-
Notifications
You must be signed in to change notification settings - Fork 561
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
🌱 Redefine managing IAM resources: Create and Delete #4909
base: main
Are you sure you want to change the base?
🌱 Redefine managing IAM resources: Create and Delete #4909
Conversation
Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it. 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. |
/assign @richardcase @Ankitasw |
@Atharva-Shinde Looks like there are CI failures here. Would you mind taking a look at failures in linting and verifying in particular? The linting job should have comments pointing at what to do in order to resolve the issue, such as this message about commenting or un-exporting a symbol. |
/retitle 🌱 Redefine managing IAM resources: Create and Delete Updating the title should cause the PR verify job to pass. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
2d73172
to
9bd5db6
Compare
Thanks @nrb I've addressed the CI failures :) |
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 seems reasonable to me overall. I've added some questions to help me understand where this might go in the future before I approve it.
|
||
func attachPoliciesToRole(rolename *string, awsManagedPolicies []string, client *iam.IAM) error { | ||
if awsManagedPolicies == nil { | ||
// klog.Warningf("no policies defined to attach to the IAM role \"%s\"", *rolename) // TODO |
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.
What's the next action here? Just enabling the warning, or something else?
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.
Reading further, looks like there's a question about outputting the ARNs elsewhere - is this the same?
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 at that time I was wondering if we should issue a warning that the user hasn't defined any awsManagedPolicies in their CloudFormation config or just return back to parent call directly without any warnings.
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.
So should we give the warning?
klog.Warningf("IAM role \"%s\" is already attached to policy", *rolename) // TODO should we output the policy arn? how safe is it | ||
continue | ||
default: | ||
return errors.Wrapf(err, "failed to attach IAM role \"%s\" to policy", *rolename) // TODO should we output the policy arn? how safe is it |
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.
Thinking about where this command should be running, I can think of a couple environments:
First, a user's machine, while they set up a management cluster. I think outputting an ARN here is fine. They have some sort credentials on their machine, which are the higher risk asset.
Next, CI, which might be spinning up resources, either for testing or as part of a larger provisioning system. In this case, the ARNs would probably get output into logs. Hopefully, the CI is using short-lived credentials, but again, those would be the more valuable asset.
It's true that policy ARNs could be observed and an attacker could attempt to edit the policy to expand permissions. However, I'm not sure the actual ARN is all that important, since what really matters are the permissions to actually overwrite the policy the ARN points to.
Does that make sense?
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.
Yeah that make sense :) I'll make the change to include the ARNs in the outputs above.
func prioritySet(t go_cfn.Template) (rmap map[string][]go_cfn.Resource, err error) { | ||
rmap = map[string][]go_cfn.Resource{} | ||
for _, resource := range t.Resources { | ||
if resource.AWSCloudFormationType() == configservice.ResourceTypeAwsIamRole { |
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.
The description says that this PR is looking to move away from CloudFormation, but we're using CloudFormation files here.
Is the intent to use CloudFormation templates as the input still, but introspect them and make our own API calls vs submitting them directly to the CF service endpoints?
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.
The intent as discussed with my mentors Richard and Ankita was to think of a solution that eventually gets rid of the CloudFormation to manage IAM resources. The end goal is to create an idempotent solution that enforces API calls to AWS to manage the IAM resources and doesn't rely on CloudFormation Stack. And the intent is to do this incrementally and not all at once so that we avoid big code change altogether and maintain a low to no user side changes.
So this PR is the first step in achieving the above, where we rely on the CF config/template (for now) to get the input and make API calls to manage these IAM resources without relying on CloudFormation stack.
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
What type of PR is this?
/kind feature
/area clusterawsadm
What this PR does / why we need it:
Currently, CAPA manages prerequisites required by AWS through CloudFormation which has caused numerous issues to CAPA end-users. This PR works as a stepping stone in migrating away from the use of AWS CloudFormation and relying on service specific API calls to manage IAM resources and gradually make the process idempotent.
This PR introduces 2 new commands:
clusterawsadm bootstrap iam create
: creates IAM resources(roles, instances profiles and policies) from the bootstrap configuration file (uses default bootstrap configuration if not provided)clusterawsadm bootstrap iam delete
deletes IAM resources(roles, instances profiles and policies) created using the bootstrap configuration file (uses default bootstrap configuration if not provided)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 #3715
Special notes for your reviewer:
Screenshots:
Checklist:
Release note: