libZSservicesZSamazonka-kmsZSamazonka-kms
Copyright(c) 2013-2021 Brendan Hay
LicenseMozilla Public License, v. 2.0.
MaintainerBrendan Hay <brendan.g.hay+amazonka@gmail.com>
Stabilityauto-generated
Portabilitynon-portable (GHC extensions)
Safe HaskellNone

Amazonka.KMS.CreateKey

Description

Creates a unique customer managed KMS key in your Amazon Web Services account and Region.

KMS is replacing the term customer master key (CMK) with KMS key and KMS key. The concept has not changed. To prevent breaking changes, KMS is keeping some variations of this term.

You can use the CreateKey operation to create symmetric or asymmetric KMS keys.

  • Symmetric KMS keys contain a 256-bit symmetric key that never leaves KMS unencrypted. To use the KMS key, you must call KMS. You can use a symmetric KMS key to encrypt and decrypt small amounts of data, but they are typically used to generate data keys and data keys pairs. For details, see GenerateDataKey and GenerateDataKeyPair.
  • Asymmetric KMS keys can contain an RSA key pair or an Elliptic Curve (ECC) key pair. The private key in an asymmetric KMS key never leaves KMS unencrypted. However, you can use the GetPublicKey operation to download the public key so it can be used outside of KMS. KMS keys with RSA key pairs can be used to encrypt or decrypt data or sign and verify messages (but not both). KMS keys with ECC key pairs can be used only to sign and verify messages.

For information about symmetric and asymmetric KMS keys, see Using Symmetric and Asymmetric KMS keys in the Key Management Service Developer Guide.

To create different types of KMS keys, use the following guidance:

Asymmetric KMS keys
To create an asymmetric KMS key, use the KeySpec parameter to specify the type of key material in the KMS key. Then, use the KeyUsage parameter to determine whether the KMS key will be used to encrypt and decrypt or sign and verify. You can't change these properties after the KMS key is created.
Symmetric KMS keys
When creating a symmetric KMS key, you don't need to specify the KeySpec or KeyUsage parameters. The default value for KeySpec, SYMMETRIC_DEFAULT, and the default value for KeyUsage, ENCRYPT_DECRYPT, are the only valid values for symmetric KMS keys.

[Multi-Region primary keys Imported key material] To create a multi-Region primary key in the local Amazon Web Services Region, use the MultiRegion parameter with a value of True. To create a multi-Region replica key, that is, a KMS key with the same key ID and key material as a primary key, but in a different Amazon Web Services Region, use the ReplicateKey operation. To change a replica key to a primary key, and its primary key to a replica key, use the UpdatePrimaryRegion operation.

This operation supports multi-Region keys, an KMS feature that lets you create multiple interoperable KMS keys in different Amazon Web Services Regions. Because these KMS keys have the same key ID, key material, and other metadata, you can use them interchangeably to encrypt data in one Amazon Web Services Region and decrypt it in a different Amazon Web Services Region without re-encrypting the data or making a cross-Region call. For more information about multi-Region keys, see Using multi-Region keys in the Key Management Service Developer Guide.

You can create symmetric and asymmetric multi-Region keys and multi-Region keys with imported key material. You cannot create multi-Region keys in a custom key store.

To import your own key material, begin by creating a symmetric KMS key with no key material. To do this, use the Origin parameter of CreateKey with a value of EXTERNAL. Next, use GetParametersForImport operation to get a public key and import token, and use the public key to encrypt your key material. Then, use ImportKeyMaterial with your import token to import the key material. For step-by-step instructions, see Importing Key Material in the /Key Management Service Developer Guide/ . You cannot import the key material into an asymmetric KMS key.

To create a multi-Region primary key with imported key material, use the Origin parameter of CreateKey with a value of EXTERNAL and the MultiRegion parameter with a value of True. To create replicas of the multi-Region primary key, use the ReplicateKey operation. For more information about multi-Region keys, see Using multi-Region keys in the Key Management Service Developer Guide.

Custom key store
To create a symmetric KMS key in a custom key store, use the CustomKeyStoreId parameter to specify the custom key store. You must also use the Origin parameter with a value of AWS_CLOUDHSM. The CloudHSM cluster that is associated with the custom key store must have at least two active HSMs in different Availability Zones in the Amazon Web Services Region.

You cannot create an asymmetric KMS key in a custom key store. For information about custom key stores in KMS see Using Custom Key Stores in the /Key Management Service Developer Guide/ .

Cross-account use: No. You cannot use this operation to create a KMS key in a different Amazon Web Services account.

Required permissions: kms:CreateKey (IAM policy). To use the Tags parameter, kms:TagResource (IAM policy). For examples and information about related permissions, see Allow a user to create KMS keys in the Key Management Service Developer Guide.

Related operations:

  • DescribeKey
  • ListKeys
  • ScheduleKeyDeletion
Synopsis

Creating a Request

data CreateKey Source #

See: newCreateKey smart constructor.

Constructors

CreateKey' 

Fields

  • origin :: Maybe OriginType

    The source of the key material for the KMS key. You cannot change the origin after you create the KMS key. The default is AWS_KMS, which means that KMS creates the key material.

    To create a KMS key with no key material (for imported key material), set the value to EXTERNAL. For more information about importing key material into KMS, see Importing Key Material in the Key Management Service Developer Guide. This value is valid only for symmetric KMS keys.

    To create a KMS key in an KMS custom key store and create its key material in the associated CloudHSM cluster, set this value to AWS_CLOUDHSM. You must also use the CustomKeyStoreId parameter to identify the custom key store. This value is valid only for symmetric KMS keys.

  • keySpec :: Maybe KeySpec

    Specifies the type of KMS key to create. The default value, SYMMETRIC_DEFAULT, creates a KMS key with a 256-bit symmetric key for encryption and decryption. For help choosing a key spec for your KMS key, see How to Choose Your KMS key Configuration in the /Key Management Service Developer Guide/ .

    The KeySpec determines whether the KMS key contains a symmetric key or an asymmetric key pair. It also determines the encryption algorithms or signing algorithms that the KMS key supports. You can't change the KeySpec after the KMS key is created. To further restrict the algorithms that can be used with the KMS key, use a condition key in its key policy or IAM policy. For more information, see kms:EncryptionAlgorithm or kms:Signing Algorithm in the /Key Management Service Developer Guide/ .

    Amazon Web Services services that are integrated with KMS use symmetric KMS keys to protect your data. These services do not support asymmetric KMS keys. For help determining whether a KMS key is symmetric or asymmetric, see Identifying Symmetric and Asymmetric KMS keys in the Key Management Service Developer Guide.

    KMS supports the following key specs for KMS keys:

    • Symmetric key (default)

      • SYMMETRIC_DEFAULT (AES-256-GCM)
    • Asymmetric RSA key pairs

      • RSA_2048
      • RSA_3072
      • RSA_4096
    • Asymmetric NIST-recommended elliptic curve key pairs

      • ECC_NIST_P256 (secp256r1)
      • ECC_NIST_P384 (secp384r1)
      • ECC_NIST_P521 (secp521r1)
    • Other asymmetric elliptic curve key pairs

      • ECC_SECG_P256K1 (secp256k1), commonly used for cryptocurrencies.
  • customerMasterKeySpec :: Maybe CustomerMasterKeySpec

    Instead, use the KeySpec parameter.

    The KeySpec and CustomerMasterKeySpec parameters work the same way. Only the names differ. We recommend that you use KeySpec parameter in your code. However, to avoid breaking changes, KMS will support both parameters.

  • keyUsage :: Maybe KeyUsageType

    Determines the cryptographic operations for which you can use the KMS key. The default value is ENCRYPT_DECRYPT. This parameter is required only for asymmetric KMS keys. You can't change the KeyUsage value after the KMS key is created.

    Select only one valid value.

    • For symmetric KMS keys, omit the parameter or specify ENCRYPT_DECRYPT.
    • For asymmetric KMS keys with RSA key material, specify ENCRYPT_DECRYPT or SIGN_VERIFY.
    • For asymmetric KMS keys with ECC key material, specify SIGN_VERIFY.
  • bypassPolicyLockoutSafetyCheck :: Maybe Bool

    A flag to indicate whether to bypass the key policy lockout safety check.

    Setting this value to true increases the risk that the KMS key becomes unmanageable. Do not set this value to true indiscriminately.

    For more information, refer to the scenario in the Default Key Policy section in the /Key Management Service Developer Guide/ .

    Use this parameter only when you include a policy in the request and you intend to prevent the principal that is making the request from making a subsequent PutKeyPolicy request on the KMS key.

    The default value is false.

  • policy :: Maybe Text

    The key policy to attach to the KMS key.

    If you provide a key policy, it must meet the following criteria:

    • If you don't set BypassPolicyLockoutSafetyCheck to true, the key policy must allow the principal that is making the CreateKey request to make a subsequent PutKeyPolicy request on the KMS key. This reduces the risk that the KMS key becomes unmanageable. For more information, refer to the scenario in the Default Key Policy section of the /Key Management Service Developer Guide/ .
    • Each statement in the key policy must contain one or more principals. The principals in the key policy must exist and be visible to KMS. When you create a new Amazon Web Services principal (for example, an IAM user or role), you might need to enforce a delay before including the new principal in a key policy because the new principal might not be immediately visible to KMS. For more information, see Changes that I make are not always immediately visible in the /Amazon Web Services Identity and Access Management User Guide/.

    If you do not provide a key policy, KMS attaches a default key policy to the KMS key. For more information, see Default Key Policy in the Key Management Service Developer Guide.

    The key policy size quota is 32 kilobytes (32768 bytes).

    For help writing and formatting a JSON policy document, see the IAM JSON Policy Reference in the /Identity and Access Management User Guide/ .

  • description :: Maybe Text

    A description of the KMS key.

    Use a description that helps you decide whether the KMS key is appropriate for a task. The default value is an empty string (no description).

    To set or change the description after the key is created, use UpdateKeyDescription.

  • customKeyStoreId :: Maybe Text

    Creates the KMS key in the specified custom key store and the key material in its associated CloudHSM cluster. To create a KMS key in a custom key store, you must also specify the Origin parameter with a value of AWS_CLOUDHSM. The CloudHSM cluster that is associated with the custom key store must have at least two active HSMs, each in a different Availability Zone in the Region.

    This parameter is valid only for symmetric KMS keys and regional KMS keys. You cannot create an asymmetric KMS key or a multi-Region key in a custom key store.

    To find the ID of a custom key store, use the DescribeCustomKeyStores operation.

    The response includes the custom key store ID and the ID of the CloudHSM cluster.

    This operation is part of the Custom Key Store feature feature in KMS, which combines the convenience and extensive integration of KMS with the isolation and control of a single-tenant key store.

  • tags :: Maybe [Tag]

    Assigns one or more tags to the KMS key. Use this parameter to tag the KMS key when it is created. To tag an existing KMS key, use the TagResource operation.

    Tagging or untagging a KMS key can allow or deny permission to the KMS key. For details, see Using ABAC in KMS in the Key Management Service Developer Guide.

    To use this parameter, you must have kms:TagResource permission in an IAM policy.

    Each tag consists of a tag key and a tag value. Both the tag key and the tag value are required, but the tag value can be an empty (null) string. You cannot have more than one tag on a KMS key with the same tag key. If you specify an existing tag key with a different tag value, KMS replaces the current tag value with the specified one.

    When you add tags to an Amazon Web Services resource, Amazon Web Services generates a cost allocation report with usage and costs aggregated by tags. Tags can also be used to control access to a KMS key. For details, see Tagging Keys.

  • multiRegion :: Maybe Bool

    Creates a multi-Region primary key that you can replicate into other Amazon Web Services Regions. You cannot change this value after you create the KMS key.

    For a multi-Region key, set this parameter to True. For a single-Region KMS key, omit this parameter or set it to False. The default value is False.

    This operation supports multi-Region keys, an KMS feature that lets you create multiple interoperable KMS keys in different Amazon Web Services Regions. Because these KMS keys have the same key ID, key material, and other metadata, you can use them interchangeably to encrypt data in one Amazon Web Services Region and decrypt it in a different Amazon Web Services Region without re-encrypting the data or making a cross-Region call. For more information about multi-Region keys, see Using multi-Region keys in the Key Management Service Developer Guide.

    This value creates a primary key, not a replica. To create a /replica key/, use the ReplicateKey operation.

    You can create a symmetric or asymmetric multi-Region key, and you can create a multi-Region key with imported key material. However, you cannot create a multi-Region key in a custom key store.

Instances

Instances details
Eq CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Read CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Show CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Generic CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Associated Types

type Rep CreateKey :: Type -> Type #

NFData CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Methods

rnf :: CreateKey -> () #

Hashable CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

ToJSON CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

AWSRequest CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Associated Types

type AWSResponse CreateKey #

ToHeaders CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Methods

toHeaders :: CreateKey -> [Header] #

ToPath CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

ToQuery CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

type Rep CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

type AWSResponse CreateKey Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

newCreateKey :: CreateKey Source #

Create a value of CreateKey with all optional fields omitted.

Use generic-lens or optics to modify other optional fields.

The following record fields are available, with the corresponding lenses provided for backwards compatibility:

$sel:origin:CreateKey', createKey_origin - The source of the key material for the KMS key. You cannot change the origin after you create the KMS key. The default is AWS_KMS, which means that KMS creates the key material.

To create a KMS key with no key material (for imported key material), set the value to EXTERNAL. For more information about importing key material into KMS, see Importing Key Material in the Key Management Service Developer Guide. This value is valid only for symmetric KMS keys.

To create a KMS key in an KMS custom key store and create its key material in the associated CloudHSM cluster, set this value to AWS_CLOUDHSM. You must also use the CustomKeyStoreId parameter to identify the custom key store. This value is valid only for symmetric KMS keys.

$sel:keySpec:CreateKey', createKey_keySpec - Specifies the type of KMS key to create. The default value, SYMMETRIC_DEFAULT, creates a KMS key with a 256-bit symmetric key for encryption and decryption. For help choosing a key spec for your KMS key, see How to Choose Your KMS key Configuration in the /Key Management Service Developer Guide/ .

The KeySpec determines whether the KMS key contains a symmetric key or an asymmetric key pair. It also determines the encryption algorithms or signing algorithms that the KMS key supports. You can't change the KeySpec after the KMS key is created. To further restrict the algorithms that can be used with the KMS key, use a condition key in its key policy or IAM policy. For more information, see kms:EncryptionAlgorithm or kms:Signing Algorithm in the /Key Management Service Developer Guide/ .

Amazon Web Services services that are integrated with KMS use symmetric KMS keys to protect your data. These services do not support asymmetric KMS keys. For help determining whether a KMS key is symmetric or asymmetric, see Identifying Symmetric and Asymmetric KMS keys in the Key Management Service Developer Guide.

KMS supports the following key specs for KMS keys:

  • Symmetric key (default)

    • SYMMETRIC_DEFAULT (AES-256-GCM)
  • Asymmetric RSA key pairs

    • RSA_2048
    • RSA_3072
    • RSA_4096
  • Asymmetric NIST-recommended elliptic curve key pairs

    • ECC_NIST_P256 (secp256r1)
    • ECC_NIST_P384 (secp384r1)
    • ECC_NIST_P521 (secp521r1)
  • Other asymmetric elliptic curve key pairs

    • ECC_SECG_P256K1 (secp256k1), commonly used for cryptocurrencies.

$sel:customerMasterKeySpec:CreateKey', createKey_customerMasterKeySpec - Instead, use the KeySpec parameter.

The KeySpec and CustomerMasterKeySpec parameters work the same way. Only the names differ. We recommend that you use KeySpec parameter in your code. However, to avoid breaking changes, KMS will support both parameters.

$sel:keyUsage:CreateKey', createKey_keyUsage - Determines the cryptographic operations for which you can use the KMS key. The default value is ENCRYPT_DECRYPT. This parameter is required only for asymmetric KMS keys. You can't change the KeyUsage value after the KMS key is created.

Select only one valid value.

  • For symmetric KMS keys, omit the parameter or specify ENCRYPT_DECRYPT.
  • For asymmetric KMS keys with RSA key material, specify ENCRYPT_DECRYPT or SIGN_VERIFY.
  • For asymmetric KMS keys with ECC key material, specify SIGN_VERIFY.

$sel:bypassPolicyLockoutSafetyCheck:CreateKey', createKey_bypassPolicyLockoutSafetyCheck - A flag to indicate whether to bypass the key policy lockout safety check.

Setting this value to true increases the risk that the KMS key becomes unmanageable. Do not set this value to true indiscriminately.

For more information, refer to the scenario in the Default Key Policy section in the /Key Management Service Developer Guide/ .

Use this parameter only when you include a policy in the request and you intend to prevent the principal that is making the request from making a subsequent PutKeyPolicy request on the KMS key.

The default value is false.

$sel:policy:CreateKey', createKey_policy - The key policy to attach to the KMS key.

If you provide a key policy, it must meet the following criteria:

  • If you don't set BypassPolicyLockoutSafetyCheck to true, the key policy must allow the principal that is making the CreateKey request to make a subsequent PutKeyPolicy request on the KMS key. This reduces the risk that the KMS key becomes unmanageable. For more information, refer to the scenario in the Default Key Policy section of the /Key Management Service Developer Guide/ .
  • Each statement in the key policy must contain one or more principals. The principals in the key policy must exist and be visible to KMS. When you create a new Amazon Web Services principal (for example, an IAM user or role), you might need to enforce a delay before including the new principal in a key policy because the new principal might not be immediately visible to KMS. For more information, see Changes that I make are not always immediately visible in the /Amazon Web Services Identity and Access Management User Guide/.

If you do not provide a key policy, KMS attaches a default key policy to the KMS key. For more information, see Default Key Policy in the Key Management Service Developer Guide.

The key policy size quota is 32 kilobytes (32768 bytes).

For help writing and formatting a JSON policy document, see the IAM JSON Policy Reference in the /Identity and Access Management User Guide/ .

$sel:description:CreateKey', createKey_description - A description of the KMS key.

Use a description that helps you decide whether the KMS key is appropriate for a task. The default value is an empty string (no description).

To set or change the description after the key is created, use UpdateKeyDescription.

$sel:customKeyStoreId:CreateKey', createKey_customKeyStoreId - Creates the KMS key in the specified custom key store and the key material in its associated CloudHSM cluster. To create a KMS key in a custom key store, you must also specify the Origin parameter with a value of AWS_CLOUDHSM. The CloudHSM cluster that is associated with the custom key store must have at least two active HSMs, each in a different Availability Zone in the Region.

This parameter is valid only for symmetric KMS keys and regional KMS keys. You cannot create an asymmetric KMS key or a multi-Region key in a custom key store.

To find the ID of a custom key store, use the DescribeCustomKeyStores operation.

The response includes the custom key store ID and the ID of the CloudHSM cluster.

This operation is part of the Custom Key Store feature feature in KMS, which combines the convenience and extensive integration of KMS with the isolation and control of a single-tenant key store.

$sel:tags:CreateKey', createKey_tags - Assigns one or more tags to the KMS key. Use this parameter to tag the KMS key when it is created. To tag an existing KMS key, use the TagResource operation.

Tagging or untagging a KMS key can allow or deny permission to the KMS key. For details, see Using ABAC in KMS in the Key Management Service Developer Guide.

To use this parameter, you must have kms:TagResource permission in an IAM policy.

Each tag consists of a tag key and a tag value. Both the tag key and the tag value are required, but the tag value can be an empty (null) string. You cannot have more than one tag on a KMS key with the same tag key. If you specify an existing tag key with a different tag value, KMS replaces the current tag value with the specified one.

When you add tags to an Amazon Web Services resource, Amazon Web Services generates a cost allocation report with usage and costs aggregated by tags. Tags can also be used to control access to a KMS key. For details, see Tagging Keys.

$sel:multiRegion:CreateKey', createKey_multiRegion - Creates a multi-Region primary key that you can replicate into other Amazon Web Services Regions. You cannot change this value after you create the KMS key.

For a multi-Region key, set this parameter to True. For a single-Region KMS key, omit this parameter or set it to False. The default value is False.

This operation supports multi-Region keys, an KMS feature that lets you create multiple interoperable KMS keys in different Amazon Web Services Regions. Because these KMS keys have the same key ID, key material, and other metadata, you can use them interchangeably to encrypt data in one Amazon Web Services Region and decrypt it in a different Amazon Web Services Region without re-encrypting the data or making a cross-Region call. For more information about multi-Region keys, see Using multi-Region keys in the Key Management Service Developer Guide.

This value creates a primary key, not a replica. To create a /replica key/, use the ReplicateKey operation.

You can create a symmetric or asymmetric multi-Region key, and you can create a multi-Region key with imported key material. However, you cannot create a multi-Region key in a custom key store.

Request Lenses

createKey_origin :: Lens' CreateKey (Maybe OriginType) Source #

The source of the key material for the KMS key. You cannot change the origin after you create the KMS key. The default is AWS_KMS, which means that KMS creates the key material.

To create a KMS key with no key material (for imported key material), set the value to EXTERNAL. For more information about importing key material into KMS, see Importing Key Material in the Key Management Service Developer Guide. This value is valid only for symmetric KMS keys.

To create a KMS key in an KMS custom key store and create its key material in the associated CloudHSM cluster, set this value to AWS_CLOUDHSM. You must also use the CustomKeyStoreId parameter to identify the custom key store. This value is valid only for symmetric KMS keys.

createKey_keySpec :: Lens' CreateKey (Maybe KeySpec) Source #

Specifies the type of KMS key to create. The default value, SYMMETRIC_DEFAULT, creates a KMS key with a 256-bit symmetric key for encryption and decryption. For help choosing a key spec for your KMS key, see How to Choose Your KMS key Configuration in the /Key Management Service Developer Guide/ .

The KeySpec determines whether the KMS key contains a symmetric key or an asymmetric key pair. It also determines the encryption algorithms or signing algorithms that the KMS key supports. You can't change the KeySpec after the KMS key is created. To further restrict the algorithms that can be used with the KMS key, use a condition key in its key policy or IAM policy. For more information, see kms:EncryptionAlgorithm or kms:Signing Algorithm in the /Key Management Service Developer Guide/ .

Amazon Web Services services that are integrated with KMS use symmetric KMS keys to protect your data. These services do not support asymmetric KMS keys. For help determining whether a KMS key is symmetric or asymmetric, see Identifying Symmetric and Asymmetric KMS keys in the Key Management Service Developer Guide.

KMS supports the following key specs for KMS keys:

  • Symmetric key (default)

    • SYMMETRIC_DEFAULT (AES-256-GCM)
  • Asymmetric RSA key pairs

    • RSA_2048
    • RSA_3072
    • RSA_4096
  • Asymmetric NIST-recommended elliptic curve key pairs

    • ECC_NIST_P256 (secp256r1)
    • ECC_NIST_P384 (secp384r1)
    • ECC_NIST_P521 (secp521r1)
  • Other asymmetric elliptic curve key pairs

    • ECC_SECG_P256K1 (secp256k1), commonly used for cryptocurrencies.

createKey_customerMasterKeySpec :: Lens' CreateKey (Maybe CustomerMasterKeySpec) Source #

Instead, use the KeySpec parameter.

The KeySpec and CustomerMasterKeySpec parameters work the same way. Only the names differ. We recommend that you use KeySpec parameter in your code. However, to avoid breaking changes, KMS will support both parameters.

createKey_keyUsage :: Lens' CreateKey (Maybe KeyUsageType) Source #

Determines the cryptographic operations for which you can use the KMS key. The default value is ENCRYPT_DECRYPT. This parameter is required only for asymmetric KMS keys. You can't change the KeyUsage value after the KMS key is created.

Select only one valid value.

  • For symmetric KMS keys, omit the parameter or specify ENCRYPT_DECRYPT.
  • For asymmetric KMS keys with RSA key material, specify ENCRYPT_DECRYPT or SIGN_VERIFY.
  • For asymmetric KMS keys with ECC key material, specify SIGN_VERIFY.

createKey_bypassPolicyLockoutSafetyCheck :: Lens' CreateKey (Maybe Bool) Source #

A flag to indicate whether to bypass the key policy lockout safety check.

Setting this value to true increases the risk that the KMS key becomes unmanageable. Do not set this value to true indiscriminately.

For more information, refer to the scenario in the Default Key Policy section in the /Key Management Service Developer Guide/ .

Use this parameter only when you include a policy in the request and you intend to prevent the principal that is making the request from making a subsequent PutKeyPolicy request on the KMS key.

The default value is false.

createKey_policy :: Lens' CreateKey (Maybe Text) Source #

The key policy to attach to the KMS key.

If you provide a key policy, it must meet the following criteria:

  • If you don't set BypassPolicyLockoutSafetyCheck to true, the key policy must allow the principal that is making the CreateKey request to make a subsequent PutKeyPolicy request on the KMS key. This reduces the risk that the KMS key becomes unmanageable. For more information, refer to the scenario in the Default Key Policy section of the /Key Management Service Developer Guide/ .
  • Each statement in the key policy must contain one or more principals. The principals in the key policy must exist and be visible to KMS. When you create a new Amazon Web Services principal (for example, an IAM user or role), you might need to enforce a delay before including the new principal in a key policy because the new principal might not be immediately visible to KMS. For more information, see Changes that I make are not always immediately visible in the /Amazon Web Services Identity and Access Management User Guide/.

If you do not provide a key policy, KMS attaches a default key policy to the KMS key. For more information, see Default Key Policy in the Key Management Service Developer Guide.

The key policy size quota is 32 kilobytes (32768 bytes).

For help writing and formatting a JSON policy document, see the IAM JSON Policy Reference in the /Identity and Access Management User Guide/ .

createKey_description :: Lens' CreateKey (Maybe Text) Source #

A description of the KMS key.

Use a description that helps you decide whether the KMS key is appropriate for a task. The default value is an empty string (no description).

To set or change the description after the key is created, use UpdateKeyDescription.

createKey_customKeyStoreId :: Lens' CreateKey (Maybe Text) Source #

Creates the KMS key in the specified custom key store and the key material in its associated CloudHSM cluster. To create a KMS key in a custom key store, you must also specify the Origin parameter with a value of AWS_CLOUDHSM. The CloudHSM cluster that is associated with the custom key store must have at least two active HSMs, each in a different Availability Zone in the Region.

This parameter is valid only for symmetric KMS keys and regional KMS keys. You cannot create an asymmetric KMS key or a multi-Region key in a custom key store.

To find the ID of a custom key store, use the DescribeCustomKeyStores operation.

The response includes the custom key store ID and the ID of the CloudHSM cluster.

This operation is part of the Custom Key Store feature feature in KMS, which combines the convenience and extensive integration of KMS with the isolation and control of a single-tenant key store.

createKey_tags :: Lens' CreateKey (Maybe [Tag]) Source #

Assigns one or more tags to the KMS key. Use this parameter to tag the KMS key when it is created. To tag an existing KMS key, use the TagResource operation.

Tagging or untagging a KMS key can allow or deny permission to the KMS key. For details, see Using ABAC in KMS in the Key Management Service Developer Guide.

To use this parameter, you must have kms:TagResource permission in an IAM policy.

Each tag consists of a tag key and a tag value. Both the tag key and the tag value are required, but the tag value can be an empty (null) string. You cannot have more than one tag on a KMS key with the same tag key. If you specify an existing tag key with a different tag value, KMS replaces the current tag value with the specified one.

When you add tags to an Amazon Web Services resource, Amazon Web Services generates a cost allocation report with usage and costs aggregated by tags. Tags can also be used to control access to a KMS key. For details, see Tagging Keys.

createKey_multiRegion :: Lens' CreateKey (Maybe Bool) Source #

Creates a multi-Region primary key that you can replicate into other Amazon Web Services Regions. You cannot change this value after you create the KMS key.

For a multi-Region key, set this parameter to True. For a single-Region KMS key, omit this parameter or set it to False. The default value is False.

This operation supports multi-Region keys, an KMS feature that lets you create multiple interoperable KMS keys in different Amazon Web Services Regions. Because these KMS keys have the same key ID, key material, and other metadata, you can use them interchangeably to encrypt data in one Amazon Web Services Region and decrypt it in a different Amazon Web Services Region without re-encrypting the data or making a cross-Region call. For more information about multi-Region keys, see Using multi-Region keys in the Key Management Service Developer Guide.

This value creates a primary key, not a replica. To create a /replica key/, use the ReplicateKey operation.

You can create a symmetric or asymmetric multi-Region key, and you can create a multi-Region key with imported key material. However, you cannot create a multi-Region key in a custom key store.

Destructuring the Response

data CreateKeyResponse Source #

See: newCreateKeyResponse smart constructor.

Constructors

CreateKeyResponse' 

Fields

Instances

Instances details
Eq CreateKeyResponse Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Read CreateKeyResponse Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Show CreateKeyResponse Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Generic CreateKeyResponse Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Associated Types

type Rep CreateKeyResponse :: Type -> Type #

NFData CreateKeyResponse Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

Methods

rnf :: CreateKeyResponse -> () #

type Rep CreateKeyResponse Source # 
Instance details

Defined in Amazonka.KMS.CreateKey

type Rep CreateKeyResponse = D1 ('MetaData "CreateKeyResponse" "Amazonka.KMS.CreateKey" "libZSservicesZSamazonka-kmsZSamazonka-kms" 'False) (C1 ('MetaCons "CreateKeyResponse'" 'PrefixI 'True) (S1 ('MetaSel ('Just "keyMetadata") 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedStrict) (Rec0 (Maybe KeyMetadata)) :*: S1 ('MetaSel ('Just "httpStatus") 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedStrict) (Rec0 Int)))

newCreateKeyResponse Source #

Create a value of CreateKeyResponse with all optional fields omitted.

Use generic-lens or optics to modify other optional fields.

The following record fields are available, with the corresponding lenses provided for backwards compatibility:

$sel:keyMetadata:CreateKeyResponse', createKeyResponse_keyMetadata - Metadata associated with the KMS key.

$sel:httpStatus:CreateKeyResponse', createKeyResponse_httpStatus - The response's http status code.

Response Lenses

createKeyResponse_httpStatus :: Lens' CreateKeyResponse Int Source #

The response's http status code.