search

kubernetes-sigs / aws-load-balancer-controller

A Kubernetes controller for Elastic Load Balancers
https://kubernetes-sigs.github.io/aws-load-balancer-controller/
Apache License 2.0
3.9k stars 1.45k forks source link

Support reading Headers values from Secrets #3852

Open ivanfoo opened 2 weeks ago

ivanfoo commented 2 weeks ago

Is your feature request related to a problem? We need to configure rule conditions based on specific Header values. However, these values can contain sensitive data so we don't want them to end up visible in plain text in the Ingress annotations. Example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: any-namespace
  name: any-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/conditions.sensible-headers: >
      [{"field":"http-header","httpHeaderConfig":{"httpHeaderName": "AnySensibleHeader", "values":["AnySensibleValue"]}}]

Describe the solution you'd like Add support to reading header values from kubernetes Secrets as it's done to configure the clientID and clientSecret when using OIDC authentication.

alb.ingress.kubernetes.io/conditions.sensible-headers: >
  [{"field":"http-header","httpHeaderConfig":{"httpHeaderName": "AnySensibleHeader", "values":["secret://any-secret/any-key"]}}]

Describe alternatives you've considered Load Header values from AWS Services like ParameterStore or SecretsManager

shraddhabang commented 1 week ago

@ivanfoo Thank you for raising this. But I have a question about it. even if we implement this, you will still be able to see these header values from console/cli. Also, if you are concerned abut the sensitive data in ingress annotation, you could try restricting the ingress access by defining the RBAC values.

ivanfoo commented 1 week ago

@shraddhabang you are right about the values being visible when using the console or CLI. However, my concern is more about how exposed these annotations are.

It's way easier to restrict access to ALB details on AWS with IAM than restricting access to Ingresses resources that contain sensitive data as annotations, as there is not a way to deny access to resources by labels or a similar approach.

Also, these annotations could be easily leaked everywhere: ArgoCD dashboard, cluster backups, alert messages, monitoring tooling...

I'm not saying the solution is perfect, but at least it does not increase the exposed surface...

What do you think? Any chance of consuming headers values from secrets? Also, do you know if native support for sensitive Headers is coming anytime on the ALB side?

Thanks!