Use clear, shorter, deterministic names for internal resources

[allquixotic]

I would like to suggest using clear, deterministic, shorter names for artifacts/resources that SSO Extensions creates.

Example: "env-aws-sso-extensions-f-envindependentutilityenv-10ygvcq...." (more stuff I'm not listing for security reasons) is the name of an S3 bucket in our stack where I have to put links_data and permission_sets.

To pull this string apart into its component pieces, we have:

env-: The name of the Environment in the config file (config/env.yaml) - OK, this is fine.
aws-sso-extensions-f-: Seems like the name of the project overall, just shortened a bit. It can be shortened more to ssox or ssoex.
envindependentutilityenv: This is really confusing for me, and this descriptor does not at all tell me "This is where you need to put the links_data and permission_sets".

10ygvcq...: This is a unique identifier because S3 buckets have to be unique globally. Fine.

I understand the reason it's so long is because CDK is auto generating this horrible name, but this is not user-friendly. It makes it difficult for us to understand what these objects are for.

Similarly with the CodePipelines and other aspects of the support stacks for SSO Extensions, they are too long and difficult to understand.

I would recommend shortening "AWS SSO Extensions for Enterprise" to "ssox" or "ssoex" to make room for more descriptive names. If the unique identifier strings are still required on the end of bucket names and pipelines, that's fine -- I'm mainly concerned with the prefix part that's confusing, and the envindependentutilityenv which is even more confusing.

[allquixotic]

Just realized that the "App" and "Environment" parameters in config/*.yaml pertain to the first two fields. So I can change/shorten those significantly on my own without any change to the upstream code.

What I can't change or clarify on my own is things like "envindependentutilityenv". I still think that should be reexamined.

[tamara-h]

Hi @allquixotic I'll be having a look into this issue.
For what use cases are you trying to predict the names of the resources? We can work backwards from the problem that this is causing you.
We have a lot of non-deterministically named resources (such as IAM policies) within the solution which may cause breaking changes if updated, so a closer look at how this is affecting your implementation may be needed.

[allquixotic]

Hi, the main area where the names should be more user-friendly is the S3 buckets (with S3 provisioning mode).

The S3 bucket for links_data and permissions_data is essentially admin-facing (admins being SSO gatekeepers who dole out permissions). Either the admins will manually maintain the files in this bucket, or they will be writing some custom automation code that performs CRUD operations on the bucket. In either case they need to know the bucket name.

I'm not insistent on the bucket name being completely deterministic, but making it easy to identify the relevant bucket to store the links_data and permissions_data is important. I see that the solution creates more than one bucket, and finding the right one is a process of elimination right now (click on bucket, list contents, see if it has links_data and permissions_data folders; if not, keep looking).

Part of the reason it is unfriendly now is the default value of the App value in config/env.yaml is aws-sso-extensions-for-enterprise, which gets shortened by CDK to a value that doesn't make the S3 bucket name very unique except for the randomly generated string at the end of the name.

The other part of the S3 bucket name that is perplexing is envindependentutilityenv -- it would be much nicer to change out this name for something that clearly tells us "put your links_data and permissions_data here!"

Thanks...

[leelalagudu]

@tamara-h to update on the current status