search

aws / aws-cdk

The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
https://aws.amazon.com/cdk
Apache License 2.0
11.7k stars 3.93k forks source link

aws-servicecatalog: giveAccessToRole using wildcards when sharing Principal Names #29770

Open thpham opened 7 months ago

thpham commented 7 months ago

Describe the feature

Allow to share AWS Service Catalog portfolio access with principal names that contains wildcards. The feature seems to be possible given the following documentation link: https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#principal-name-share

image

image

Use Case

In the context of an AWS Organisation with SSO and multi-account permission set, the provisioned roles in the sub-accounts have an ARN pattern which contains each time a random number suffix (ex.: arn:aws:iam::${accountId}:role/${roleName}_{randomNumber}).

The ability to use giveAccessToRole with a string ARN pattern would allow us to share access to the portfolio across the entire organisation account with the people having the permission set.

Proposed Solution

No response

Other Information

No response

Acknowledgements

CDK version used

2.136.0

Environment details (OS name and version, etc.)

macos 14

pahud commented 7 months ago

Yes I agree. Can you share a little code snippets about this and what's the desired API experience with some sample?

I am making it a p2 and we welcome any pull requests from the community to move this forward.

thpham commented 7 months ago

Hello, thank you very much for your consideration.

I'm not fully familiar with aws-cdk yet, so I hope the community or maintainers to contribute to their perspective. But I foresee 2 approach for this:

  1. we keep the signature of giveAccessToRole(role: iam.IRole) function, and we allow to instantiate a Role with an ARN pattern that allow wildcard pattern, also in regard to its validation.
  2. or we create another function for ex. giveAccessToIamPrincipalARN(arn: string): void.

I tend to prefer the option 2, because it is closer to the actual use case and current UI capability. But I might also understand that the case might be also useful in other generalisable situation that cover the option 1 (I dont have any example in mind at the moment).

Dear community, please share your opinion to help maintainers get a direction for the implementation. Thank you.

avoidik commented 2 months ago

Just an opinion.

For the context, the AWS ServiceCatalog experience includes two general parts: A. product ownership -- a person or a team which is responsible for the complete life-cycle of products being distributed through a Service Catalog portfolio B. customer-facing -- which is consuming products shared by the product owner

Having this A-B relation model in mind here's a use-case. An actor representing the B part would like to provision a ServiceCatalog product from the ServiceCatalog portfolio, which is in turn protected by the ServiceCatalog portfolio grants (it's not possible to access the portfolio without this grant). To control the grants the product owner actor should use AssociatePrincipalWithPortfolio and DisassociatePrincipalFromPortfolio ServiceCatalog API methods. The product owner can supply here a very specific IAM principal ARN (corresponding to PrincipalType.IAM), or a IAM principal pattern with no account id in it (corresponding to PrincipalType.IAM_PATTERN). The product owner is enlisting the most obvious IAM principals, like AWS SSO roles. On the other hand, the customer can use different options to provision the product: [1] by using their own IAM principal identity, [2] by using any kind of IAM delegated identity. In the first case scenario, it's relatively easy for the product owner actor to identify which IAM principal to use, and then enlist it as PrincipalType.IAM (for example SSO roles). However in the second case scenario it is not always easy, for example if the customer is using the aws_servicecatalog.CfnCloudFormationProvisionedProduct construct in CDK, it assumes IAM roles named as cdk-{qualifier}-{purpose}-{account_id}-{region} in attempt to access the ServiceCatalog portfolio, and then fails because the grants list has only SSO roles in it. It's okay to enlist these special CDK IAM roles for one particular AWS account, but what if we have plenty of AWS accounts? The IAM pattern matching grants come in handy. The list of the grants in question can have up to 10 entries, so that the IAM pattern matching option could be considered as an option to relax the constraint.

In my opinion, the 2nd option with giveAccessToIamPrincipalARN(arn: string) can potentially fulfil this gap.

avoidik commented 2 months ago

xref. https://github.com/aws/aws-cdk/issues/24370, https://github.com/aws/aws-cdk/discussions/25956