-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Adds Roles for IC resource access requests #49565
Conversation
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.
Are we just going to keep adding preset roles? Is there a documented list of roles that people should expect to see in their cluster? We've had customers that were rightfully weirded out by the addition of roles that they didn't add.
@espadolini - A good question, to which I don't have a good answer. I've basically followed the pattern used in other integrations, but I'm open to alternative suggestions on how to grant/deny access to IC resources with access requests. I did consider just adding the appropriate conditions to |
I agree that the creation of additional roles by Teleport under the hood might be unexpected behavior for Teleport users , we can update our documentation and AWS Identity Center enrollment flow to clearly explain that the integration will create these roles to support the access request flow that we make clear that after enrolling AWS IC those roles are expected and will be created internally by teleport |
lib/services/presets.go
Outdated
Rules: []types.Rule{ | ||
types.NewRule(types.KindIdentityCenter, RO()), | ||
}, |
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.
Doe the RO rule for `KindIdentityCenter is really needs to access AWS IC resource ?
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.
Things stop working when I take it out, so... :-)
Looking at the implementation of ListResources()
, the role access rules are explicitly checked, so I think it's necessary.
lib/services/presets.go
Outdated
Roles: []string{ | ||
teleport.SystemIdentityCenterAccessRoleName, | ||
}, |
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.
wonder why we need the separate AWS IC requester role for that
After taking a look at our code we can just extend the NewPresetRequesterRole that currently grands access request role for PresetGroupAccessRoleName and Okta:
teleport/lib/services/presets.go
Line 706 in 94dc1a9
teleport.SystemOktaAccessRoleName, |
Does reusing NewPresetReviewerRole
and NewPresetRequesterRole this will work in AWS IC case ?
ba6f65d
to
aa1132c
Compare
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 agree with other commenters - can we please update the existing preset roles to allow requesting access to IC resources rather than adding another set of presets?
It's more than just about having fewer preset roles, new presets will also have ripple effects on the documentation guides, etc. If we update existing ones, things will work out of the box, docs won't need as much updating, etc.
Adds the global-allow wildcards to the preset access role, allowing the `access` role to participate in Resource Access Requests involving Identty Center resources.
Adds the global-allow wildcards to the preset access role, allowing the `access` role to participate in Resource Access Requests involving Identty Center resources.
lib/services/presets.go
Outdated
teleport.PresetAccessRoleName: { | ||
{ | ||
Account: types.Wildcard, | ||
PermissionSet: types.Wildcard, | ||
}, | ||
}, |
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.
Hrm, wouldn't this assign people with this role to each account and permission set pair? Don't we want to only grant access request privileges to them?
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.
Yes, this will ensure that anyone with the appropriate access role is assigned to WS IC resources.
However we should consider following the existing pattern:
// defaultAllowAccessRequestConditions has the access request conditions that should be set as default when they were
// not explicitly defined.
func defaultAllowAccessRequestConditions(enterprise bool) map[string]*types.AccessRequestConditions {
if enterprise {
return map[string]*types.AccessRequestConditions{
teleport.PresetRequesterRoleName: {
SearchAsRoles: []string{
teleport.PresetAccessRoleName,
teleport.PresetGroupAccessRoleName,
},
},
teleport.SystemOktaRequesterRoleName: {
SearchAsRoles: []string{
teleport.SystemOktaAccessRoleName,
},
MaxDuration: types.NewDuration(MaxAccessDuration),
},
}
}
return map[string]*types.AccessRequestConditions{}
}
// defaultAllowAccessReviewConditions has the access review conditions that should be set as default when they were
// not explicitly defined.
func defaultAllowAccessReviewConditions(enterprise bool) map[string]*types.AccessReviewConditions {
if enterprise {
return map[string]*types.AccessReviewConditions{
teleport.PresetReviewerRoleName: {
PreviewAsRoles: []string{
teleport.PresetAccessRoleName,
teleport.PresetGroupAccessRoleName,
},
Roles: []string{
teleport.PresetAccessRoleName,
teleport.PresetGroupAccessRoleName,
},
},
}
}
return map[string]*types.AccessReviewConditions{}
}
To extend this we just need to add PresetAWSIdentityCenterAccessRoleName in both defaultAllowAccessRequestConditions and defaultAllowAccessReviewConditions. This ensures that the access role does not interfere with AWS IC resources.
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 I agree let's do that as it's safer.
@tcsc Sorry for going back and forth but I think it makes sense to have preset role for AWS IC resources to make sure users don't accidentally grant everyone access to everything by assigning access
role.
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 have to admit that I was a bit concerned about that myself.
lib/services/presets.go
Outdated
@@ -877,6 +923,63 @@ func AddRoleDefaults(role types.Role) (types.Role, error) { | |||
return role, nil | |||
} | |||
|
|||
func mergeStrings(dst, src []string, dirty *bool) []string { |
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 is very confusing function signature, can we have it return whether the role changed or not (boolean argument) rather than modify the passed in pointer?
Co-authored-by: Roman Tkachenko <[email protected]>
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.
with a comment
target.Roles, rolesUpdated = mergeStrings(target.Roles, defaults.Roles) | ||
changed = changed || rolesUpdated | ||
|
||
target.SearchAsRoles, rolesUpdated = mergeStrings(target.SearchAsRoles, defaults.SearchAsRoles) | ||
changed = changed || rolesUpdated |
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.
Hmm isn't this the equivalent (and cleaner) or am I missing something?
Same below.
target.Roles, rolesUpdated = mergeStrings(target.Roles, defaults.Roles) | |
changed = changed || rolesUpdated | |
target.SearchAsRoles, rolesUpdated = mergeStrings(target.SearchAsRoles, defaults.SearchAsRoles) | |
changed = changed || rolesUpdated | |
target.Roles, changed = mergeStrings(target.Roles, defaults.Roles) | |
target.SearchAsRoles, changed = mergeStrings(target.SearchAsRoles, defaults.SearchAsRoles) |
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.
If the first mergeStrings
call changes the roles but the second one doesn't, then the changed
flag will be incorrectly reset and the change won't be propagated.
target.Roles, rolesUpdated = mergeStrings(target.Roles, defaults.Roles) | ||
changed = changed || rolesUpdated | ||
|
||
target.PreviewAsRoles, rolesUpdated = mergeStrings(target.PreviewAsRoles, defaults.PreviewAsRoles) | ||
changed = changed || rolesUpdated |
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.
target.Roles, rolesUpdated = mergeStrings(target.Roles, defaults.Roles) | |
changed = changed || rolesUpdated | |
target.PreviewAsRoles, rolesUpdated = mergeStrings(target.PreviewAsRoles, defaults.PreviewAsRoles) | |
changed = changed || rolesUpdated | |
target.Roles, changed = mergeStrings(target.Roles, defaults.Roles) | |
target.PreviewAsRoles, changed = mergeStrings(target.PreviewAsRoles, defaults.PreviewAsRoles) |
Backports #49565 --------- Co-authored-by: Roman Tkachenko <[email protected]>
Backports #49565 --------- Co-authored-by: Roman Tkachenko <[email protected]>
No description provided.