-
Notifications
You must be signed in to change notification settings - Fork 20
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
chore(.NET): update hierarchy examples #618
base: mainline
Are you sure you want to change the base?
Conversation
// It may take a couple minutes for the table to become ACTIVE, | ||
// at which point it is ready to store branch and beacon keys. | ||
|
||
// keyStore.CreateKeyStore(new CreateKeyStoreInput()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Why should we not run this?
The Description of in 2 states that IF the table already exists,
it will validate the table.
Therefore, it SHOULD BE safe to run this,
as it will NOT create a table.
Though we may need to grant the CI Role Describe Table permission.
AwsEncryptionSDK/runtimes/net/Examples/Keyring/AwsKmsHierarchical/AwsKmsHierarchicalKeyring.cs
Outdated
Show resolved
Hide resolved
AwsEncryptionSDK/runtimes/net/Examples/Keyring/AwsKmsHierarchical/AwsKmsHierarchicalKeyring.cs
Outdated
Show resolved
Hide resolved
// Only the branch key will be rotated. | ||
// This rotation is eventually consistent. See the VersionBranchKey | ||
// Example for how to version a branch key. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue: Can you describe Version as Rotate?
It is implied here, but not explicitly said.
AwsEncryptionSDK/runtimes/net/Examples/Keyring/AwsKmsHierarchical/AwsKmsHierarchicalKeyring.cs
Show resolved
Hide resolved
/// This example requires access to the DDB Table where you are storing the Branch Keys. | ||
/// This table must be configured with the following | ||
/// primary key configuration: | ||
/// - Partition key is named "partition_key" with type (S) | ||
/// - Sort key is named "sort_key" with type (S) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
If we are not going to create or version branch keys,
we do not need write permission.
/// This example requires access to the DDB Table where you are storing the Branch Keys. | |
/// This table must be configured with the following | |
/// primary key configuration: | |
/// - Partition key is named "partition_key" with type (S) | |
/// - Sort key is named "sort_key" with type (S) | |
/// This example requires read access to the DDB Table | |
/// where you are storing the Branch Keys. | |
/// primary key configuration: | |
/// - Partition key is named "partition_key" with type (S) | |
/// - Sort key is named "sort_key" with type (S) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although the example won't create or version, someone reading this example and trying to run it won't know what permissions they need to successfully run the example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
someone reading this example and trying to run it won't know what permissions they need to successfully run the example
Yes. Hence my suggestion that we document it.
In meetings, we have celebrated the Permission Boundary of the H-Keyring
and Key Store.
The Key Store implicitly supports two levels of Actors:
- Keyring Users : Read the Table, Decrypt from KMS
- Key Store Admins : Read and Write to the table; Generate, ReEncrypt, Decrypt from KMS
I do not want to bother documenting all of that here.
We could, and we SHOULD, one day, document all of this.
For now, we can imply this Actor distinction to our customers in this example.
After all,
this Example does NOT include any Branch Key Creation or Version calls,
commented out or otherwise.
...ntimes/net/Examples/Keyring/AwsKmsHierarchical/AwsKmsHierarchicalKeyringBranchKeySupplier.cs
Outdated
Show resolved
Hide resolved
AwsEncryptionSDK/runtimes/net/Examples/Keyring/AwsKmsHierarchical/AwsKmsHierarchicalKeyring.cs
Outdated
Show resolved
Hide resolved
AwsEncryptionSDK/runtimes/net/Examples/Keyring/AwsKmsHierarchical/AwsKmsHierarchicalKeyring.cs
Show resolved
Hide resolved
// 4. Create the Hierarchical Keyring, using the Branch Key ID Supplier above. | ||
// With this configuration, the AWS SDK Client ultimately configured will be capable | ||
// of encrypting or decrypting items for either tenant (assuming correct KMS access). | ||
// We are restricting the keyring to only branch key by statically configuring | ||
// it with a branch key id. For an examples on how to decide on which branch key to | ||
// use see the `AwsKmsHierarchicalKeyringBranhcKeySupplier` example in this directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// 4. Create the Hierarchical Keyring, using the Branch Key ID Supplier above. | |
// With this configuration, the AWS SDK Client ultimately configured will be capable | |
// of encrypting or decrypting items for either tenant (assuming correct KMS access). | |
// We are restricting the keyring to only branch key by statically configuring | |
// it with a branch key id. For an examples on how to decide on which branch key to | |
// use see the `AwsKmsHierarchicalKeyringBranhcKeySupplier` example in this directory. | |
// 4. Create the Hierarchical Keyring, with a static Branch Key ID. | |
// With this configuration, the AWS SDK Client ultimately configured will be capable | |
// of encrypting or decrypting items for either tenant (assuming correct KMS access). | |
// We are restricting the keyring to only branch key by statically configuring | |
// it with a branch key id. For an examples on how to decide on which branch key to | |
// use see the `AwsKmsHierarchicalKeyringBranhcKeySupplier` example in this directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: Link to our docs.
https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/use-hierarchical-keyring.html
// 8. Rotate the Branch Key in our KeyStore. | ||
// Only the branch key will be rotated. | ||
// This rotation is eventually consistent. See the VersionBranchKey | ||
// Example for how to rotate a branch key. | ||
// To rotate a branch key you need: | ||
// - "dynamodb:GetItem" | ||
// - "kms:ReEncrypt*" | ||
// - "kms:GenerateDataKeyWithoutPlaintext" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: Link to our docs.
The VersionBranchKey file and these comments do not explain
what rotation or an active branch key is.
We could add all that content here or in the other file.
Or we could link to our docs.
// 8. Rotate the Branch Key in our KeyStore. | |
// Only the branch key will be rotated. | |
// This rotation is eventually consistent. See the VersionBranchKey | |
// Example for how to rotate a branch key. | |
// To rotate a branch key you need: | |
// - "dynamodb:GetItem" | |
// - "kms:ReEncrypt*" | |
// - "kms:GenerateDataKeyWithoutPlaintext" | |
// 8. Rotate the Branch Key in our KeyStore. | |
// Only the branch key will be rotated. | |
// This rotation is eventually consistent. | |
// See the VersionBranchKey for a narrower example. | |
// See the Developer Guide for details: https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/use-hierarchical-keyring.html#rotate-branch-key | |
// Example for how to rotate a branch key. | |
// To rotate a branch key you need: | |
// - "dynamodb:GetItem" | |
// - "kms:ReEncrypt*" | |
// - "kms:GenerateDataKeyWithoutPlaintext" |
/// This example requires access to the DDB Table where you are storing the Branch Keys. | ||
/// This table must be configured with the following | ||
/// primary key configuration: | ||
/// - Partition key is named "partition_key" with type (S) | ||
/// - Sort key is named "sort_key" with type (S) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
someone reading this example and trying to run it won't know what permissions they need to successfully run the example
Yes. Hence my suggestion that we document it.
In meetings, we have celebrated the Permission Boundary of the H-Keyring
and Key Store.
The Key Store implicitly supports two levels of Actors:
- Keyring Users : Read the Table, Decrypt from KMS
- Key Store Admins : Read and Write to the table; Generate, ReEncrypt, Decrypt from KMS
I do not want to bother documenting all of that here.
We could, and we SHOULD, one day, document all of this.
For now, we can imply this Actor distinction to our customers in this example.
After all,
this Example does NOT include any Branch Key Creation or Version calls,
commented out or otherwise.
// This will NOT create a Key Store but check that the configured table name exists and it validates | ||
// its construction. In order to check the construction is correct the configured IAM role | ||
// MUST have `DescribeTable` permission on the Key Store resource. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
Semantic Line Breaks, grammar fixes,
& tighter phrasing to remove the other comment.
// This will NOT create a Key Store but check that the configured table name exists and it validates | |
// its construction. In order to check the construction is correct the configured IAM role | |
// MUST have `DescribeTable` permission on the Key Store resource. | |
// Since AWS Crypto Tool's Example table already exists, | |
// this will NOT create a Key Store | |
// but check that the configured table name exists | |
// and validate the table's index configuration. | |
// In order to check this configuration, | |
// the IAM role MUST have `DescribeTable` permission on | |
// the Key Store table. |
// We have already created a Table with the specified configuration. | ||
// For testing purposes we will not create a table when we run this example. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// We have already created a Table with the specified configuration. | |
// For testing purposes we will not create a table when we run this example. |
// 4. Create the Hierarchical Keyring, with a static Branch Key ID. | ||
// With this configuration, the AWS SDK Client ultimately configured will be capable | ||
// of encrypting or decrypting items for either tenant (assuming correct KMS access). | ||
// We are restricting the keyring to only branch key by statically configuring | ||
// it with a branch key id. For an examples on how to decide on which branch key to | ||
// use see the `AwsKmsHierarchicalKeyringBranhcKeySupplier` example in this directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion/Issue:
Do not mention tenants here.
This is a static configuration of one Branch Key ID.
It is not really a Multi-tenant scenario.
// 4. Create the Hierarchical Keyring, with a static Branch Key ID. | |
// With this configuration, the AWS SDK Client ultimately configured will be capable | |
// of encrypting or decrypting items for either tenant (assuming correct KMS access). | |
// We are restricting the keyring to only branch key by statically configuring | |
// it with a branch key id. For an examples on how to decide on which branch key to | |
// use see the `AwsKmsHierarchicalKeyringBranhcKeySupplier` example in this directory. | |
// 4. Create the Hierarchical Keyring, with a static Branch Key ID. | |
// This restricts the keyring to | |
// only one branch key by | |
// statically configuring it with a Branch Key ID. | |
// For a demonstration of Multi Branch Key support, | |
// see the `AwsKmsHierarchicalKeyringBranhcKeySupplier` example in this directory. |
// KMS config in the keystore and therefore MUST have the right permissions. | ||
BranchKeyIdSupplier = branchKeySupplier, | ||
KeyStore = keyStore, | ||
BranchKeyId = branchKeyId, | ||
// The value provided to `EntryCapacity` dictates how many branch keys will be held locally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue: Is this true?
I think that multiple of versions of the same Branch Key
count towards the Entry Capacity.
// The value provided to `EntryCapacity` dictates how many branch keys will be held locally | |
// The value provided to `EntryCapacity` dictates how many branch key versions will be held locally |
// See the VersionBranchKey for a narrower example. | ||
// See the Developer Guide for details: | ||
// https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/use-hierarchical-keyring.html#rotate-branch-key | ||
// Example for how to rotate a branch key. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Example for how to rotate a branch key. |
// To rotate a branch key you need: | ||
// - "dynamodb:GetItem" | ||
// - "kms:ReEncrypt*" | ||
// - "kms:GenerateDataKeyWithoutPlaintext" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// To rotate a branch key you need: | |
// - "dynamodb:GetItem" | |
// - "kms:ReEncrypt*" | |
// - "kms:GenerateDataKeyWithoutPlaintext" | |
// To rotate a branch key you need: | |
// - "dynamodb:ConditionCheckItem" | |
// - "dynamodb:GetItem" | |
// - "dynamodb:PutItem" | |
// - "kms:ReEncrypt*" | |
// - "kms:GenerateDataKeyWithoutPlaintext" |
Issue #, if available:
Description of changes:
Updates Hierarchy Keyring examples to include more comments and to have an explicit example on how to create a key store, create a branch key, version a branch key, and encrypt and decrypt using a statically configured hierarchy keyring
Squash/merge commit message, if applicable:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.