You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AWS added mTLS support to ALBs earlier this year. We could not find support for mTLS in this project.
Our goal is to use mTLS for most of the (sub) domains for a Kubernetes cluster to reduce the attack surface. We're evaluating if we can implement the following ALB listener structure:
exception: host matches webhook.* disable mTLS and forward to Kubernetes
default: enable mTLS and forward to Kubernetes
Questions:
How to implement the "exception" listener? Would this be a another listener or should we define a different ingress-class which would create a second ALB?
Would you accept a PR to implement this (if we chose to continue with)?
Ideas:
New flags
aws-mtls-mode = off|verify|passthrough
aws-mtls-trust-store-arn = ... ARN of the elbv2 Trust Store
AWS added mTLS support to ALBs earlier this year. We could not find support for mTLS in this project.
Our goal is to use mTLS for most of the (sub) domains for a Kubernetes cluster to reduce the attack surface. We're evaluating if we can implement the following ALB listener structure:
webhook.*
disable mTLS and forward to KubernetesQuestions:
Ideas:
New flags
aws-mtls-mode = off|verify|passthrough
aws-mtls-trust-store-arn = ...
ARN of the elbv2 Trust Storeaws-mtls-ignore-client-certificate-expiry = true|false
ignore_client_certificate_expiry
New annotation:
zalando.org/aws-mtls-mode = off|verify|passthrough
on each ingress to turn off mTLS on a specific domainThe text was updated successfully, but these errors were encountered: