--default-ssl-certificate flag for via CRD

[aamgayle]

Description

Added functionality to use the --default-ssl-certificate flag via the CRD.
The defaultSSLCerfiticate field has a secret field with secretName and secretNamespace properties. From here it enters these in namespace/name format into the --default-ssl-certificate command line command and sets the default ssl certificate for the default HTTPS server

Fixes # (issue)
Feature # (details)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. Is it a breaking change which will impact consuming tool(s)?

• Unit Tests
• e2e Tests

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[coveralls]

Pull Request Test Coverage Report for Build 7758505383

• -28 of 52 (46.15%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.7%) to 81.252%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
api/v1alpha1/zz_generated.deepcopy.go	1	29	3.45%

Totals
Change from base Build 7747450632:	-0.7%
Covered Lines:	2557
Relevant Lines:	3147

---

💛 - Coveralls

[OliverMKing]

Looks like a good approach! Just left a few comments.

[aamgayle]

/ok-to-test sha=9374b59

[aamgayle]

/ok-to-test sha=7614337

[aamgayle]

/ok-to-test sha=a3b7596

[OliverMKing]

/ok-to-test sha=a3b7596

[bfoley13]

Very clean, LGTM!

[aamgayle]

/ok-to-test sha=7eff4ed

[OliverMKing]

/ok-to-test sha=7eff4ed

[OliverMKing]

/ok-to-test sha=7eff4ed

[MXClyde]

@OliverMKing Is there a way to trigger receiving this enhancement in an active AKS cluster? It seems like it isn't live yet (at least in West Europe region), as i'm getting an unknown field error when trying to apply the setting...

[OliverMKing]

@OliverMKing Is there a way to trigger receiving this enhancement in an active AKS cluster? It seems like it isn't live yet (at least in West Europe region), as i'm getting an unknown field error when trying to apply the setting...

This will be released shortly. It's not released yet but I'll let you know when it is.

It will be part of the AKS release notes when it is

[MXClyde]

@OliverMKing I see the new version appeared on the AKS release notes but I cannot get it working on a newly deployed cluster (in a region that has the new version according to the release tracker). Is below syntax correct?

apiVersion: approuting.kubernetes.azure.com/v1alpha1
kind: NginxIngressController
metadata:
  name: default
  namespace: app-routing-namespace
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  controllerNamePrefix: nginx
  defaultSSLCertificate: "mendix/wildcard-tls-cert"

[OliverMKing]

@OliverMKing I see the new version appeared on the AKS release notes but I cannot get it working on a newly deployed cluster (in a region that has the new version according to the release tracker). Is below syntax correct?

This should be documented in release notes, but it will only be available on clusters with k8s versions 1.30 and up. This is due to AKS addon breaking change policies.

@sabbour for visibility.