Global Name Prefix

🚀 Feature Request

Description

I’m working as an expert AWS consultant with a large internet bank on a high-security project using CDK. It’s the very first project at this bank using CDK, and it has allowed us to accelerate development considerably. However, when trying to prepare and deploy to the new staging and production accounts, we were suddenly faced with a problematic integration issue: the fact that boundary policies require us to prefix many resource names (such as lambdas, security groups, and many more) with the team name, e.g. theTeam-my-lambda-function-72636364.

The reason these prefix rules exist is due to the fact that there are some accounts shared by multiple teams. Imposing a network of rules keyed on name prefixes is the only way of keeping teams within one account separate, as tags can’t be used for policy conditionals with all resources, e.g. lambdas.

Shared accounts, while no longer best practice on AWS, do exist in many companies and will probably do so for quite some time, which means that our situation at this particular bank isn’t unique. In order for CDK to gain widespread acceptance in brownfield situations, it would be good if there was an easy way – and above all a standardised way – of specifying prefixes for CDK.

CDK doesn’t support resource name prefixing out of the box. In fact, CDK follows best practices as established by CloudFormation and assumes full control of all generated names. Postprocessing the CloudFormation templates isn’t an option, as tokens and other abstract features of CDK make simple text substitutions very difficult if not impossible.

Elad Ben-Israel proposed overloading the CDK method for generating logical names. While this would work, it’s somewhat of a hackish solution in that it can be done in several different ways. The security powers-that-be at this bank would prefer a standardised solution in order to be able to recommend CDK.

Proposed Solution

We propose a simple switch to the cdk synth command. It would be used as follows:

$ cdk synth --name-prefix='theTeam-'

This would add the prefix to all resource names, across all stacks. To provide even greater flexibility, the prefix could also be made part of the project configuration, obviating the need to type the proposed --name-prefix switch every time one synthesises the stacks.

Environment

• CDK CLI Version: 1.8
• OS: all
• Language: all

Previously filed request

https://github.com/aws/aws-cdk/issues/3982

[eladb]

Hey guys, sorry I am late for the discussion… @PeterBengtson I am still not sure I understand if we are talking about physical names or logical names.

If this is about physical names, we are limited to what we can do since CloudFormation generates physical names during deployment. In most cases, those names are derived from the logical names (and therefore sometimes remind people of the logical name) but in other cases they are completely opaque. Specifying explicit physical names in CFN templates is an anti-pattern and not a recommended practice. Resources that use physical names cannot be replaced during updates and cause all kinds of headaches when it comes to reusability and composability (i.e. you can’t use the same construct twice).

If this is about logical names, the official way to customize logical names is to override allocateLogicalId and provide an alternative behavior. You can easily implement something like what you suggested using this approach and context:

export class BaseStack extends Stack {
  public allocateLogicalId(element: CfnElement) {
    const orig = super.allocateLogicalId(element);
    const prefix = this.node.tryGetContext('prefix');
    return prefix ? prefix + orig : orig;
   }
}

Then, you can specify a prefix through the CLI:

$ cdk synth -c prefix="MyTeam"

This will cause all logical names to have a prefix MyTeam.

I’ve submitted a pull requests to the aws-cdk-examples with a full example.

[hoegertn]

@rhboyd that is my main concern when creating names. And if CDK provides an out-of-the-box solution it will be misused at some point in time. If prefixes for the stack are ok this solves your request without any change to CDK. Be aware that not all resources use the stackname in the generated name (eg RDS)