Separation of duties is the concept of ensuring that one individual does not have all necessary permissions to be able to complete a malicious action. In Cloud KMS, this could be an action such as using a key to access and decrypt data that that user should not normally have access to.
Separation of duties is a business control typically used in larger organizations, meant to help avoid security or privacy incidents and errors. It is considered best practice.
For further guidance, see our documentation on using IAM securely.
Setting up Cloud KMS in a separate project
Cloud KMS could be run in an existing project, for example
this might be sensible if the data being encrypted with keys in Cloud KMS is
stored in the same project.
However, any user with
owner access on that project is then also able to
manage (and perform cryptographic operations with)
keys in Cloud KMS in that project. This is because the keys themselves are owned
project, of which the user is an
Instead, to allow for a separation of duties, you could run Cloud KMS in its
own project, for example
your-key-project. Then, depending on the strictness
of your separation requirements, you could either:
- (recommended) Create
ownerat the project-level, and instead have an Organization Admin granted at the organization-level. This Organization Admin is not like an
owner- they are not able to manage or use keys, but they have the permission to Set IAM Policy to restrict who is given permissions for key management and use. Using an organization-level node, you can further restrict permissions for projects in your organization. See the next section for alternative roles to
ownerfor use with Cloud KMS.
- (not recommended) Grant an
your-key-projectto a different user than the
your-project, where the keys from Cloud KMS are being used. This user would still have access to all key operations.
Choosing the right IAM roles
For smaller organizations, the primitive roles of
likely provide sufficient granularity for key management. In larger
organizations where separation of duties is required, the
owner role provides
excessive access to sensitive security operations, and may not be ideal. In this
case, we instead recommend you use predefined roles:
- For the business owner whose application requires encryption: organization-level Organization Admin.
- For the user managing Cloud KMS, e.g., a member of an organization's IT
security team: Cloud KMS project-level with Admin (
cloudkms.admin) or Editor (
- For the user or service using keys for encryption and decryption
operations: Cloud KMS project-level service account with Encrypter/Decrypter
cloudkms.cryptoKeyEncrypterDecrypter). If the service only needs to be able to write or only be able to read data, further restrict use with the role of only Encrypter (
cloudkms.cryptoKeyEncrypter) or Decrypter (
Using a separate project for Cloud KMS and these recommended roles, you address several security concerns about separation of duties:
- Any user who needs a primitive role at the project-level in order to use another Google Cloud service cannot use that authority to access Cloud KMS.
- No user will need the
ownerrole, which could grant them excessive permissions to use keys. With no
owner, no user can both manage and use a key to encrypt or decrypt data directly by default. Note that if data access logs are not enabled, an
ownercould have potentially unaudited access to use key material.