Description

Kubernetes has a pretty strict constraints for names of resources based in RFC 1123 and RFC 1035 spec:
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

For example it prevents using capital letters in names, so during cdk deploy I'm getting following error:

4:06:08 PM | CREATE_FAILED        | Custom::AWSCDK-EKS-KubernetesResource | eksbaserolestestin...ntResource2D5932A8
Received response status [FAILED] from custom resource. Message returned: Error: b'The ServiceAccount "testing-s3-list-NEW" is invalid: metadata.name: Invalid value: "testing-s3-list-NEW": a lowercase RFC 1123 subdomain must consist of lower
case alphanumeric characters, \'-\' or \'.\', and must start and end with an alphanumeric character (e.g. \'example.com\', regex used for validation is \'[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\')\n'

Use Case

When creating EKS cluster I'd like to get feedback that my names are correct at writing / compiling phase, not at deploy phase.

Proposed Solution

EKS module could expect the types that conform to K8s constraints, instead of using strings type hints. For example name and namespace could be a DomainName type (not string) in the following call:

class DomainName extends String {
  constructor(value: string) {
    // TODO: Implement validation.
    super(value);
  }
}

// Inside CDK constructor:
    const sa = cluster.addServiceAccount('testing', {
      name: new DomainName('testing'),
      namespace: 'default',
    });

As a consequence type of name property would have to be altered. This is an exported interface, which makes it breaking change, right?
https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-eks/lib/service-account.ts#L19

I'm new to TypeScript, but I guess it would be a breaking change from SemVer perspective.

Other information

Since I've been bitten by this few times already I'm considering writing decorator / wrapper for some CDK constructs to get names validation at compilation phase.

Would be great to have that in CDK, but I realize that might be a breaking change. I'm open for discussion here and willing to try to implement this (with some guidance).

Acknowledge

• I may be able to implement this feature request
• This feature might incur a breaking change