> ## Documentation Index > Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # KMS Cross Account Access Must Not Be Present ### More Info: Ensure that all KMS keys are configured to be accessed only by trusted accounts in order to prevent unauthorized access ### Risk Level High ### Address Security ### Compliance Standards * APRA CPS 234 (Australia) * BSI C5 (Germany) * Brazil LGPD * CCPA / CPRA (California) * CIS Critical Security Controls v8 * CMMC 2.0 * CSA Cloud Controls Matrix v4 * Cloudanix Best Practice * DPDPA * Digital Operational Resilience Act (EU) * Essential 8 * ISO/IEC 27017 * ISO/IEC 27018 * ISO/IEC 27701 * KSA PDPL * MAS Technology Risk Management (Singapore) * MITRE ATT\&CK (Cloud) * NIS2 Directive * NIST SP 800-171 * NYDFS 23 NYCRR 500 * SWIFT Customer Security Controls Framework * Sarbanes-Oxley IT General Controls * UK NCSC Cyber Assessment Framework ### Triage and Remediation ### Remediation To remediate the KMS Cross Account Access misconfiguration in GCP using the GCP console, follow these steps: 1. Open the GCP Console and navigate to the Key Management Service (KMS) page. 2. Select the key ring that has cross-account access enabled. 3. Click on the key for which cross-account access is enabled. 4. Click on the "Permissions" tab. 5. Click the "Edit" button at the top of the page. 6. Find the member that has cross-account access and click the "X" to remove it. 7. Click "Save" to save the changes. Once you have completed these steps, cross-account access will be disabled for the selected key. Ensure that you have reviewed all the other keys and key rings and disabled cross-account access for any other keys that may have it enabled. # To remediate the KMS Cross Account Access Misconfiguration in GCP using GCP CLI, you can follow these steps: 1. First, you need to identify the KMS keyring and cryptokey that has cross-account access. You can use the following command to list all the KMS keyrings in your GCP project: ``` gcloud kms keyrings list ``` Once you have identified the keyring, you can list all the cryptokeys in that keyring using the following command: ``` gcloud kms keys list --keyring= ``` Identify the cryptokey that has cross-account access. 2. Once you have identified the cryptokey, you can remove the cross-account access by updating the IAM policy for that cryptokey. You can use the following command to remove all the members from the IAM policy for that cryptokey: ``` gcloud kms keys set-iam-policy /dev/null ``` This command sets the IAM policy for the cryptokey to an empty policy, which effectively removes all the members from the policy. 3. Finally, you can verify that the cross-account access has been removed by listing the IAM policy for the cryptokey using the following command: ``` gcloud kms keys get-iam-policy ``` This command should return an empty policy, indicating that there are no members with access to the cryptokey. By following these steps, you can remediate the KMS Cross Account Access Misconfiguration in GCP using GCP CLI. To remediate the KMS Cross Account Access misconfiguration in GCP using Python, you can follow the below steps: 1. First, you need to identify the KMS key that has cross-account access enabled. You can use the following command to list all the KMS keys in your project: ```python theme={null} from google.cloud import kms_v1 client = kms_v1.KeyManagementServiceClient() parent = client.key_ring_path(project_id, location_id, key_ring_id) response = client.list_crypto_keys(parent) for crypto_key in response: print(crypto_key.name) ``` 2. Once you have identified the KMS key, you can disable cross-account access by updating the IAM policy of the KMS key. You can use the following code to update the IAM policy: ```python theme={null} from google.cloud import kms_v1 client = kms_v1.KeyManagementServiceClient() resource = client.crypto_key_path(project_id, location_id, key_ring_id, crypto_key_id) policy = client.get_iam_policy(resource) for binding in policy.bindings: if binding.role == 'roles/cloudkms.cryptoKeyEncrypterDecrypter': binding.condition = None binding.members = [f'serviceAccount:{project_number}-compute@developer.gserviceaccount.com'] updated_policy = client.set_iam_policy(resource, policy) ``` In the above code, we are removing the condition that allows cross-account access and adding the service account of the Compute Engine instance in the same project as a member with the `roles/cloudkms.cryptoKeyEncrypterDecrypter` role. This will allow the Compute Engine instance to access the KMS key but prevent cross-account access. 3. Finally, you can verify that cross-account access has been disabled for the KMS key by running the following command: ```python theme={null} from google.cloud import kms_v1 client = kms_v1.KeyManagementServiceClient() resource = client.crypto_key_path(project_id, location_id, key_ring_id, crypto_key_id) policy = client.get_iam_policy(resource) for binding in policy.bindings: if binding.role == 'roles/cloudkms.cryptoKeyEncrypterDecrypter' and binding.condition: print('Cross-account access is still enabled') else: print('Cross-account access has been disabled') ``` By following these steps, you can remediate the KMS Cross Account Access misconfiguration in GCP using Python. ```hcl theme={null} # KMS crypto key (existing resource) resource "google_kms_crypto_key" "crypto_key" { name = "CRYPTO_KEY_NAME" # e.g. "my-key" key_ring = "projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME" purpose = "ENCRYPT_DECRYPT" rotation_period = "7776000s" } # IAM policy that removes all cross-project / cross-account access. # Only list principals from TRUSTED accounts (same project or explicitly trusted), # and do NOT include any other members. With trusted_accounts = [], that means # remove all non-essential external members and keep only required in-project ones. data "google_iam_policy" "crypto_key_trusted_only" { binding { role = "roles/cloudkms.cryptoKeyEncrypterDecrypter" members = [ # Replace with ONLY trusted in-project identities that must use the key. # Example in-project service account: "serviceAccount:KMS_CLIENT_SA@PROJECT_ID.iam.gserviceaccount.com", # Add other trusted in-project members as needed; do not include any # identities from other GCP projects or external domains/accounts. ] } # Add other role bindings as needed, again only with trusted in-project members. } resource "google_kms_crypto_key_iam_policy" "crypto_key_policy" { crypto_key_id = google_kms_crypto_key.crypto_key.id policy_data = data.google_iam_policy.crypto_key_trusted_only.policy_data } ``` Substitute: * `PROJECT_ID` with your GCP project ID. * `LOCATION` with the KMS location (e.g. `us-central1`). * `KEY_RING_NAME` with the existing key ring name. * `CRYPTO_KEY_NAME` with the existing crypto key name. * `KMS_CLIENT_SA` with the local service account name (or other *in‑project* principals) that are allowed to use the key. This change updates only IAM on the crypto key and does **not** force replacement of the KMS key itself, but it will remove any existing cross-account principals from the key’s IAM policy. Verification: `terraform plan` should show changes only to `google_kms_crypto_key_iam_policy.crypto_key_policy`, with all non‑trusted / cross‑account members being removed from the policy.