Permissions and roles

Certificate authorities, certificates, and certificate revocation lists in CA Service can have Identity and Access Management policies bound to the resource.

Required permissions

The following table lists the permissions that the caller must have to call each method:

Permission Description
privateca.certificateAuthorities.create Create a certificate authority (CA).
privateca.certificateAuthorities.delete Schedule a CA for deletion.
privateca.certificateAuthorities.get Get a CA or CA certificate signing request.
privateca.certificateAuthorities.getIamPolicy Get the IAM policy for a CA.
privateca.certificateAuthorities.list List CAs in a project.
privateca.certificateAuthorities.setIamPolicy Set the IAM policy for a CA.
privateca.certificateAuthorities.update Update a CA, including activating, enabling, disabling, and restoring the CA.
privateca.certificates.create Create a new certificate in a CA.
privateca.certificates.get Get a certificate and its metadata.
privateca.certificates.list List all certificates in a CA.
privateca.certificates.update Update a certificate's metadata, including revocation.
privateca.certificateRevocationLists.get Get a certificate revocation list (CRL) in a CA.
privateca.certificateRevocationLists.getIamPolicy Get the IAM policy for a CRL.
privateca.certificateRevocationLists.list List all CRLs in a CA.
privateca.certificateRevocationLists.setIamPolicy Set the IAM policy for a CRL.
privateca.certificateRevocationLists.update Update a CRL.
privateca.operations.cancel Cancel a long-running operation.
privateca.operations.delete Delete a long-running operation.
privateca.operations.get Get a long-running operation.
privateca.operations.list List long-running operations in a project.
privateca.reusableConfigs.get Get a reusable configuration.
privateca.reusableConfigs.list List reusable configurations in a project.

Predefined roles

It is important to implement separation of duties to protect the security and integrity of a CA. Through the implementation of discrete roles, organizations can better manage the security of the CA and the overall PKI itself.

CA Service lets you assign roles to a user or service account. These role bindings can be added at the CA-level (to grant access to a specific CA), or at the project or organization-level (to grant access to all CAs in that scope).

Roles are inherited if granted at a higher resource level. For example, a user who is granted the Auditor role at the project level is able to view all resources under the project. The role that grants the broadest scope takes precedence. For example, if the user is granted the Admin role at the project level but only the Auditor role for a specific resource, they can still edit the resource.

Role Permissions Description
CA Service Auditor
The CA Service Auditor has read-only access to all CA Service resources and can retrieve and list properties of the CA, certificates, revocation lists, reusable configs, IAM policies and projects. This role should be assigned to individuals who are accountable for validating security and operations of the CA and are not assigned any daily responsibility of administering the service.
CA Service Certificate Requester
privateca.certificates.create A CA Service Certificate Requester can submit certificate requests to a CA. This role should be granted to trusted individuals who are allowed to request certificates.

A user with this role can request arbitrary certificates subject to the issuance policy.

Unlike the CA Service Certificate Manager role, this role does not allow the user to get or list the newly issued certificate, or to get any information about the CA.
CA Service Certificate Manager
All permissions from roles/privateca.auditor, plus:
A CA Service Certificate Manager can submit certificate issuance requests to a CA like the CA Service Certificate Requester. In addition, this role also inherits the permissions of the CA Service Auditor. It should be assigned to individuals accountable for creating, tracking and reviewing certificate requests on a CA such as a manager or lead engineer.
CA Service Operation Manager
All permissions from roles/privateca.auditor, plus:
A CA Service Operation Manager can create, update, and delete CAs. This role can also revoke certificates and create storage buckets. It also includes the same abilities as the CA Service Auditor. In this role, individuals are responsible for configuring and deploying CAs in the organization, along with configuring the CA's issuance policy.

This role does not allow for creating certificates. To do that, use the CA Service Certificate Requester, CA Service Certificate Manager, or CA Service Admin roles.
CA Service Admin
All permissions from roles/privateca.certificateManager, and roles/privateca.caManager, plus:
The CA Service Admin role inherits permissions from the CA Service Operation Manager and CA Service Certificate Manager. This role can perform all actions within CA Service and should be seldom assigned once the service is established. In this role, individuals can perform all aspects of administration including assigning rights to others and managing certificate requests in CA Service. It is recommended to implement special control and access to this role account to prevent unauthorized access or use.

CA Service Service Agent

When providing existing Cloud KMS signing keys or Cloud Storage buckets during CA creation, the CA Service Service Agent service account ( must be granted access to the respective resource.

For Cloud KMS, roles/cloudkms.signerVerifier is required to use the signing key and read the public key. roles/viewer is required to monitor the key for Cloud Monitoring integration.

For Cloud Storage, roles/storage.objectAdmin is required to write the CA certificate and CRLs to a bucket. roles/storage.legacyBucketReader is required to monitor the bucket for Cloud Monitoring integration.

When accessing the service through the API, the following commands should be run. First, create the Service Agent service account.

In the following example, PROJECT_ID is the unique identifier of the project where the CA resource is created.


gcloud beta services identity create --project=PROJECT_ID

If existing Cloud KMS signing keys are provided:


gcloud kms keys add-iam-policy-binding 'CRYPTOKEY_NAME' \
--keyring='KEYRING_NAME' \
--location='LOCATION' \
--member='' \

gcloud kms keys add-iam-policy-binding 'CRYPTOKEY_NAME' \
--keyring='KEYRING_NAME' \
--location='LOCATION' \
--member='' \

If existing Cloud Storage buckets are provided, use the gsutil command-line tool to bind the required roles for the Cloud Storage bucket:


gsutil iam ch gs://BUCKET_NAME
gsutil iam ch gs://BUCKET_NAME

What's next

  • Learn how IAM centralizes management of permissions and access scopes for Google Cloud resources.