Provision Enterprise Managed Encryption Keys (EMEK) for Splunk Cloud Platform

The Admin Config Service (ACS) API supports programmatic self-service provisioning of Enterprise Managed Encryption Keys (EMEK) for your Splunk Cloud Platform deployment.

For detailed information on using EMEK to encrypt data in Splunk Cloud Platform, see Secure data with Enterprise Managed Encryption Keys in Securing Splunk Cloud Platform.

Requirements

To provision EMEK using the ACS API:

• You must have enabled EMEK for your deployment. To request EMEK enablement, contact your Splunk Cloud Platform account representative.
• You must have the sc_admin role.
• You must generate the key in the same AWS or GCP region as your Splunk Cloud Platform deployment.

GCP deployments with DDAA (Dynamic Data Active Archive) storage activated, do not support self-provisioning of EMEKs.

Provision EMEK using the ACS API

To provision a new or update an existing EMEK using the ACS API, follow these steps:

1. View EMEK legal disclaimer.
2. Generate KMS key policy.
3. Upload new KMS key.
4. Validate and use new key.

1. View EMEK legal disclaimer

Before you use the EMEK feature in Splunk Cloud Platform, you must view and acknowledge the EMEK legal disclaimer. You acknowledge the EMEK legal disclaimer when you generate the KMS key policy in the following step.

To view the EMEK legal disclaimer, send an HTTP GET request to the emek/waiver endpoint. For example:

curl "https://admin.splunk.com/${STACK}/adminconfig/v2/emek/waiver" \
--header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2VjcmV0Iiwi…'

ACS returns the following responses for AWS and GCP deployments respectively:

AWS Legal Disclaimer

Thank you for subscribing to an encryption service for data at rest as an add-on to the Splunk Cloud Platform service. As you know, Splunk Cloud Platform relies on AWS Cloud Key Management Service (Cloud KMS) for key management operations, and customers who elect to use the Enterprise Managed Encryption Key (EMEK) capability assume full control of the customer master key (CMK) in Cloud KMS. Before electing to directly manage your own master in Cloud KMS, please reply to this message to confirm and acknowledge the following risks and responsibilities involved with self-management of your CMK:  

    * You are assuming ownership and full responsibility for the integrity and ongoing availability of your CMK in Cloud KMS.

    * The CMK is required for encrypting and decrypting Splunk data in real-time.

    * Loss of access to the CMK in Cloud KMS can and will result in service interruption and/or permanent loss of data access by all parties (AWS, Splunk and you).

    * Unauthorized access to the CMK in Cloud KMS can result in accidental or explicit key operations (such as key deactivation and/or deletion) that could lead to service disruption and/or permanent loss of data access by all parties (AWS, Splunk and you).

    * You must maintain Splunk privileged access to the CMK via Splunk mandated key policy definitions.

GCP Legal Disclaimer

Thank you for subscribing to an encryption service for data at rest as an add-on to the Splunk Cloud Platform service. As you know, Splunk Cloud Platform relies on GCP Cloud Key Management Service (Cloud KMS) for key management operations, and customers who elect to use the Enterprise Managed Encryption Key (EMEK) capability assume full control of the customer master key (CMK) in Cloud KMS. Before electing to directly manage your own master in Cloud KMS, please reply to this message to confirm and acknowledge the following risks and responsibilities involved with self-management of your CMK:  

    * You are assuming ownership and full responsibility for the integrity and ongoing availability of your CMK in Cloud KMS.

    * The CMK is required for encrypting and decrypting Splunk data in real-time.

    * Loss of access to the CMK in Cloud KMS can and will result in service interruption and/or permanent loss of data access by all parties (GCP, Splunk and you).

    * Unauthorized access to the CMK in Cloud KMS can result in accidental or explicit key operations (such as key deactivation and/or deletion) that could lead to service disruption and/or permanent loss of data access by all parties (GCP, Splunk and you).

    * You must maintain Splunk privileged access to the CMK via Splunk mandated key policy definitions.

For endpoint details, see emek/waiver in the ACS API endpoint reference.

2. Generate KMS key policy

Generate a KMS key policy and then create a new KMS key. You submit the KMS key policy when you create a new or update an existing KMS key in your AWS or GCP account. The key policy is required for your Splunk Cloud Platform deployment to access the encryption key.

To generate the KMS key policy, send an HTTP GET request to the emek/key-policy endpoint. You must also specify Y in the EMEK-Legal-Ack header to acknowledge acceptance of any risks involved using EMEK, as specified in the EMEK legal disclaimer. For example:

curl "https://admin.splunk.com/{STACK}/adminconfig/v2/emek/key-policy" \
--header 'EMEK-Legal-Ack: Y' \
--header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2VjcmV0Iiwi…'

ACS returns the KMS key policy. For example:

AWS sample response

{
    "message": "Please copy and apply this key policy in AWS. Make sure to replace ${CUSTOMER_ACCOUNT_ID} with your corresponding AWS account ID.",
    "policy": {
        "Id": "key-consolepolicy-3",
        "Statement": [
            {
                "Action": "kms:*",
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::${CUSTOMER_ACCOUNT_ID}:root"
                },
                "Resource": "*",
                "Sid": "Enable IAM User Permissions"
            },
            {
                "Action": [
                    "kms:Encrypt",
                    "kms:Decrypt",
                    "kms:ReEncrypt*",
                    "kms:GenerateDataKey*",
                    "kms:DescribeKey"
                ],
                "Condition": {
                    "ArnEquals": {
                        "aws:PrincipalArn": "arn:aws:iam::992171771154:role/test-ibaniya-emek"
                    }
                },
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::992171771154:root"
                },
                "Resource": "*",
                "Sid": "Allow SplunkCloud to use the KMS Key"
            },
            {
                "Action": [
                    "kms:Encrypt",
                    "kms:GenerateDataKey*",
                    "kms:ReEncrypt*",
                    "kms:DescribeKey"
                ],
                "Condition": {
                    "ArnEquals": {
                        "aws:PrincipalArn": "arn:aws:iam::992171771154:role/terraform_assumed_role-lve"
                    }
                },
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::992171771154:root"
                },
                "Resource": "*",
                "Sid": "Allow SplunkCloud's Infrastructure Builder to use Key"
            },
            {
                "Action": [
                    "kms:CreateGrant",
                    "kms:ListGrants",
                    "kms:RevokeGrant"
                ],
                "Condition": {
                    "Bool": {
                        "kms:GrantIsForAWSResource": "true"
                    }
                },
                "Effect": "Allow",
                "Principal": {
                    "AWS": [
                        "arn:aws:iam::992171771154:root"
                    ]
                },
                "Resource": "*",
                "Sid": "Allow attachment of persistent resources"
            }
        ],
        "Version": "2012-10-17"
    },
    "region": "us-east-1"
}

When you create a KMS key on AWS, make sure to replace the $(CUSTOMER_ACCOUNT_ID) with your corresponding AWS Account ID.

GCP sample response:

{
    "message": "Create a KMS key in the following GCP region: us-central1. Apply the provided Splunk Cloud cross-account key policy template, see Using Key Policies and Allowing Cross-Account access to a CMK for more details on this. Make sure to replace any placeholder values if applicable. Once the above steps have been completed, please provide Splunk Cloud with the ARN of the KMS key created as well as the output of the KMS describe key command.",
    "policy": {
        "bindings": [
            {
                "members": [
                    "serviceAccount:test-ibaniya-gcp-idx@test-ibaniya-gcp-9fe6.iam.gserviceaccount.com",
                    "serviceAccount:service-945453386874@compute-system.iam.gserviceaccount.com"
                ],
                "role": "roles/cloudkms.cryptoKeyEncrypterDecrypter"
            },
            {
                "members": [
                    "serviceAccount:lve-stack-tf@cworks-lve-dd28.iam.gserviceaccount.com",
                    "serviceAccount:test-ibaniya-gcp-idx@test-ibaniya-gcp-9fe6.iam.gserviceaccount.com"
                ],
                "role": "roles/cloudkms.viewer"
            }
        ]
    },
    "region": "us-central1"
}

For endpoint details, see emek/key-policy in the ACS API endpoint reference

For more information on creating and updating key policies, see:

• AWS: Creating Symmetric Encryption Keys
• AWS: Key Policies

3. Upload new KMS key ARN

After you successfully generate the new key, you can upload the key ARN to your deployment for use encrypting data. The key ARN defines the path to the KMS key.

To upload the key ARN, send an HTTP PUT request to the ACS emek/key endpoint, specifying the keyARN provided in the KMS key policy in the request body. You must also specify Y in the EMEK-Legal-ACK header to acknowledge your acceptance of any risks involved using EMEK, as specified in the EMEK disclaimer. For example:

curl -X PUT "https://admin.splunk.com/{STACK}/adminconfig/v2/emek/key" \
--header 'EMEK-Legal-Ack: Y' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2VjcmV0Iiwi…'
--data '{
    "keyARN": "arn:aws:kms:us-east-1:111111111111:key/000000-xxx"
}'

ACS returns a message indicating that your key ARN upload request has been accepted. For example:

{
    "message": "EMEK Key ARN upload request accepted. To check the status of your request, use DescribeStack operation. Please contact Splunk support to use this EMEK key to re-key your stack."
}

For endpoint details, see emek/key in the ACS API endpoint reference

The key ARN upload process is asynchronous and can take time to complete. To check the status of your key upload request, send an HTTP GET request to the ACS stack status endpoint. For example:

curl "https://admin.splunk.com/{STACK}/adminconfig/v2/status" \
--header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2...'

ACS returns one of the following status responses:

• Ready: Key ARN was uploaded successfully
• Pending: Key ARN is being uploaded to the stack
• Failed: There were some errors uploading the key ARN. If you continue to experience errors, contact Splunk Support.

When uploading your KMS key to Splunk Cloud Platform, note the following:

• For AWS, the keyARN must be of the format: arn:<partition>:kms:<region>:<account-id>:key/<key-id> or arn:<partition>:kms:<region>:<account-id>:alias/<alias-name>
• For GCP, the keyARN must be of the format: projects/<project-id>/locations/<location>/keyRings/<keyring>/cryptoKeys/<key>
• You cannot perform key upload operations during an ongoing maintenance window.
• Splunk Cloud Platform does not support multiple non-active keys per stack. Splunk Cloud Platform stores new keys for re-key and any further key upload prior to re-key will overwrite the previously uploaded key ARN.

4. Validate and use new key

Before you can use your newly uploaded key, you must contact Splunk support for key validation. Splunk support validates access, region, and key origin to ensure compliance with EMEK requirements. Splunk then provisions your environment and notifies you upon completion. Once you receive this notification, your EMEK is ready for use.