Aws-load-balancer-controller: Getting alb.ingress.kubernetes.io/certificate-arn from a variable (secret)

[omerfsen]

Currently we define to use SSL cert ARN like:

alb.ingress.kubernetes.io/certificate-arn : arn:aws:acm:eu-central-1.......
````

It would be nice to get this value from a variable (from a secret) like:

---

apiVersion: v1
kind: Secret
metadata:
name: aws-alb-ssl
type: Opaque
data:
arn: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Then use it on alb.ingress.kubernetes.io/certificate-arn   like

alb.ingress.kubernetes.io/certificate-arn: $(aws-alb-ssl.arn)

````

[M00nF1sh]

Hi,
What's your use case for this scenario?

1. will you actually change the certificate-arn after it's created?
2. seems the effort to update certificate-arn in ingressSpec is same as update it in secretSpec.

[omerfsen]

It is for security as arn contains awsid etc so idea is to keep it secret as much as it can be

Sent using mobile phone

On 4 Jan 2019, at 18:47, M00nF1sh [e-mail] wrote:

Hi,
What's your use case for this scenario?

will you actually change the certificate-arn after it's created?
seems the effort to update certificate-arn in ingressSpec is same as update it in secretSpec.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[backjo]

I wonder if it might be useful to add the capability to lookup by a Tag instead of just ARN - it could be useful for cases where you want to run the same ingress definition in multiple regions (which might have the same certificate imported with different ARNs)

[M00nF1sh]

@backjo @omerfsen
How about auto-discover it by hostname(if user specified it), and keep the ability to override it with current alb.ingress.kubernetes.io/certificate-arn annotation?
I remember there was a pr for it, but get closed accidentally.

[omerfsen]

Something like

alb.ingress.kubernetes.io/certificate-autodiscover
http://alb.ingress.kubernetes.io/certificate-arn

as it will allow us NOT to enter ARN (which contains Customer Id)

On Mon, Jan 7, 2019 at 9:18 PM M00nF1sh [e-mail] wrote:

@backjo https://github.com/backjo @omerfsen
https://github.com/omerfsen
How about auto-discover it by hostname(if user specified it), and keep the
ability to override it with current
alb.ingress.kubernetes.io/certificate-arn annotation?
I remember there was a pr for it, but get closed accidentally.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/aws-alb-ingress-controller/issues/800#issuecomment-452085247,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AcVFm2_0fxL_4rkEeibEYJ_CeGIIrwUMks5vA7mqgaJpZM4Zp5Uf
.

[BrianChristie]

Certificate Autodiscovery would be great. It is supported by Zalando's controller.

[backjo]

One potential difficulty i see with discovering by hostname is if there are multiple hits in ACM. How do you tell the ingress controller to get the "new" one when the cert is being renewed?

[M00nF1sh]

One potential difficulty i see with discovering by hostname is if there are multiple hits in ACM. How do you tell the ingress controller to get the "new" one when the cert is being renewed?

@backjo
I think the one strategy can be below:

1. using hostname to discover candidate certificates first(needs to deal with wildcard certificates correctly).
2. if there are multiple candidate certificates, try to resolve it with tags(e.g. kubernetes.io/cluster/${clusterName}:shared and alb.ingress.kubernetes.io/certificate-autodiscover: 1)
3. if there are still multiple candidate certificates, log an error message in controller(also rise error events to ingress object), and prompt user to setup proper tags or using alb.ingress.kubernetes.io/certificate-arn to denote one explicitly.

@omerfsen
I think we don't need a separate annotation like 'alb.ingress.kubernetes.io/certificate-autodiscover', we can make it the default behavior. (customers can override the behavior with alb.ingress.kubernetes.io/certificate-arn). If we output proper error message to controller and ingress objects about failure during certificate-autodiscover, it will be ok 😄 .
The only issue is handling with alb.ingress.kubernetes.io/listen-ports, previously, if user don't explicitly specify [{"HTTPS": 443}], we used whether certificate-arn exists to determining whether we create an HTTPS listener for them.
So for these customers that want certificate-autodiscover, there are actually three choice:

1. add annotation alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}' explicitly to use HTTPS listener and certificate auto discover
2. maintain a separate annotation like proposed alb.ingress.kubernetes.io/certificate-autodiscover, and add that annotation to use HTTPS listener and certificate auto discover
3. do certificate-autodiscover by default, and create HTTPS listener for customer. Otherwise, fall back to HTTP, and log an warning message to customer.

I think The 3rd choice have the least required custom configuration on ingress, and default secure 😄

If the above make sense, i can make a PR to support it, should be pretty straight forward.
(BTW, is there any better tag name/value than alb.ingress.kubernetes.io/certificate-autodiscover:1? it seems a bit odd to me).

[florind]

@M00nF1sh certificate autodiscovery is indeed an awesome feature to add. Amongst other benefits it would allow to use the same Ingress definition in multiple environments.
I'd also go for option 3 since such auto-configuring out of the box would effectively ensure the Ingress controller works securely by default.

[khyew]

Same. We have multiple environments (namespaces) in the same cluster and auto-detection via tags is how we assign DNS names for the services in each environment (via Route53/ExternalDNS). It would be great if something similar exists to support automatically assigning certs from ACM to the ALB so that we don't have to maintain a deployment spec with a unique cert ARN for each environment.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.