Closed kpulgam closed 2 years ago
@ketan-sdeuser
The v2 Controller doesn't support the --alb-name-perfix
flag. we now used a fixed name pattern for ALB/NLBs: k8s-<namespacedName>-<hash>
. The fixed name pattern allows us to have fine-grain control to stay within ELB's naming limits.
What's your use case to use this --alb-name-perfix
flag? (e.g. the purpose, prefix length, etc.)
will a new feature to allow you specify the whole ALB name(instead of a prefix) for Ingress be sufficient?
When trying to fit into existing infrastructure moulds at Enterprises, IAM policies are already crafted around specific resource naming conventions. We need the ability to customize it. For example, a team name "aum" must have all ALB resources named starting with aum prefix. It is important to have this level of customization for Enterprise integrations with the existing IAM paradigms
Any updates regarding this feature?, we just move to work with the new version and we need the as well need the prefix option that was in the old controller
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
@k8s-triage-robot: Closing this issue.
@M00nF1sh Is this not mentioned anywhere in the migration guide? We use this feature to lockdown IAM permissions when using multiple kubernetes clusters. We expected this feature to still work from it not being mentioned anywhere. What is now the best way to grant limited access to alb resources when running multiple kubernetes clusters in the same account?
We explored using something like conditionals on tags but because each ingress controller needs to be able to AddTags that would result in any compromise of one controller effectively meaning they all would be compromised.
/remove-lifecycle rotten /reopen
@kishorj: Reopened this issue.
@rdubya16, the v2 controller adds a resource tag with the key elbv2.k8s.aws/cluster
with the current clusterName as the value. You could also configure controller instance to add additional tags. Would it not be possible to lockdown the IAM permission per controller based on the specific tag values?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
We use --alb-name-perfix in our current v1 alb ingress controller implementation , which helps us craft our IAM policy for controller to make it resource bound based on the prefix. I see there was similar discussion in https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/1302 to see if --alb-name-perfix is also supported in v2 ( this will help us along with tag based conditions in locking IAM even further ) I did not notice this flag mentioned anywhere in the documentation - https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/docs/deploy/configurations.md
Can anyone please advise if it still is supported. Thanks!