Skip to content
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

Merged
merged 9 commits into from
Dec 16, 2024
Merged

Adds Roles for IC resource access requests #49565

merged 9 commits into from
Dec 16, 2024

Conversation

tcsc
Copy link
Contributor

@tcsc tcsc commented Nov 29, 2024

No description provided.

@tcsc tcsc added no-changelog Indicates that a PR does not require a changelog entry backport/branch/v17 labels Nov 29, 2024
@github-actions github-actions bot requested review from espadolini and Tener November 29, 2024 00:19
Copy link
Contributor

@espadolini espadolini left a 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.

@tcsc tcsc requested a review from smallinsky November 29, 2024 12:37
@tcsc
Copy link
Contributor Author

tcsc commented Dec 2, 2024

Are we just going to keep adding preset roles?

@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 requester and access, but I'm not sure that would be any better.

@smallinsky
Copy link
Contributor

Are we just going to keep adding preset roles?

@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 requester and access, but I'm not sure that would be any better.

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

Comment on lines 589 to 592
Rules: []types.Rule{
types.NewRule(types.KindIdentityCenter, RO()),
},
Copy link
Contributor

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 ?

Copy link
Contributor Author

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.

Comment on lines 619 to 622
Roles: []string{
teleport.SystemIdentityCenterAccessRoleName,
},
Copy link
Contributor

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.SystemOktaAccessRoleName,

Does reusing NewPresetReviewerRole and NewPresetRequesterRole this will work in AWS IC case ?

@tcsc tcsc force-pushed the tcsc/idc-expose-accounts-as-apps branch 7 times, most recently from ba6f65d to aa1132c Compare December 5, 2024 07:06
@tcsc tcsc changed the base branch from tcsc/idc-expose-accounts-as-apps to master December 5, 2024 12:09
Copy link
Collaborator

@r0mant r0mant left a 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.
@tcsc tcsc requested a review from r0mant December 12, 2024 02:07
tcsc added 2 commits December 12, 2024 13:07
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 Show resolved Hide resolved
Comment on lines 757 to 762
teleport.PresetAccessRoleName: {
{
Account: types.Wildcard,
PermissionSet: types.Wildcard,
},
},
Copy link
Collaborator

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?

Copy link
Contributor

@smallinsky smallinsky Dec 12, 2024

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

@tcsc tcsc requested a review from r0mant December 13, 2024 03:37
lib/services/presets.go Outdated Show resolved Hide resolved
@@ -877,6 +923,63 @@ func AddRoleDefaults(role types.Role) (types.Role, error) {
return role, nil
}

func mergeStrings(dst, src []string, dirty *bool) []string {
Copy link
Collaborator

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?

@tcsc tcsc requested a review from r0mant December 13, 2024 13:54
Copy link
Collaborator

@r0mant r0mant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with a comment

Comment on lines +951 to +955
target.Roles, rolesUpdated = mergeStrings(target.Roles, defaults.Roles)
changed = changed || rolesUpdated

target.SearchAsRoles, rolesUpdated = mergeStrings(target.SearchAsRoles, defaults.SearchAsRoles)
changed = changed || rolesUpdated
Copy link
Collaborator

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.

Suggested change
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)

Copy link
Contributor Author

@tcsc tcsc Dec 15, 2024

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.

Comment on lines +979 to +983
target.Roles, rolesUpdated = mergeStrings(target.Roles, defaults.Roles)
changed = changed || rolesUpdated

target.PreviewAsRoles, rolesUpdated = mergeStrings(target.PreviewAsRoles, defaults.PreviewAsRoles)
changed = changed || rolesUpdated
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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)

@tcsc tcsc added this pull request to the merge queue Dec 16, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Dec 16, 2024
@tcsc tcsc added this pull request to the merge queue Dec 16, 2024
Merged via the queue into master with commit 86dc8b1 Dec 16, 2024
41 checks passed
@tcsc tcsc deleted the tcsc/idc-roles branch December 16, 2024 02:26
@public-teleport-github-review-bot

@tcsc See the table below for backport results.

Branch Result
branch/v17 Failed

tcsc added a commit that referenced this pull request Dec 16, 2024
Backports #49565

---------
Co-authored-by: Roman Tkachenko <[email protected]>
github-merge-queue bot pushed a commit that referenced this pull request Dec 16, 2024
Backports #49565

---------
Co-authored-by: Roman Tkachenko <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
aws-iam-identity-center backport/branch/v17 no-changelog Indicates that a PR does not require a changelog entry size/md
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants