Certificate authorities, certificates, and certificate revocation lists in CA Service can have Identity and Access Management policies bound to the resource.
The following table lists the permissions that the caller must have to call each method:
||Create a certificate authority (CA).|
||Schedule a CA for deletion.|
||Get a CA or CA certificate signing request.|
||Get the IAM policy for a CA.|
||List CAs in a project.|
||Set the IAM policy for a CA.|
||Update a CA, including activating, enabling, disabling, and restoring the CA.|
||Create a new certificate in a CA.|
||Get a certificate and its metadata.|
||List all certificates in a CA.|
||Update a certificate's metadata, including revocation.|
||Get a certificate revocation list (CRL) in a CA.|
||Get the IAM policy for a CRL.|
||List all CRLs in a CA.|
||Set the IAM policy for a CRL.|
||Update a CRL.|
||Cancel a long-running operation.|
||Delete a long-running operation.|
||Get a long-running operation.|
||List long-running operations in a project.|
||Get a reusable configuration.|
||List reusable configurations in a project.|
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.
|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
||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
||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
||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
||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
service-PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com) 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.
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 --service=privateca.googleapis.com --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='serviceAccount:service-PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com' \ --role='roles/cloudkms.signerVerifier' gcloud kms keys add-iam-policy-binding 'CRYPTOKEY_NAME' \ --keyring='KEYRING_NAME' \ --location='LOCATION' \ --member='serviceAccount:service-PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com' \ --role='roles/viewer'
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 serviceAccount:service-PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com:roles/storage.objectAdmin gs://BUCKET_NAME gsutil iam ch serviceAccount:service-PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com:roles/storage.legacyBucketReader gs://BUCKET_NAME
- Learn how IAM centralizes management of permissions and access scopes for Google Cloud resources.