Secrets Manager vs Parameter Store: rotation, cost and limits

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. An application runs in three Regions and reads one database credential. Security requires the credential to rotate automatically, and the application teams require a local read in each Region with no cross-Region call. Nobody wants to operate rotation code in three places. Which solution meets these requirements?

   Right. In the game that’s Renown for your Design Secure Architectures building.

   Not that one: D is right. In the game your Design Secure Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Store the credential in each Region as a Parameter Store SecureString, rotated by a nightly job.Parameter Store has no built-in rotation, so the nightly job is rotation code to operate in three places.Your answerB.Turn on rotation for the primary secret, and have the other Regions' applications read it cross-Region.A cross-Region read is the latency the application teams ruled out, and replication exists to avoid it.Your answerC.Replicate the secret to the three Regions, and turn on rotation separately in each Region's replica.Rotation is configured on the primary and propagates; configuring it per replica is the work the feature removes.The answerD.Turn on rotation for the primary secret and replicate it, since the new value propagates to the replicas.One rotation, three local reads, and the documentation joins the two halves itself. Replication gives the local read: "you can replicate your secrets in multiple AWS Regions to support applications spread across those Regions to meet Regional access and low latency requirements"

   Show the full explanation and doc quotes

   With "the ARN for a replicated secret... the same as the primary secret except for the Region." Rotation stays in one place: "if you turn on rotation for your primary secret, Secrets Manager rotates the secret in the primary Region, and the new secret value propagates to all of the associated replica secrets. You don't have to manage rotation individually for all of the replica secrets." And the rotation itself need not be code the team owns - for most managed secrets "you use managed rotation, where the service configures and manages rotation for you. Managed rotation doesn't use a Lambda function."

   Written from docs.aws.amazon.com/secretsmanager/latest/userguide/replicate-secrets.html

2. A role in a second account must read one database credential held in Secrets Manager in the first account. The secret is currently encrypted with the AWS managed key for Secrets Manager, and a resource policy naming the role has been attached, but every GetSecretValue call still fails. Which solution meets these requirements?

   Right. In the game that’s Renown for your Design Secure Architectures building.

   Not that one: C is right. In the game your Design Secure Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Replicate the secret into the second account so that the role reads a local copy of it rather than crossing an account boundary.Replication copies the secret and its rotation problem into another account rather than granting access to the one that exists.Your answerB.Re-encrypt the secret with a customer managed KMS key and allow the role kms:Decrypt in that key's policy.The key is fixed, but a role in another account still needs its own identity policy allowing the actions.The answerC.Re-encrypt with a customer managed key allowing the role kms:Decrypt, and add an identity policy in the second account.A cross-account secret read needs three policies, and two of them are missing here. The key is the first: "you must also allow the identity to use the KMS key that the secret is encrypted with. This is because you can't use the AWS managed key (aws/secretsmanager) for cross-account access. Instead, you must encrypt your secret with a KMS key that you create, and then attach a key policy to it."Your answerD.Add an identity policy in the second account allowing secretsmanager:GetSecretValue on the secret's ARN.The identity policy is necessary and not sufficient: the AWS managed key cannot be used across accounts at all.

   Show the full explanation and doc quotes

   The identity is the second: the documented sequence is a resource policy on the secret in Account1, a statement in the KMS key policy in Account1 allowing kms:Decrypt and kms:DescribeKey, and "an identity policy to the identity in Account2" allowing secretsmanager:GetSecretValue and kms:Decrypt on the two ARNs.

   Written from docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html

3. A deployment reads three values from Parameter Store: a list of subnet IDs, an endpoint URL, and an account identifier that a compliance rule says must not be readable in plaintext by anyone browsing the console. Which solution meets these requirements?

   Right. In the game that’s Renown for your Design Secure Architectures building.

   Not that one: B is right. In the game your Design Secure Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Store the subnets and the URL as Strings, and keep the account identifier in Secrets Manager.Parameter Store does encrypt values, through the SecureString type and AWS KMS.The answerB.Store the subnets as a StringList, the URL as a String, and the account identifier as a SecureString encrypted with AWS KMS.One type per value, chosen by what the value is. "String - Use this type for plain text values, such as environment names, endpoint URLs, or resource identifiers. StringList - Use this type for a comma-separated list of plain-text values. For example, you could store the value subnet-123abc,subnet-456def,subnet-789ghi. SecureString - Use SecureString for configuration values that require encryption, such as service endpoints and account identifiers." The compliance rule is about the stored value rather than about who may call the API, which is what makes SecureString the answer rather than a policy.Your answerC.Store all three as SecureStrings, because a StringList cannot hold comma-separated values once encryption is required.The types are chosen per parameter; a list does not have to become a secret because one other value does.Your answerD.Store the subnets as a StringList, the URL as a String, and the account identifier as a policy-restricted String.A policy governs who may read the parameter; the value is still stored in plain text.

   Written from docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html