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

feat: introduce "node.addr" (deprecates "uniqueId") #314

Merged
merged 3 commits into from
Oct 26, 2020
Merged

Conversation

eladb
Copy link
Contributor

@eladb eladb commented Oct 25, 2020

The uniqueId property has a few issues:

  1. It uses MD5 which is not FIPS-compliant (fixes crypto.createHash('md5') fails in a FIPS-enabled environment #272)
  2. It has a variable length of up to 255 chars which may not be suitable in certain domains (e.g. k8s label names are limited to 63 characters).
  3. The human-readable portion of uniqueId is sometimes confusing and in many cases does not offer sufficient value.
  4. Its charset might be restrictive or too broad for certain domains.

To that end, we introduce node.addr as an alternative to uniqueId. It returns a 42 character hexadecimal, lowercase and opaque address for a construct which is unique within the tree (app). The address is calculated using SHA-1 which is FIPS-compliant.

For example:

c83a2846e506bcc5f10682b564084bca2d275709ee

Similar to uniqueId, addr intentionally skips any path components called Default to allow refactoring of construct trees which preserve names within the tree.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

The `uniqueId` property has a few issues:

1. It uses MD5 which is not FIPS-compliant (fixes #273)
2. They have variable length of up to 255 chars which may not be suitable in certain domains (e.g. k8s label names are limited to 63 characters).
3. The human-readable portion of `uniqueId` is sometimes confusing and in many cases does not offer sufficient value.
4. Their charset might be restrictive or too broad for certain domains.

To that end, we introduce `node.addr` as an alternative to `uniqueId`. It returns a 42 character hexadecimal, lowercase and opaque address for a construct which is unique within the tree (app). The address is calculated using SHA-1 which is FIPS-compliant.

For example:

    c83a2846e506bcc5f10682b564084bca2d275709ee

Similar to `uniqueId`, `addr` intentionally skips any path components called `default` (case insensitive) to allow refactoring of construct trees which preserve names within the tree.
@eladb eladb changed the title feat: node.addr (deprecates node.uniqueId) feat: introduce "node.addr" (deprecates "uniqueId") Oct 25, 2020
@eladb eladb mentioned this pull request Oct 25, 2020
@rix0rrr
Copy link
Contributor

rix0rrr commented Oct 26, 2020

Isn't it better to allow customizing the addressing strategy at the root, in some way?

I don't see the point in deprecating uniqueId; the AWS CDK will never be able to switch away from it anyway, so that will stick us with invoking a deprecated API for eternity.

How does this change interact with people using AWS CDK EKS+cdk8s in the same program? What if they want to FIPS-ify their setup similarly in that scenario (whatever that means)?

@eladb
Copy link
Contributor Author

eladb commented Oct 26, 2020

The idea is that resource naming strategy is left to the domain, but that strategy can use addr to formulate a unique name (eg by appending the address).

As for deprecating uniqueId: my plan is that in 2.0 we will move the implementation to the AWS CDK to support legacy usage but remove from constructs 10.x and future usage in AWS CDK. Makes sense?

@mergify mergify bot merged commit 754a84d into master Oct 26, 2020
@mergify mergify bot deleted the benisrae/addr branch October 26, 2020 12:12
eladb pushed a commit to aws/aws-cdk that referenced this pull request Oct 28, 2020
The property `node.uniqueId` is used throughout our codebase to generate unique names. We are planning to deprecate this API in constructs 10.x (and CDK 2.0) in favor of a `node.addr` (see aws/constructs#314).

In most cases, these generated names cannot be changed because they will incur breaking changes to deployments. So we have to continue to use the "legacy" unique ID in those cases (new cases should use `addr`).

To that end, we introduce a utility `Legacy.uniqueId()` which uses the legacy algorithm and the code base was migrated to use it instead of `node.uniqueId` which will go away soon.
eladb pushed a commit to aws/aws-cdk that referenced this pull request Oct 29, 2020
The property `node.uniqueId` is used throughout our codebase to generate unique names. We are planning to deprecate this API in constructs 10.x (and CDK 2.0) in favor of a `node.addr` (see aws/constructs#314).

In most cases, these generated names cannot be changed because they will incur breaking changes to deployments. So we have to continue to use the "legacy" unique ID in those cases (new cases should use `addr`).

To that end, we introduce a utility `Legacy.uniqueId()` which uses the legacy algorithm and the code base was migrated to use it instead of `node.uniqueId` which will go away soon.
mergify bot pushed a commit to aws/aws-cdk that referenced this pull request Nov 3, 2020
…Id" (#11166)

The property `node.uniqueId` is used throughout our codebase to generate unique names. We are planning to deprecate this API in constructs 10.x (and CDK 2.0) in favor of a `node.addr` (see aws/constructs#314).

In most cases, these generated names cannot be changed because they will incur breaking changes to deployments. So we have to continue to use the "legacy" unique ID in those cases (new cases should use `addr`).

To that end, we introduce a utility `Legacy.uniqueId()` which uses the legacy algorithm and the code base was migrated to use it instead of `node.uniqueId` which will go away soon.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
eladb pushed a commit to cdk8s-team/cdk8s that referenced this pull request Nov 18, 2020
The CDK8s name generator (`Names.toLabelValue()` and `Names.toDnsLabel()`) have used sha256, which cannot be used in environments that are FIPS compliant.

To fix this, we are now using the [recently introduced](aws/constructs#314) `Node.of(construct).addr` as the hash postfix of generated names.

Fixes #334

BREAKING CHANGE: CAUTION! Auto-generated resource names will change with this release. Resource names in manifests synthesized by a previous version of the CDK8s will be invalidated. Deploying new manifests will cause **resources to be replaced**. Temporarily, you can opt to use the legacy hashing mechanism by setting the environment variable `CDK8S_LEGACY_HASH=1`.
* **core:** `Names.toDnsLabel()` now accepts a construct scope instead of a string path, and a set of options instead of `maxLen`.
* **core:** `Names.toLabelValue()` now accepts a construct scope instead of a string path, and a set of options instead of `maxLen`.
mergify bot pushed a commit to cdk8s-team/cdk8s that referenced this pull request Nov 19, 2020
The CDK8s name generator (`Names.toLabelValue()` and `Names.toDnsLabel()`) have used sha256, which cannot be used in environments that are FIPS compliant.

To fix this, we are now using the [recently introduced](aws/constructs#314) `Node.of(construct).addr` as the hash postfix of generated names.

Fixes #334

BREAKING CHANGE: CAUTION! Auto-generated resource names will change with this release. Resource names in manifests synthesized by a previous version of the CDK8s will be invalidated. Deploying new manifests will cause **resources to be replaced**. Temporarily, you can opt to use the legacy hashing mechanism by setting the environment variable `CDK8S_LEGACY_HASH=1`.
* **lib:** `Names.toDnsLabel()` now accepts a construct scope instead of a string path, and a set of options instead of `maxLen`.
* **lib:** `Names.toLabelValue()` now accepts a construct scope instead of a string path, and a set of options instead of `maxLen`.

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@jimr6007
Copy link

jimr6007 commented May 23, 2023

what about the node.addr at the very top of the tree for the cdk.App()

import * as cdk from 'aws-cdk-lib';

const app1 = new cdk.App();
console.log(app1.node.addr)

const app2 = new cdk.App();
console.log(app2.node.addr)

Can I safely assume that this addr of the App itself will always be unique?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

crypto.createHash('md5') fails in a FIPS-enabled environment
3 participants