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 Key Management Service, this could be an action such as using a key to access and decrypt data which 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 Cloud Identity and Access Management securely.
Setting up KMS in a separate project
KMS could be run in an existing project, for example
this might be sensible if the data being encrypted with keys in 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 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 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 Cloud 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 KMS.
- (not recommended) Grant an
your-key-projectto a different user than the
your-project, where the keys from KMS are being used. This user would still have access to all key operations.
Choosing the right Cloud 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: Use the organization-level Organization Admin role.
For the user managing KMS, that is, a member of an organization's IT security team: The two roles with the minimum permissions required to manage KMS via the Cloud Console are the predefined Project Editor (
editor) role, or a custom role based on the KMS Admin (
cloudkms.admin) role combined with the following permissions:
For information about creating a custom role, see Creating a custom role. If the user manages KMS using only the
gcloudtool and the KMS API, the predefined KMS Admin role has sufficient permission without requiring the
For the user or service using keys for encryption and decryption operations: Use a 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 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 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.