-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate EKS-related IAM resources #2662
Separate EKS-related IAM resources #2662
Conversation
Welcome @johananl! |
Hi @johananl. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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/test-infra repository. |
/ok-to-test |
@@ -96,6 +97,16 @@ func (t Template) RenderCloudFormation() *cloudformation.Template { | |||
Roles: t.controllersPolicyRoleAttachments(), | |||
} | |||
|
|||
if t.Spec.EKS.Enable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This field is going to be changed with #2648
Let's wait for it to be merged first and then rebase.
/hold
Currently the AWSIAMManagedPolicyControllers policy is quite large and sometimes exceeds the maximum number of characters AWS allows in managed policies. Separating the policy into smaller policies can solve this problem since multiple policies can be attached to an IAM user/role. It makes sense to separate EKS-related resources specifically because they are grouped nicely under a conditional and refer to one logical entity.
@sedefsavas done. |
Given the impact of this is creating new policies, I think we may need to bump the minor version to v0.8.0 |
OK. Is there anything I should do to make this happen @randomvariable? Also, if we're incrementing the version for this, should we proactively move any other IAM statements to new policies while we're at it? Right now the EKS-related statements seem to make the biggest difference in terms of policy size. |
/unhold |
I think so. Can you create an issue documenting any suggested changes as we need to think carefully about upgrades here. I'm placing the hold back on because we haven't decided on a branch split yet - will raise at next office hours. /hold |
This is big enough impact in terms of upgrades that changes should be recorded in an ADR too, see https://github.com/kubernetes-sigs/cluster-api-provider-aws/tree/main/docs/adr |
@randomvariable I took a closer look at the various IAM policies. AFAICT the only policy which has a risk of hitting the 6144-char size limit is Given the above and given that we have to balance between the per-policy size limit and the limit on the number of policies which can be attached to an IAM entity (default: 10), I don't think we need to do anything other than break out the EKS-related resources from As far as upgrades and ADRs go, I'm happy to follow any necessary process, however do you feel this is indeed such a big change? We're talking about moving IAM statements which are already applied to a new policy that's attached to the same entities (roles/users/groups). Assuming we don't make any policy logic mistakes and the "allow/deny" end result is identical, AFAICT the users don't need to do anything special when upgrading and I can't find any reason for downtime or other problems. Following the same logic, this change also doesn't feel like an architectural change to me. What do you think? |
} | ||
} | ||
|
||
// ControllersPolicyEKS creates a policy from a template for AWS Controllers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's ok for now. The 10 policies limit should be relatively well understood by folk in the IAM space.
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: randomvariable The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind bug
What this PR does / why we need it:
This PR works around the AWS character limit for managed policies. In the e2e tests the
AWSIAMManagedPolicyControllers
policy is currently very close to the AWS limit, which means that the next time a feature adds a few lines to this policy, the CloudFormation template would error out (I've already hit this limit while working on #2271, hence this issue + PR). More info and repro instructions in #2642.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #2642
Special notes for your reviewer:
Checklist:
Release note: