EKS Automode - cant specify header attributes

[jcuribe]

• Bug Description
  EKS Cluster with automode enabled v1.32.
  When I create or update an ingress and use annotation like the following:
  alb.ingress.kubernetes.io/listener-attributes.HTTPS-443: routing.http.response.strict_transport_security.header_value=max-age=600; includeSubDomains; preload
  the corresponding load-balancer is correctly created or updated but the listner is not updated.

• Steps to Reproduce
  create a EKS cluster with auto mode enabled
  create a svc and corresponding ingress , add any anotation under alb.ingress.kubernetes.io/listener-attributes.HTTPS-443. for example alb.ingress.kubernetes.io/listener-attributes.HTTPS-443: routing.http.response.strict_transport_security.header_value=max-age=600; includeSubDomains; preload

• Expected Behavior
  under the correpoinding HTTPS-443 listener the header should be added

• Environment
  EKS version 1.32 automode enabled

[wweiwei-li]

Hey, did you see any controller logs with error messages ?

[jcuribe]

really difficult to debug. when you have auto mode enabled in cluster the controller is that normally manages the alb is "managed" so no way to look at logs.

I searched in cloudtrail but did not see anything with regard to the load balancer listener. so my guess is that I'm missing something or its not supported.

[oliviassss]

Hi @jcuribe, the EKS Auto mode LBC hasn't supported this feature yet. @M00nF1sh is doing some refactoring work for the code base, after that's done we should have the EKS auto mode LBC supporting the latest version of open-source LBC.

[jcuribe]

Any update on this? ( eks auto mode, annotation )

I am working on a work around using:

• aws elbv2 describe-load-balancers
• aws elbv2 modify-listener-attributes --listener-arn

Any other sugestion in the meantime?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[matthiassb]

Checking in on this

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

Details

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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-sigs/prow repository.