AWS KMS condition keys

AWS KMS provides a set of condition keys that you can use in key policies and IAM policies. These condition keys are specific to AWS KMS. For example, you can use the kms:EncryptionContext:context-key condition key to require a particular encryption context when controlling access to a symmetric encryption KMS key.

Conditions for an API operation request

Many AWS KMS condition keys control access to a KMS key based on the value of a parameter in the request for an AWS KMS operation. For example, you can use the kms:KeySpec condition key in an IAM policy to allow use of the CreateKey operation only when the value of the KeySpec parameter in the CreateKey request is RSA_4096.

This type of condition works even when the parameter doesn't appear in the request, such as when you use the parameter's default value. For example you can use the kms:KeySpec condition key to allow users to use the CreateKey operation only when the value of the KeySpec parameter is SYMMETRIC_DEFAULT, which is the default value. This condition allows requests that have the KeySpec parameter with the SYMMETRIC_DEFAULT value and requests that have no KeySpec parameter.

Conditions for KMS keys used in API operations

Some AWS KMS condition keys can control access to operations based on a property of the KMS key that is used in the operation. For example, you can use the kms:KeyOrigin condition to allow principals to call GenerateDataKey on a KMS key only when the Origin of the KMS key is AWS_KMS. To find out if a condition key can be used in this way, see the description of the condition key.

The operation must be a KMS key resource operation, that is, an operation that is authorized for a particular KMS key. To identify the KMS key resource operations, in the Actions and Resources Table, look for a value of KMS key in the Resources column for the operation. If you use this type of condition key with an operation that is not authorized for a particular KMS key resource, like ListKeys, the permission is not effective because the condition can never be satisfied. There is no KMS key resource involved in authorizing the ListKeys operation and no KeySpec property.

The following topics describe each AWS KMS condition key and include example policy statements that demonstrate policy syntax.

Using set operators with condition keys

When a policy condition compares two set of values, such as the set of tags in a request and the set of tags in a policy, you need tell AWS how to compare the sets. IAM defines two set operators, ForAnyValue and ForAllValues, for this purpose. Use set operators only with multi-valued condition keys, which require them. Do not use set operators with single-valued condition keys. As always, test your policy statements thoroughly before using them in a production environment.

Condition keys are single-valued or multi-valued. To determine whether an AWS KMS condition key is single-valued or multi-valued, see the Value type column in the condition key description.

Note that the difference between single-valued and multi-valued condition keys depends on the number of values in the authorization context; not the number of values in the policy condition.

For detailed information about the ForAnyValue and ForAllValues set operators, see Using multiple keys and values in the IAM User Guide. For information about the risk of using the ForAllValues set operator with a single-valued condition, see Security Warning – ForAllValues with single valued key in the IAM User Guide.

kms:BypassPolicyLockoutSafetyCheck

The kms:BypassPolicyLockoutSafetyCheck condition key controls access to the CreateKey and PutKeyPolicy operations based on the value of the BypassPolicyLockoutSafetyCheck parameter in the request.

The following example IAM policy statement prevents users from bypassing the policy lockout safety check by denying them permission to create KMS keys when the value of the BypassPolicyLockoutSafetyCheck parameter in the CreateKey request is true.

{
  "Effect": "Deny",
  "Action": [
    "kms:CreateKey",
    "kms:PutKeyPolicy"
  ],
  "Resource": "*",
  "Condition": {
    "Bool": {
      "kms:BypassPolicyLockoutSafetyCheck": true
    }
  }
}

You can also use the kms:BypassPolicyLockoutSafetyCheck condition key in an IAM policy or key policy to control access to the PutKeyPolicy operation. The following example policy statement from a key policy prevents users from bypassing the policy lockout safety check when changing the policy of a KMS key.

Instead of using an explicit Deny, this policy statement uses Allow with the Null condition operator to allow access only when the request does not include the BypassPolicyLockoutSafetyCheck parameter. When the parameter is not used, the default value is false. This slightly weaker policy statement can be overridden in the rare case that a bypass is necessary.

{
  "Effect": "Allow",
  "Action": "kms:PutKeyPolicy",
  "Resource": "*",
  "Condition": {
    "Null": {
      "kms:BypassPolicyLockoutSafetyCheck": true
    }
  }
}

See also

kms:CallerAccount

You can use this condition key to allow or deny access to all identities (users and roles) in an AWS account. In key policies, you use the Principal element to specify the identities to which the policy statement applies. The syntax for the Principal element does not provide a way to specify all identities in an AWS account. But you can achieve this effect by combining this condition key with a Principal element that specifies all AWS identities.

You can use it to control access to any KMS key resource operation, that is, any AWS KMS operation that uses a particular KMS key. To identify the KMS key resource operations, in the Actions and Resources Table, look for a value of KMS key in the Resources column for the operation. It is also valid for operations that manage custom key stores.

For example, the following key policy statement demonstrates how to use the kms:CallerAccount condition key. This policy statement is in the key policy for the AWS managed key for Amazon EBS. It combines a Principal element that specifies all AWS identities with the kms:CallerAccount condition key to effectively allow access to all identities in AWS account 111122223333. It contains an additional AWS KMS condition key (kms:ViaService) to further limit the permissions by only allowing requests that come through Amazon EBS. For more information, see kms:ViaService.

{
  "Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
  "Effect": "Allow",
  "Principal": {"AWS": "*"},
  "Condition": {
    "StringEquals": {
      "kms:CallerAccount": "111122223333",
      "kms:ViaService": "ec2.us-west-2.amazonaws.com"
    }
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:CreateGrant",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}

kms:CustomerMasterKeySpec (deprecated)

The kms:CustomerMasterKeySpec condition key is deprecated. Instead, use the kms:KeySpec condition key.

The kms:CustomerMasterKeySpec and kms:KeySpec condition keys work the same way. Only the names differ. We recommend that you use kms:KeySpec. However, to avoid breaking changes, AWS KMS supports both condition keys.

kms:CustomerMasterKeyUsage (deprecated)

The kms:CustomerMasterKeyUsage condition key is deprecated. Instead, use the kms:KeyUsage condition key.

The kms:CustomerMasterKeyUsage and kms:KeyUsage condition keys work the same way. Only the names differ. We recommend that you use kms:KeyUsage. However, to avoid breaking changes, AWS KMS supports both condition keys.

kms:DataKeyPairSpec

You can use this condition key to control access to the GenerateDataKeyPair and GenerateDataKeyPairWithoutPlaintext operations based on the value of the KeyPairSpec parameter in the request. For example, you can allow users to generate only particular types of data key pairs.

The following example key policy statement uses the kms:DataKeyPairSpec condition key to allow users to use the KMS key to generate only RSA data key pairs.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": [
    "kms:GenerateDataKeyPair",
    "kms:GenerateDataKeyPairWithoutPlaintext"
  ],
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "kms:DataKeyPairSpec": "RSA*"
    }
  }
}

See also

kms:EncryptionAlgorithm

You can use the kms:EncryptionAlgorithm condition key to control access to cryptographic operations based on the encryption algorithm that is used in the operation. For the Encrypt, Decrypt, and ReEncrypt operations, it controls access based on the value of the EncryptionAlgorithm parameter in the request. For operations that generate data keys and data key pairs, it controls access based on the encryption algorithm that is used to encrypt the data key.

This condition key has no effect on operations performed outside of AWS KMS, such as encrypting with the public key in an asymmetric KMS key pair outside of AWS KMS.

EncryptionAlgorithm parameter in a request

To allow users to use only a particular encryption algorithm with a KMS key, use a policy statement with a Deny effect and a StringNotEquals condition operator. For example, the following example key policy statement prohibits principals who can assume the ExampleRole role from using this KMS key in the specified cryptographic operations unless the encryption algorithm in the request is RSAES_OAEP_SHA_256, an asymmetric encryption algorithm used with RSA KMS keys.

Unlike a policy statement that allows a user to use a particular encryption algorithm, a policy statement with a double-negative like this one prevents other policies and grants for this KMS key from allowing this role to use other encryption algorithms. The Deny in this key policy statement takes precedence over any key policy or IAM policy with an Allow effect, and it takes precedence over all grants for this KMS key and its principals.

{
  "Sid": "Allow only one encryption algorithm with this asymmetric KMS key",
  "Effect": "Deny",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "kms:EncryptionAlgorithm": "RSAES_OAEP_SHA_256"
    }
  }
}

Encryption algorithm used for the operation

You can also use the kms:EncryptionAlgorithm condition key to control access to operations based on the encryption algorithm used in the operation, even when the algorithm isn't specified in the request. This allows you to require or forbid the SYMMETRIC_DEFAULT algorithm, which might not be specified in a request because it's the default value.

This feature lets you use the kms:EncryptionAlgorithm condition key to control access to the operations that generate data keys and data key pairs. These operations use only symmetric encryption KMS keys and the SYMMETRIC_DEFAULT algorithm.

For example, this IAM policy limits its principals to symmetric encryption. It denies access to any KMS key in the example account for cryptographic operations unless the encryption algorithm specified in the request or used in the operation is SYMMETRIC_DEFAULT. Including GenerateDataKey* adds GenerateDataKey, GenerateDataKeyWithoutPlaintext, GenerateDataKeyPair, and GenerateDataKeyPairWithoutPlaintext to the permissions. The condition has no effect on these operations because they always use a symmetric encryption algorithm.

{
  "Sid": "AllowOnlySymmetricAlgorithm",
  "Effect": "Deny",
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*"
  ],
  "Resource": "arn:aws:kms:us-west-2:111122223333:key/*",
  "Condition": {
    "StringNotEquals": {
      "kms:EncryptionAlgorithm": "SYMMETRIC_DEFAULT"
    }
  }
}

See also

kms:EncryptionContext:context-key

You can use the kms:EncryptionContext:context-key condition key to control access to a symmetric encryption KMS key based on the encryption context in a request for a cryptographic operation. Use this condition key to evaluate both the key and the value in the encryption context pair. To evaluate only the encryption context keys or require an encryption context regardless of keys or values, use the kms:EncryptionContextKeys condition key.

You cannot specify an encryption context in a cryptographic operation with an asymmetric KMS key or an HMAC KMS key. Asymmetric algorithms and MAC algorithms do not support an encryption context.

To use the kms:EncryptionContext:context-key condition key, replace the context-key placeholder with the encryption context key. Replace the context-value placeholder with the encryption context value.

"kms:EncryptionContext:context-key": "context-value"

For example, the following condition key specifies an encryption context in which the key is AppName and the value is ExampleApp (AppName = ExampleApp).

"kms:EncryptionContext:AppName": "ExampleApp"

This is a single-valued condition key. The key in the condition key specifies a particular encryption context key (context-key). Although you can include multiple encryption context pairs in each API request, the encryption context pair with the specified context-key can have only one value. For example, the kms:EncryptionContext:Department condition key applies only to encryption context pairs with a Department key, and any given encryption context pair with the Department key can have only one value.

Do not use a set operator with the kms:EncryptionContext:context-key condition key. If you create a policy statement with an Allow action, the kms:EncryptionContext:context-key condition key, and the ForAllValues set operator, the condition allows requests with no encryption context and requests with encryption context pairs that are not specified in the policy condition.

To require a particular encryption context pair, use the kms:EncryptionContext:context-key condition key with the StringEquals operator .

The following example key policy statement allows principals who can assume the role to use the KMS key in a GenerateDataKey request only when the encryption context in the request includes the AppName:ExampleApp pair. Other encryption context pairs are permitted.

The key name is not case sensitive. The case sensitivity of the value is determined by the condition operator, such as StringEquals. For details, see Case sensitivity of the encryption context condition.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:GenerateDataKey",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:AppName": "ExampleApp"
    }
  }
}

To require an encryption context pair and forbid all other encryption context pairs, use both kms:EncryptionContext:context-key and kms:EncryptionContextKeys in the policy statement. The following key policy statement uses the kms:EncryptionContext:AppName condition to require the AppName=ExampleApp encryption context pair in the request. It also uses a kms:EncryptionContextKeys condition key with the ForAllValues set operator to allow only the AppName encryption context key.

The ForAllValues set operator limits encryption context keys in the request to AppName. If the kms:EncryptionContextKeys condition with the ForAllValues set operator was used alone in a policy statement, this set operator would allow requests with no encryption context. However, if the request had no encryption context, the kms:EncryptionContext:AppName condition would fail. For details about the ForAllValues set operator, see Using multiple keys and values in the IAM User Guide.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/KeyUsers"
  },
  "Action": "kms:GenerateDataKey",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:AppName": "ExampleApp"
    },
    "ForAllValues:StringEquals": {
      "kms:EncryptionContextKeys": [
        "AppName"
      ]
    }
  }
}  

You can also use this condition key to deny access to a KMS key for a particular operation. The following example key policy statement uses a Deny effect to forbid the principal from using the KMS key if the encryption context in the request includes a Stage=Restricted encryption context pair. This condition allows a request with other encryption context pairs, including encryption context pairs with the Stage key and other values, such as Stage=Test.

{
  "Effect": "Deny",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:GenerateDataKey",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:Stage": "Restricted"
    }
  }
}

Using multiple encryption context pairs

You can require or forbid multiple encryption context pairs. You can also require one of several encryption context pairs. For details about the logic used to interpret these conditions, see Creating a condition with multiple keys or values in the IAM User Guide.

To require multiple encryption context pairs, list the pairs in the same condition. The following example key policy statement requires two encryption context pairs, Department=IT and Project=Alpha. Because the conditions have different keys (kms:EncryptionContext:Department and kms:EncryptionContext:Project), they are implicitly connected by an AND operator. Other encryption context pairs are permitted, but not required.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:Decrypt",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:Department": "IT",
      "kms:EncryptionContext:Project": "Alpha"
    }
  }
}

To require one encryption context pair OR another pair, place each condition key in a separate policy statement. The following example key policy requires Department=IT or Project=Alpha pairs, or both. Other encryption context pairs are permitted, but not required.

{
 "Effect": "Allow",
 "Principal": {
  "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
 },
 "Action": "kms:GenerateDataKey",
 "Resource": "*",
 "Condition": {
  "StringEquals": {
   "kms:EncryptionContext:Department": "IT"
  }
 }
},
{
 "Effect": "Allow",
 "Principal": {
  "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
 },
 "Action": "kms:GenerateDataKey",
 "Resource": "*",
 "Condition": {
  "StringEquals": {
   "kms:EncryptionContext:Project": "Alpha"
  }
 }
}

To require particular encryption pairs and exclude all other encryption context pairs, use both kms:EncryptionContext:context-key and kms:EncryptionContextKeys in the policy statement. The following key policy statement uses the kms:EncryptionContext:context-key condition to require an encryption context with both Department=IT and Project=Alpha pairs. It uses a kms:EncryptionContextKeys condition key with the ForAllValues set operator to allow only the Department and Project encryption context keys.

The ForAllValues set operator limits encryption context keys in the request to Department and Project. If it were used alone in a condition, this set operator would allow requests with no encryption context, but in this configuration, the kms:EncryptionContext:context-key in this condition would fail.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:GenerateDataKey",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:Department": "IT",
      "kms:EncryptionContext:Project": "Alpha"
    },
    "ForAllValues:StringEquals": {
      "kms:EncryptionContextKeys": [
        "Department",
        "Project"
      ]
    }
  }
}  

You can also forbid multiple encryption context pairs. The following example key policy statement uses a Deny effect to forbid the principal from using the KMS keys if the encryption context in the request includes a Stage=Restricted or Stage=Production.pair.

Multiple values (Restricted and Production) for the same key (kms:EncryptionContext:Stage) are implicitly connected by a OR. For details, see Evaluation logic for conditions with multiple keys or values in the IAM User Guide.

{
  "Effect": "Deny",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:GenerateDataKey",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:Stage": [
         "Restricted",
         "Production"
      ] 
    }
  }
}

Case sensitivity of the encryption context condition

The encryption context that is specified in a decryption operation must be an exact, case-sensitive match for the encryption context that is specified in the encryption operation. Only the order of pairs in an encryption context with multiple pair can vary.

However, in policy conditions, the condition key is not case sensitive. The case sensitivity of the condition value is determined by the policy condition operator that you use, such as StringEquals or StringEqualsIgnoreCase.

As such, the condition key, which consists of the kms:EncryptionContext: prefix and the context-key replacement, is not case sensitive. A policy that uses this condition does not check the case of either element of the condition key. The case sensitivity of the value, that is, the context-value replacement, is determined by the policy condition operator.

For example, the following policy statement allows the operation when the encryption context includes an Appname key, regardless of its capitalization. The StringEquals condition requires that ExampleApp be capitalized as it is specified.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:Decrypt",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:Appname": "ExampleApp"
    }
  }
}

To require a case-sensitive encryption context key, use the kms:EncryptionContextKeys policy condition with a case-sensitive condition operator, such as StringEquals. In this policy condition, because the encryption context key is the value in this policy condition, its case sensitivity is determined by the condition operator.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:GenerateDataKey",
  "Resource": "*",
  "Condition": {
    "ForAnyValue:StringEquals": {
      "kms:EncryptionContextKeys": "AppName"
    }
  }
}

To require a case-sensitive evaluation of both the encryption context key and value, use the kms:EncryptionContextKeys and kms:EncryptionContext:context-key policy conditions together in the same policy statement. The case-sensitive condition operator (such as StringEquals) always applies to the value of the condition. The encryption context key (such as AppName) is the value of the kms:EncryptionContextKeys condition. The encryption context value (such as ExampleApp) is the value of the kms:EncryptionContext:context-key condition.

For example, in the following example key policy statement, because the StringEquals operator is case sensitive, both the encryption context key and the encryption context value are case sensitive.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:GenerateDataKey",
  "Resource": "*",
  "Condition": {
    "ForAnyValue:StringEquals": {
      "kms:EncryptionContextKeys": "AppName"
    },
    "StringEquals": {
      "kms:EncryptionContext:AppName": "ExampleApp"
    }
  }
}

Using variables in an encryption context condition

The key and value in an encryption context pair must be simple literal strings. They cannot be integers or objects, or any type that is not fully resolved. If you use a different type, such as an integer or float, AWS KMS interprets it as a literal string.

"encryptionContext": {
    "department": "10103.0"
}

However, the value of the kms:EncryptionContext:context-key condition key can be an IAM policy variable. These policy variables are resolved at runtime based on values in the request. For example, aws:CurrentTime resolves to the time of the request and aws:username resolves to the friendly name of the caller.

You can use these policy variables to create a policy statement with a condition that requires very specific information in an encryption context, such as the caller's user name. Because it contains a variable, you can use the same policy statement for all users who can assume the role. You don't have to write a separate policy statement for each user.

Consider a situation where you want to all users who can assume a role to use the same KMS key to encrypt and decrypt their data. However, you want to allow them to decrypt only the data that they encrypted. Start by requiring that every request to AWS KMS include an encryption context where the key is user and the value is the caller's AWS user name, such as the following one.

"encryptionContext": {
    "user": "bob"
}

Then, to enforce this requirement, you can use a policy statement like the one in the following example. This policy statement gives the TestTeam role permission to encrypt and decrypt data with the KMS key. However, the permission is valid only when the encryption context in the request includes a "user": "<username>" pair. To represent the user name, the condition uses the aws:username policy variable.

When the request is evaluated, the caller's user name replaces the variable in the condition. As such, the condition requires an encryption context of "user": "bob" for "bob" and "user": "alice" for "alice."

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/TestTeam"
  },
  "Action": [
    "kms:Decrypt",
    "kms:Encrypt"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:EncryptionContext:user": "${aws:username}"
    }
  }
}

You can use an IAM policy variable only in the value of the kms:EncryptionContext:context-key condition key. You cannot use a variable in the key.

You can also use provider-specific context keys in variables. These context keys uniquely identify users who logged into AWS by using web identity federation.

Like all variables, these variables can be used only in the kms:EncryptionContext:context-key policy condition, not in the actual encryption context. And they can be used only in the value of the condition, not in the key.

For example, the following key policy statement is similar to the previous one. However, the condition requires an encryption context where the key is sub and the value uniquely identifies a user logged into an Amazon Cognito user pool. For details about identifying users and roles in Amazon Cognito, see IAM Roles in the Amazon Cognito Developer Guide.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/TestTeam"
  },
  "Action": [
    "kms:Decrypt",
    "kms:Encrypt"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
       "kms:EncryptionContext:sub": "${cognito-identity.amazonaws.com:sub}"
    }
  }
}

See also

kms:EncryptionContextKeys

You can use the kms:EncryptionContextKeys condition key to control access to a symmetric encryption KMS key based on the encryption context in a request for a cryptographic operation. Use this condition key to evaluate only the key in each encryption context pair. To evaluate both the key and the value in the encryption context, use the kms:EncryptionContext:context-key condition key.

You cannot specify an encryption context in a cryptographic operation with an asymmetric KMS key or an HMAC KMS key. Asymmetric algorithms and MAC algorithms do not support an encryption context.

This is a multi-valued condition key. You can specify multiple encryption context pairs in each API request. kms:EncryptionContextKeys compares the encryption context keys in the request to the set of encryption context keys in the policy. To determine how these sets are compared, you must provide a ForAnyValue or ForAllValues set operator in the policy condition. For details about the set operators, see Using multiple keys and values in the IAM User Guide.

The following example key policy statement uses the kms:EncryptionContextKeys condition key with the ForAnyValue set operator. This policy statement allows use of a KMS key for the specified operations, but only when at least one of the encryption context pairs in the request includes the AppName key, regardless of its value.

For example, this key policy statement allows a GenerateDataKey request with two encryption context pairs, AppName=Helper and Project=Alpha, because the first encryption context pair satisfies the condition. A request with only Project=Alpha or with no encryption context would fail.

Because the StringEquals condition operation is case sensitive, this policy statement requires the spelling and case of the encryption context key. But you can use a condition operator that ignores the case of the key, such as StringEqualsIgnoreCase.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": [
    "kms:Encrypt",
    "kms:GenerateDataKey*"
  ],
  "Resource": "*",
  "Condition": {
    "ForAnyValue:StringEquals": {
      "kms:EncryptionContextKeys": "AppName"
    }
  }
}

You can also use the kms:EncryptionContextKeys condition key to require an encryption context (any encryption context) in cryptographic operations that use the KMS key;.

The following example key policy statement uses the kms:EncryptionContextKeys condition key with the Null condition operator to allow access to a KMS key only when encryption context in the API request is not null. This condition does not check the keys or values of the encryption context. It only verifies that the encryption context exists.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": [
    "kms:Encrypt",
    "kms:GenerateDataKey*"
  ],
  "Resource": "*",
  "Condition": {
    "Null": {
      "kms:EncryptionContextKeys": false
    }
  }
}

See also

kms:ExpirationModel

The kms:ExpirationModel condition key controls access to the ImportKeyMaterial operation based on the value of the ExpirationModel parameter in the request.

ExpirationModel is an optional parameter that determines whether the imported key material expires. Valid values are KEY_MATERIAL_EXPIRES and KEY_MATERIAL_DOES_NOT_EXPIRE. KEY_MATERIAL_EXPIRES is the default value.

The expiration date and time is determined by the value of the ValidTo parameter. The ValidTo parameter is required unless the value of the ExpirationModel parameter is KEY_MATERIAL_DOES_NOT_EXPIRE. You can also use the kms:ValidTo condition key to require a particular expiration date as a condition for access.

The following example policy statement uses the kms:ExpirationModel condition key to allow users to import key material into a KMS key only when the request includes the ExpirationModel parameter and its value is KEY_MATERIAL_DOES_NOT_EXPIRE.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:ImportKeyMaterial",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ExpirationModel": "KEY_MATERIAL_DOES_NOT_EXPIRE"
    }
  }
}

You can also use the kms:ExpirationModel condition key to allow users to import key material only when the key material expires. The following example key policy statement uses the kms:ExpirationModel condition key with the Null condition operator to allow users to import key material only when the request does not have an ExpirationModel parameter. The default value for ExpirationModel is KEY_MATERIAL_EXPIRES.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:ImportKeyMaterial",
  "Resource": "*",
  "Condition": {
    "Null": {
      "kms:ExpirationModel": true
    }
  }
}

See also

kms:GrantConstraintType

You can use this condition key to control access to the CreateGrant operation based on the type of grant constraint in the request.

When you create a grant, you can optionally specify a grant constraint to allow the operations that the grant permit only when a particular encryption context is present. The grant constraint can be one of two types: EncryptionContextEquals or EncryptionContextSubset. You can use this condition key to check that the request contains one type or the other.

The following example key policy statement uses the kms:GrantConstraintType condition key to allow users to create grants only when the request includes an EncryptionContextEquals grant constraint. The example shows a policy statement in a key policy.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/RoleForExampleApp"
  },
  "Action": "kms:CreateGrant",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:GrantConstraintType": "EncryptionContextEquals"
    }
  }
}

See also

kms:GrantIsForAWSResource

Allows or denies permission for the CreateGrant, ListGrants, or RevokeGrant operations only when an AWS service integrated with AWS KMS calls the operation on the user's behalf. This policy condition doesn't allow the user to call these grant operations directly.

The following example key policy statement uses the kms:GrantIsForAWSResource condition key. It allows AWS services that are integrated with AWS KMS, such as Amazon EBS, to create grants on this KMS key on behalf of the specified principal.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": "kms:CreateGrant",
  "Resource": "*",
  "Condition": {
    "Bool": {
      "kms:GrantIsForAWSResource": true
    }
  }
}

See also

kms:GrantOperations

You can use this condition key to control access to the CreateGrant operation based on the grant operations in the request. For example, you can allow users to create grants that delegate permission to encrypt but not decrypt. For more information about grants, see Using grants.

This is a multi-valued condition key. kms:GrantOperations compares the set of grant operations in the CreateGrant request to the set of grant operations in the policy. To determine how these sets are compared, you must provide a ForAnyValue or ForAllValues set operator in the policy condition. For details about the set operators, see Using multiple keys and values in the IAM User Guide.

The following example key policy statement uses the kms:GrantOperations condition key to to create grants only when the grant operations are Encrypt, ReEncryptTo, or both. If the grant includes any other operations, the CreateGrant request fails.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": "kms:CreateGrant",
  "Resource": "*",
  "Condition": {
    "ForAllValues:StringEquals": {
      "kms:GrantOperations": [
        "Encrypt",
        "ReEncryptTo"
      ]
    }
  }
}

If you change the set operator in the policy condition to ForAnyValue, the policy statement would require that at least one of the grant operations in the grant is Encrypt or ReEncryptTo, but it would allow other grant operations, such as Decrypt or ReEncryptFrom.

See also

kms:GranteePrincipal

You can use this condition key to control access to the CreateGrant operation based on the value of the GranteePrincipal parameter in the request. For example, you can to create grants to use a KMS key only when the grantee principal in the CreateGrant request matches the principal specified in the condition statement.

To specify the grantee principal, use the Amazon Resource Name (ARN) of an AWS principal. Valid principals include AWS accounts, IAM users, IAM roles, federated users, and assumed role users. For help with the ARN syntax for a principal, see IAM ARNs in the IAM User Guide.

The following example key policy statement uses the kms:GranteePrincipal condition key to to create grants for a KMS key only when the grantee principal in the grant is the LimitedAdminRole.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": "kms:CreateGrant",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:GranteePrincipal": "arn:aws:iam::111122223333:role/LimitedAdminRole"
    }
  }
}

See also

kms:KeyAgreementAlgorithm

You can use the kms:KeyAgreementAlgorithm condition key to control access to the DeriveSharedSecret operation based on the value of the KeyAgreementAlgorithm parameter in the request. The only valid value for KeyAgreementAlgorithm is ECDH.

For example, the following key policy statement uses the kms:KeyAgreementAlgorithm condition key to deny all access to DeriveSharedSecret unless the KeyAgreementAlgorithm is ECDH.

{
       "Effect": "Deny",
       "Principal": {
         "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
       },
       "Action": "kms:DeriveSharedSecret",
       "Resource": "*",
       "Condition": {
            "StringNotEquals": {
               "kms:KeyAgreementAlgorithm": "ECDH"
         }
       }
}

See also

kms:KeyOrigin

The kms:KeyOrigin condition key controls access to operations based on the value of the Origin property of the KMS key that is created by or used in the operation. It works as a resource condition or a request condition.

You can use this condition key to control access to the CreateKey operation based on the value of the Origin parameter in the request. Valid values for Origin are AWS_KMS, AWS_CLOUDHSM, and EXTERNAL.

For example, you can to create a KMS key only when the key material is generated in AWS KMS (AWS_KMS), only when the key material is generated in an AWS CloudHSM cluster that is associated with a custom key store (AWS_CLOUDHSM), or only when the key material is imported from an external source (EXTERNAL).

The following example key policy statement uses the kms:KeyOrigin condition key to to create a KMS key only when AWS KMS creates the key material.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
      },
      "Action": "kms:CreateKey",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:KeyOrigin": "AWS_KMS"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:GenerateDataKeyPair",
        "kms:GenerateDataKeyPairWithoutPlaintext",
        "kms:ReEncrypt*"
      ],
      "Resource": "arn:aws:kms:us-west-2:111122223333:key/*",
      "Condition": {
        "StringEquals": {
          "kms:KeyOrigin": "AWS_CLOUDHSM"
        }
      }
    }
  ]
}

You can also use the kms:KeyOrigin condition key to control access to operations that use or manage a KMS key based on the Origin property of the KMS key used for the operation. The operation must be a KMS key resource operation, that is, an operation that is authorized for a particular KMS key. To identify the KMS key resource operations, in the Actions and Resources Table, look for a value of KMS key in the Resources column for the operation.

For example, the following IAM policy allows principals to perform the specified KMS key resource operations, but only with KMS keys in the account that were created in a custom key store.

{
  "Effect": "Allow",  
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:GenerateDataKey",
    "kms:GenerateDataKeyWithoutPlaintext",
    "kms:GenerateDataKeyPair",
    "kms:GenerateDataKeyPairWithoutPlaintext",
    "kms:ReEncrypt*"
  ],
  "Resource": "arn:aws:kms:us-west-2:111122223333:key/*",
  "Condition": {
    "StringEquals": {
      "kms:KeyOrigin": "AWS_CLOUDHSM"
    }
  }
}

See also

kms:KeySpec

The kms:KeySpec condition key controls access to operations based on the value of the KeySpec property of the KMS key that is created by or used in the operation.

You can use this condition key in an IAM policy to control access to the CreateKey operation based on the value of the KeySpec parameter in a CreateKey request. For example, you can use this condition to allow users to create only symmetric encryption KMS keys or only HMAC KMS keys.

The following example IAM policy statement uses the kms:KeySpec condition key to allow the principals to create only RSA asymmetric KMS keys. The permission is valid only when the KeySpec in the request begins with RSA_.

{
  "Effect": "Allow",
  "Action": "kms:CreateKey",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "kms:KeySpec": "RSA_*"
    }
  }
}

You can also use the kms:KeySpec condition key to control access to operations that use or manage a KMS key based on the KeySpec property of the KMS key used for the operation. The operation must be a KMS key resource operation, that is, an operation that is authorized for a particular KMS key. To identify the KMS key resource operations, in the Actions and Resources Table, look for a value of KMS key in the Resources column for the operation.

For example, the following IAM policy allows principals to perform the specified KMS key resource operations, but only with symmetric encryption KMS keys in the account.

{
  "Effect": "Allow",
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:DescribeKey"
  ],
  "Resource": "arn:aws:kms:us-west-2:111122223333:key/*",
  "Condition": {
    "StringEquals": {
      "kms:KeySpec": "SYMMETRIC_DEFAULT"
    }
  }
}

See also

kms:KeyUsage

The kms:KeyUsage condition key controls access to operations based on the value of the KeyUsage property of the KMS key that is created by or used in the operation.

You can use this condition key to control access to the CreateKey operation based on the value of the KeyUsage parameter in the request. Valid values for KeyUsage are ENCRYPT_DECRYPT, SIGN_VERIFY, GENERATE_VERIFY_MAC, and KEY_AGREEMENT.

For example, you can to create a KMS key only when the KeyUsage is ENCRYPT_DECRYPT or deny a user permission when the KeyUsage is SIGN_VERIFY.

The following example IAM policy statement uses the kms:KeyUsage condition key to to create a KMS key only when the KeyUsage is ENCRYPT_DECRYPT.

{
  "Effect": "Allow",  
  "Action": "kms:CreateKey",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:KeyUsage": "ENCRYPT_DECRYPT"
    }
  }
}

You can also use the kms:KeyUsage condition key to control access to operations that use or manage a KMS key based on the KeyUsage property of the KMS key in the operation. The operation must be a KMS key resource operation, that is, an operation that is authorized for a particular KMS key. To identify the KMS key resource operations, in the Actions and Resources Table, look for a value of KMS key in the Resources column for the operation.

For example, the following IAM policy allows principals to perform the specified KMS key resource operations, but only with KMS keys in the account that are used for signing and verification.

{
  "Effect": "Allow",
  "Action": [
    "kms:CreateGrant",
    "kms:DescribeKey",
    "kms:GetPublicKey",
    "kms:ScheduleKeyDeletion"
  ],
  "Resource": "arn:aws:kms:us-west-2:111122223333:key/*",
  "Condition": {
    "StringEquals": {
      "kms:KeyUsage": "SIGN_VERIFY"
    }
  }
}

See also

kms:MacAlgorithm

You can use the kms:MacAlgorithm condition key to control access to the GenerateMac and VerifyMac operations based on the value of the MacAlgorithm parameter in the request.

The following example key policy allows users who can assume the testers role to use the HMAC KMS key to generate and verify HMAC tags only when the MAC algorithm in the request is HMAC_SHA_384 or HMAC_SHA_512. This policy uses two separate policy statements each with its own condition. If you specify more than one MAC algorithm in a single condition statement, the condition requires both algorithms, instead of one or the other.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/testers"
      },
      "Action": [
        "kms:GenerateMac",
        "kms:VerifyMac"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:MacAlgorithm": "HMAC_SHA_384"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/testers"
      },
      "Action": [
        "kms:GenerateMac",
        "kms:VerifyMac"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:MacAlgorithm": "HMAC_SHA_512"
        }
      }
    }
  ]
}

See also

kms:MessageType

The kms:MessageType condition key controls access to the Sign and Verify operations based on the value of the MessageType parameter in the request. Valid values for MessageType are RAW and DIGEST.

For example, the following key policy statement uses the kms:MessageType condition key to to use an asymmetric KMS key to sign a message, but not a message digest.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": "kms:Sign",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:MessageType": "RAW"
    }
  }
}

See also

kms:MultiRegion

You can use this condition key to allow operations only on single-Region keys or only on multi-Region keys. The kms:MultiRegion condition key controls access to AWS KMS operations on KMS keys and to the CreateKey operation based on the value of the MultiRegion property of the KMS key. Valid values are true (multi-Region), and false (single-Region). All KMS keys have a MultiRegion property.

For example, the following IAM policy statement uses the kms:MultiRegion condition key to allow principals to create only single-Region keys.

{
  "Effect": "Allow",
  "Action": "kms:CreateKey",
  "Resource": "*",
  "Condition": {
    "Bool": {
      "kms:MultiRegion": false
    }
  }
}

kms:MultiRegionKeyType

You can use this condition key to allow operations only on multi-Region primary keys or only on multi-Region replica keys. The kms:MultiRegionKeyType condition key controls access to AWS KMS operations on KMS keys and the CreateKey operation based on the MultiRegionKeyType property of the KMS key. The valid values are PRIMARY and REPLICA. Only multi-Region keys have a MultiRegionKeyType property.

Typically, you use the kms:MultiRegionKeyType condition key in an IAM policy to control access to multiple KMS keys. However, because a given multi-Region key can change to primary or replica, you might want to use this condition in a key policy to allow an operation only when the particular multi-Region key is a primary or replica key.

For example, the following IAM policy statement uses the kms:MultiRegionKeyType condition key to allow principals to schedule and cancel key deletion only on multi-Region replica keys in the specified AWS account.

{
  "Effect": "Allow",
  "Action": [
    "kms:ScheduleKeyDeletion",
    "kms:CancelKeyDeletion"
  ],
  "Resource": "arn:aws:kms:*:111122223333:key/*",
  "Condition": {
    "StringEquals": {
      "kms:MultiRegionKeyType": "REPLICA"
    }
  }
}

To allow or deny access to all multi-Region keys, you can use both values or a null value with kms:MultiRegionKeyType. However, the kms:MultiRegion condition key is recommended for that purpose.

kms:PrimaryRegion

You can use this condition key to limit the destination Regions in an UpdatePrimaryRegion operation. These are AWS Regions that can host your multi-Region primary keys.

The kms:PrimaryRegion condition key controls access to the UpdatePrimaryRegion operation based on the value of the PrimaryRegion parameter. The PrimaryRegion parameter specifies the AWS Region of the multi-Region replica key that is being promoted to primary. The value of the condition is one or more AWS Region names, such as us-east-1 or ap-southeast-2, or Region name patterns, such as eu-*

For example, the following key policy statement uses the kms:PrimaryRegion condition key to allow principals to update the primary region of a multi-Region key to one of the four specified Regions.

{
  "Effect": "Allow",
  "Action": "kms:UpdatePrimaryRegion",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/Developer"
  },
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:PrimaryRegion": [ 
         "us-east-1",
         "us-west-2",
         "eu-west-3",
         "ap-southeast-2"
      ]
    }
  }
}

kms:ReEncryptOnSameKey

You can use this condition key to control access to the ReEncrypt operation based on whether the request specifies a destination KMS key that is the same one used for the original encryption.

For example, the following key policy statement uses the kms:ReEncryptOnSameKey condition key to to reencrypt only when the destination KMS key is the same one used for the original encryption.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": "kms:ReEncrypt*",
  "Resource": "*",
  "Condition": {
    "Bool": {
      "kms:ReEncryptOnSameKey": true
    }
  }
}

kms:RequestAlias

You can use this condition key to allow an operation only when the request uses a particular alias to identify the KMS key. The kms:RequestAlias condition key controls access to a KMS key used in a cryptographic operation, GetPublicKey, or DescribeKey based on the alias that identifies that KMS key in the request. (This policy condition has no effect on the GenerateRandom operation because the operation doesn't use a KMS key or alias.)

This condition supports attribute-based access control (ABAC) in AWS KMS, which lets you control access to KMS keys based on the tags and aliases of a KMS key. You can use tags and aliases to allow or deny access to a KMS key without changing policies or grants. For details, see ABAC for AWS KMS.

To specify the alias in this policy condition, use an alias name, such as alias/project-alpha, or an alias name pattern, such as alias/*test*. You cannot specify an alias ARN in the value of this condition key.

To satisfy this condition, the value of the KeyId parameter in the request must be a matching alias name or alias ARN. If the request uses a different key identifier, it does not satisfy the condition, even if identifies the same KMS key.

For example, the following key policy statement allows the principal to call the GenerateDataKey operation on the KMS key. However this is permitted only when the value of the KeyId parameter in the request is alias/finance-key or an alias ARN with that alias name, such as arn:aws:kms:us-west-2:111122223333:alias/finance-key.

{
  "Sid": "Key policy using a request alias condition",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/developer"
  },
  "Action": "kms:GenerateDataKey",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:RequestAlias": "alias/finance-key"
    }
  }
}

You cannot use this condition key to control access to alias operations, such as CreateAlias or DeleteAlias. For information about controlling access to alias operations, see Controlling access to aliases.

kms:ResourceAliases

Use this condition key to control access to a KMS key based on the aliases that are associated with the KMS key. The operation must be a KMS key resource operation, that is, an operation that is authorized for a particular KMS key. To identify the KMS key resource operations, in the Actions and Resources Table, look for a value of KMS key in the Resources column for the operation.

This condition supports attribute-based access control (ABAC) in AWS KMS. With ABAC, you can control access to KMS keys based on the tags that are assigned to a KMS key and the aliases that are associated with a KMS key. You can use tags and aliases to allow or deny access to a KMS key without changing policies or grants. For details, see ABAC for AWS KMS.

An alias must be unique in an AWS account and Region, but this condition lets you control access to multiple KMS keys in the same Region (using the StringLike comparison operator) or to multiple KMS keys in different AWS Regions of each account.

To specify the alias in this policy condition, use an alias name, such as alias/project-alpha, or an alias name pattern, such as alias/*test*. You cannot specify an alias ARN in the value of this condition key. To satisfy the condition, the KMS key used in the operation must have the specified alias. It does not matter whether or how the KMS key is identified in the request for the operation.

This is a multivalued condition key that compares the set of aliases associated with a KMS key to the set of aliases in the policy. To determine how these sets are compared, you must provide a ForAnyValue or ForAllValues set operator in the policy condition. For details about the set operators, see Using multiple keys and values in the IAM User Guide.

For example, the following IAM policy statement allows the principal to call the GenerateDataKey operation on any KMS key in the specified AWS account that is associated with the finance-key alias. (The key policies of the affected KMS keys must also allow the principal's account to use them for this operation.) To indicate that the condition is satisfied when one of the many aliases that might be associated with the KMS key is alias/finance-key, the condition uses the ForAnyValue set operator.

Because the kms:ResourceAliases condition is based on the resource, not the request, a call to GenerateDataKey succeeds for any KMS key associated with the finance-key alias, even if the request uses a key ID or key ARN to identify the KMS key.

{
  "Sid": "AliasBasedIAMPolicy",
  "Effect": "Allow",
  "Action": "kms:GenerateDataKey",
  "Resource": [
    "arn:aws:kms:*:111122223333:key/*",
    "arn:aws:kms:*:444455556666:key/*"
  ],
  "Condition": {
    "ForAnyValue:StringEquals": {
      "kms:ResourceAliases": "alias/finance-key"
    }
  }
}

The following example IAM policy statement allows the principal to enable and disable KMS keys but only when all aliases of the KMS keys include "Test." This policy statement uses two conditions. The condition with the ForAllValues set operator requires that all aliases associated with the KMS key include "Test". The condition with the ForAnyValue set operator requires that the KMS key have at least one alias with "Test." Without the ForAnyValue condition, this policy statement would have allowed the principal to use KMS keys that had no aliases.

{
  "Sid": "AliasBasedIAMPolicy",
  "Effect": "Allow",
  "Action": [
    "kms:EnableKey",
    "kms:DisableKey"
  ],
  "Resource": "arn:aws:kms:*:111122223333:key/*",
  "Condition": {
    "ForAllValues:StringLike": {
      "kms:ResourceAliases": [
        "alias/*Test*"
      ]
    },
    "ForAnyValue:StringLike": {
      "kms:ResourceAliases": [
        "alias/*Test*"
      ]
    }
  }
}

kms:ReplicaRegion

You can use this condition key to limit the AWS Regions in which a principal can replicate a multi-Region key. The kms:ReplicaRegion condition key controls access to the ReplicateKey operation based on the value of the ReplicaRegion parameter in the request. This parameter specifies the AWS Region for the new replica key.

The value of the condition is one or more AWS Region names, such as us-east-1 or ap-southeast-2, or name patterns, such as eu-*. For a list of the names of AWS Regions that AWS KMS supports, see AWS Key Management Service endpoints and quotas in the AWS General Reference.

For example, the following key policy statement uses the kms:ReplicaRegion condition key to allow principals to call the ReplicateKey operation only when the value of the ReplicaRegion parameter is one of the specified Regions.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/Administrator"
  },
  "Action": "kms:ReplicateKey"
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ReplicaRegion": [ 
         "us-east-1",
         "eu-west-3",
         "ap-southeast-2"
      ]
    }
  }
}

This condition key controls access only to the ReplicateKey operation. To control access to the UpdatePrimaryRegion operation, use the kms:PrimaryRegion condition key.

kms:RetiringPrincipal

You can use this condition key to control access to the CreateGrant operation based on the value of the RetiringPrincipal parameter in the request. For example, you can to create grants to use a KMS key only when the RetiringPrincipal in the CreateGrant request matches the RetiringPrincipal in the condition statement.

To specify the retiring principal, use the Amazon Resource Name (ARN) of an AWS principal. Valid principals include AWS accounts, IAM users, IAM roles, federated users, and assumed role users. For help with the ARN syntax for a principal, see IAM ARNs in the IAM User Guide.

The following example key policy statement allows a user to create grants for the KMS key. The kms:RetiringPrincipal condition key restricts the permission to CreateGrant requests where the retiring principal in the grant is the LimitedAdminRole.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": "kms:CreateGrant",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:RetiringPrincipal": "arn:aws:iam::111122223333:role/LimitedAdminRole"
    }
  }
}

See also

kms:RotationPeriodInDays

You can use this condition key to limit the values that principals can specify in the RotationPeriodInDays parameter of a EnableKeyRotation request.

The RotationPeriodInDays specifies the number of days between each automatic key rotation date. AWS KMS allows you to specify a rotation period between 90 and 2560 days, but you can use the kms:RotationPeriodInDays condition key to further constrain the rotation period, such as enforcing a minimum rotation period within the valid range.

For example, the following key policy statement uses the kms:RotationPeriodInDays condition key to prevent principals from enabling key rotation if the rotation period is less than or equal to 180 days.

{
  "Effect": "Deny",
  "Action": "kms:EnableKeyRotation",
  "Principal": "*",
  "Resource": "*",
  "Condition" : {
      "NumericLessThanEquals" : {
        "kms:RotationPeriodInDays" : "180"
      }
  }
}

kms:ScheduleKeyDeletionPendingWindowInDays

You can use this condition key to limit the values that principals can specify in the PendingWindowInDays parameter of a ScheduleKeyDeletion request.

The PendingWindowInDays specifies the number of days that AWS KMS will wait before deleting a key. AWS KMS allows you to specify a waiting period between 7 and 30 days, but you can use the kms:ScheduleKeyDeletionPendingWindowInDays condition key to further constrain the waiting period, such as enforcing a minimum waiting period within the valid range.

For example, the following key policy statement uses the kms:ScheduleKeyDeletionPendingWindowInDays condition key to prevent principals from scheduling key deletion if the waiting period is less than or equal to 21 days.

{
  "Effect": "Deny",
  "Action": "kms:ScheduleKeyDeletion",
  "Principal": "*",
  "Resource": "*",
  "Condition" : {
      "NumericLessThanEquals" : {
        "kms:ScheduleKeyDeletionPendingWindowInDays" : "21"
      }
  }
}

kms:SigningAlgorithm

You can use the kms:SigningAlgorithm condition key to control access to the Sign and Verify operations based on the value of the SigningAlgorithm parameter in the request. This condition key has no effect on operations performed outside of AWS KMS, such as verifying signatures with the public key in an asymmetric KMS key pair outside of AWS KMS.

The following example key policy allows users who can assume the testers role to use the KMS key to sign messages only when the signing algorithm used for the request is an RSASSA_PSS algorithm, such as RSASSA_PSS_SHA512.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/testers"
  },
  "Action": "kms:Sign",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "kms:SigningAlgorithm": "RSASSA_PSS*"
    }
  }
}

See also

kms:ValidTo

The kms:ValidTo condition key controls access to the ImportKeyMaterial operation based on the value of the ValidTo parameter in the request, which determines when the imported key material expires. The value is expressed in Unix time.

By default, the ValidTo parameter is required in an ImportKeyMaterial request. However, if the value of the ExpirationModel parameter is KEY_MATERIAL_DOES_NOT_EXPIRE, the ValidTo parameter is invalid. You can also use the kms:ExpirationModel condition key to require the ExpirationModel parameter or a specific parameter value.

The following example policy statement allows a user to import key material into a KMS key. The kms:ValidTo condition key limits the permission to ImportKeyMaterial requests where the ValidTo value is less than or equal to 1546257599.0 (December 31, 2018 11:59:59 PM).

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": "kms:ImportKeyMaterial",
  "Resource": "*",
  "Condition": {
    "NumericLessThanEquals": {
      "kms:ValidTo": "1546257599.0"
    }
  }
}

See also

kms:ViaService

The kms:ViaService condition key limits use of an KMS key to requests from specified AWS services. You can specify one or more services in each kms:ViaService condition key. The operation must be a KMS key resource operation, that is, an operation that is authorized for a particular KMS key. To identify the KMS key resource operations, in the Actions and Resources Table, look for a value of KMS key in the Resources column for the operation.

For example, the following key policy statement uses the kms:ViaService condition key to allow a customer managed key to be used for the specified actions only when the request comes from Amazon EC2 or Amazon RDS in the US West (Oregon) region on behalf of ExampleRole.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:CreateGrant",
    "kms:ListGrants",
    "kms:DescribeKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": [
        "ec2.us-west-2.amazonaws.com",
        "rds.us-west-2.amazonaws.com"
      ]
    }
  }
}

You can also use a kms:ViaService condition key to deny permission to use a KMS key when the request comes from particular services. For example, the following policy statement from a key policy uses a kms:ViaService condition key to prevent a customer managed key from being used for Encrypt operations when the request comes from AWS Lambda on behalf of ExampleRole.

{
  "Effect": "Deny",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": [
    "kms:Encrypt"    
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": [
          "lambda.us-west-2.amazonaws.com"
      ]
    }
  }
}

All AWS managed keys use a kms:ViaService condition key in their key policy document. This condition allows the KMS key to be used only for requests that come from the service that created the KMS key. To see the key policy for an AWS managed key, use the GetKeyPolicy operation.

The kms:ViaService condition key is valid in IAM and key policy statements. The services that you specify must be integrated with AWS KMS and support the kms:ViaService condition key.

Services that support the kms:ViaService condition key

The following table lists AWS services that are integrated with AWS KMS and support the use of the kms:ViaService condition key in customer managed keys The services in this table might not be available in all regions. Use the .amazonaws.com suffix of the AWS KMS ViaService name in all AWS partitions.

kms:WrappingAlgorithm

This condition key controls access to the GetParametersForImport operation based on the value of the WrappingAlgorithm parameter in the request. You can use this condition to require principals to use a particular algorithm to encrypt key material during the import process. Requests for the required public key and import token fail when they specify a different wrapping algorithm.

The following example key policy statement uses the kms:WrappingAlgorithm condition key to give the example user permission to call the GetParametersForImport operation, but prevents them from using the RSAES_OAEP_SHA_1 wrapping algorithm. When the WrappingAlgorithm in the GetParametersForImport request is RSAES_OAEP_SHA_1, the operation fails.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": "kms:GetParametersForImport",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "kms:WrappingAlgorithm": "RSAES_OAEP_SHA_1"
    }
  }
}

See also

kms:WrappingKeySpec

This condition key controls access to the GetParametersForImport operation based on the value of the WrappingKeySpec parameter in the request. You can use this condition to require principals to use a particular type of public key during the import process. If the request specifies a different key type, it fails.

Because the only valid value for the WrappingKeySpec parameter value is RSA_2048, preventing users from using this value effectively prevents them from using the GetParametersForImport operation.

The following example policy statement uses the kms:WrappingAlgorithm condition key to require that the WrappingKeySpec in the request is RSA_4096.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/ExampleRole"
  },
  "Action": "kms:GetParametersForImport",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:WrappingKeySpec": "RSA_4096"
    }
  }
}

See also