-
Notifications
You must be signed in to change notification settings - Fork 22
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
Implement a configurable pattern for the IAM Role Name #73
Conversation
Signed-off-by: Matt Wise <[email protected]>
d6d7217
to
f23a216
Compare
Codecov Report
@@ Coverage Diff @@
## master #73 +/- ##
==========================================
+ Coverage 66.19% 66.40% +0.20%
==========================================
Files 8 8
Lines 991 1003 +12
==========================================
+ Hits 656 666 +10
- Misses 304 306 +2
Partials 31 31
Continue to review full report at Codecov.
|
Thanks @diranged. I will check this out today and also meanwhile let me think about this point
and see if we are leaving any holes which will create an issue. This was not an issue in present setup because we do know that namespace name follows DNS naming conventions and can not have more than 63 characters which is what IAM Role restrictions as well. Allowing the pattern completely open creates the possibility of having new special characters which might not be allowed in IAM role name. My only worry is, if for some reason administrator running into this issue AFTER few valid iam roles created then, changing the pattern will create all new sets of iam roles and that need changes in the application deployment specs etc if they are referring that iam role anywhere. |
|
||
if config.Props.DeriveNameFromNamespace() && config.Props.MaxRolesAllowed() == 1 { | ||
roleName = fmt.Sprintf("k8s-%s", iamRole.ObjectMeta.Namespace) | ||
// TODO: Remove the need to do this here. |
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.
Good point and yes I included ARN in the status of iam role object itself in the last release so we should be able to skip this for delete in future
Change looks overall good!! If you tested it out in your cluster, can you post some screenshots with results? May be with different type of patterns and one with "invalid" pattern too to see how the error is surfaced all the way to IamRole spec/status? |
Sorry - yes, this has been tested and is working today. Here's a failure example:
|
Here's it working:
|
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.
LGTM
Do I need to refactor for the conflicts - or will you take care of that? |
Can you handle the conflicts please? |
Signed-off-by: Matt Wise <[email protected]>
1f92f60
to
6103fa4
Compare
@mnkg561 Sorry for the delay - here ya go! |
Closes #62
Could you share the solution in high level?
Implement a new parameter (
iam.role.pattern
) with a default value that matches the current behavior (k8s-<iamrole name>
). This new parameter is a template that can be customized by the administrator of the iam-manager controller.Note: This PR also removes the
iam.role.derive.from.namespace
property because it becomes unnecessary, the user can simply setiam.role.pattern: k8s-{{ .ObjectMeta.Namespace}}
to get the same behavior.Could you share the test results?
All of the tests pass.
** Note about IAM Role naming restrictions **
The PR does not currently try to protect the end-user from having an IAM role name that doesn't work with IAM (ie, bad characters, too long, etc). In my opinion, it is up to the code that actually creates the IAM role itself to return back a success/failure. If we want to do some kind of validation before trying to make the call, then I think we'd be looking at implementing a validationwebhook that prevents the user from creating the Iamrole object all. That would be great - but
it is pretty far out of the scope of this PR.