Redirect Action based only on Path - Not creating Rule

[Ca-moes]

Bug Description

After creating an Ingress that uses the redirect action [docs] the LB Controller logs that it built the model, without errors, but the new rule is not part of the model, and it does not appear on the AWS LB rules.

Steps to Reproduce

Apply the following Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: favicon-redirect
  annotations:
    alb.ingress.kubernetes.io/actions.redirect-to-cdn: >
      {"type":"redirect","redirectConfig":{"host":"<something>.cloudfront.net","path":"/static/favicon.ico","port":"443","protocol":"HTTPS","query":"k=v","statusCode":"HTTP_302"}}
spec:
  ingressClassName: alb-external
  rules:
    - http:
        paths:
          - path: /favicon.ico
            pathType: Exact
            backend:
              service:
                name: redirect-to-cdn
                port:
                  name: use-annotation

The LB Controller logs 3 lines:

{"level":"info","ts":"2025-07-22T07:58:34Z","logger":"controllers.ingress","msg":"Auto Create SG","LB SGs":[{"$ref":"#/resources/AWS::EC2::SecurityGroup/ManagedLBSecurityGroup/status/groupID"},"sg-<id>"],"backend SG":"sg-<id>"}

{"level":"info","ts":"2025-07-22T07:58:34Z","logger":"controllers.ingress","msg":"successfully built model","model":"{\"id\":\"promptly-lb-prod-uk-euw2\" ...

{"level":"info","ts":"2025-07-22T07:58:35Z","logger":"controllers.ingress","msg":"successfully deployed model","ingressGroup":"promptly-lb-prod-uk-euw2"}

With no errors, but on the model value, it does not show the favicon rule.

Expected Behavior

On the model value of the LB Controller logs, see the mention of the favicon rule, and then see it created on the AWS Console.

Actual Behavior

No Rule is created on the LB.

The Controller is healthy and does not throw any error. This happens Always, when not defining a host. If I set a host, it works correctly. But it should be possible to set the rule without the host.

Regression Was the functionality working correctly in a previous version ? Didn't test it.

Current Workarounds

Apply the same rule for all the intended hosts.

Environment

• AWS Load Balancer controller version: v2.13.3
• Kubernetes version: v1.33.1-eks-595af52
• Using EKS (yes/no), if so version?: Yes
• Using Service or Ingress: Ingress
• AWS region: eu-central-1
• How was the aws-load-balancer-controller installed: Helm was used, via ArgoCD. Nothing special on values.yaml
• Current state of the Controller configuration:
  • kubectl -n <controllernamespace> describe deployment aws-load-balancer-controller
• Current state of the Ingress/Service configuration:
  • kubectl describe ingressclasses
  • kubectl -n <appnamespace> describe ingress <ingressname>
  • kubectl -n <appnamespace> describe svc <servicename>

All above are normal, I'll provide on the comments if needed.

Possible Solution (Optional)

None

Contribution Intention (Optional)

• [ ] Yes, I'm willing to submit a PR to fix this issue
• [x] No, I cannot work on a PR at this time

Additional Context

• https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/3782#issuecomment-2293314692

[Ca-moes]

Update

Got it to work, by creating the Ingress on the same namespace of the LB Controller. Still unsure if this was what it made it work, or some extra annotations:

alb.ingress.kubernetes.io/load-balancer-name: <lb-name>
alb.ingress.kubernetes.io/certificate-arn: <arns of certs>
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/ssl-redirect: '443'

If the Ingress needs to be on the same namespace, it would be a good addition to the documentation to point this out.

[wweiwei-li]

Ingress does not need to be on the same namespace of the LB controller.

[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

[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".

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.