Stay organized with collections Save and categorize content based on your preferences.

Policy controls

This topic describes the scenarios when you should use various policy controls.

Policy controls enable you to control the type of certificates that your certificate authority (CA) pool can issue. Policy controls are of two types: coarse-grained and fine-grained. Coarse-grained policies apply CA pool-specific constraints. Fine-grained policies determine the operations a particular user can perform on a CA pool.

Certificate templates

You can use a certificate template when you have a well-defined certificate issuance scenario. You can use certificate templates to enable consistency across certificates issued from different CA pools. You can also use a certificate template to restrict the kinds of certificates that different individuals can issue. For more information, see Certificate templates.

For information about creating certificate templates, see Creating certificate templates.

Certificate issuance policies

A CA Manager can attach a certificate issuance policy to a CA pool to define restrictions on the kind of certificates that the CAs in the CA pool can issue. An issuance policy can define restrictions on certificate identities, certificate lifetimes, key types, certificate request modes, and X.509 extensions. The issuance policy can also contain a set of X.509 extensions that are applied to all incoming certificate requests.

Issuance policies let you apply certain restrictions on the entire CA pool. For example, you can use an issuance policy to enforce the following conditions:

  • All issued certificates have O=My organization in their subject.
  • All DNS names end with .my-org-domain.com.
  • The CA pool can only issue Server TLS certificates.

If one or both of the following cases apply, we recommend using a certificate issuance policy:

  1. Your CA pool is intended to issue certificates according to a single, well-defined profile.
  2. You want to define a common baseline for X.509 extensions and additional restrictions that apply to all the certificate issuance profiles.

For more information about issuance policies, see Using an issuance policy.

CA certificate name constraints

CAS enforce name constraints in CA certificates as defined in the RFC 5280 name constraints section. It allows you to control which names are permitted or excluded in certificates issued from CAs.

For example, you can create a CA with name constraints to enforce the following conditions:

  • Only my-org-domain.com and its subdomains can be used as DNS names.
  • untrusted-domain.com and its subdomains are prohibited as DNS names.

Name constraints is for CA certificate. It can only be specified on CA creation and can not be updated later.

IAM policies

It is important to implement the security principle of least privilege to protect the integrity of CA Service resources. Through the implementation of discrete Identity and Access Management (IAM) roles, organizations can better manage the security of the CA pool and the overall PKI itself.

General IAM policies

CA Service lets you grant IAM roles to users or service accounts for creating and managing resources. You can add these role bindings at the following levels:

  • CA pool-level to manage access for a specific CA pool and for the CAs in that CA pool.
  • Project or organization-level to grant access to all CA pools in that scope.

Roles are inherited, if granted at a higher resource-level. For example, a user who is granted the Auditor (roles/privateca.auditor) role at the project-level is able to view all resources under the project.

For the complete list of predefined IAM roles for CA Service, see Predefined roles.

Conditional IAM policies

If you have a shared CA pool that might be used by multiple users who are authorized to request different types of certificates, you can implement controls through conditional IAM policies to limit the per-user permissions to perform certain operations on a CA pool.

IAM conditional bindings help control the permissions a specific user or group is allowed under a set of conditions. For example, if the Certificate Requester role is bound to the user alice@example.com on a CA pool with the condition that the requested DNS SANs are a subset of ['alice@example.com', 'bob@example.com'], then that user is able to request certificates from the same CA pool only if the requested SAN is one of those two allowed values. You can set conditions on IAM bindings using Common Expression Language (CEL) expressions. These conditions can help you further restrict the type of certificates a user is able to request. For information on using CEL expressions for IAM conditions, see Common Expression Language (CEL) dialect for IAM policies.

For information on configuring IAM policies, see Configuring IAM policies.

Policy conflicts

When using different policy control mechanisms in conjunction, there is a possibility that policies on different levels can conflict. This section describes how policy controls get enforced and provides guidance on avoiding policy conflicts.

Policy enforcement

When requesting certificates, policy controls are evaluated at different layers.

IAM conditional bindings for request attributes are evaluated first to ensure the caller has the required permissions for creating certificates or using certificate templates.

During certificate creation the CA pool and the certificate template issuance policy are validated against the normalized certificate request. X.509 extensions from the CA pool's certificate issuance policy and the certificate template are added to the certificate, and certain values can be dropped based on those same policies.

Before signing the certificate, name constraints in CA certificates are validated against the certificate to ensure the subject is compliant.

Issuance policy conflicts

The following is a non-comprehensive list of errors where the issuance policy of a certificate template can conflict with the issuance policy of a CA pool.

  • A certificate template contains predefined values that are prohibited by the CA pool, or vice versa.
  • A certificate template contains different X.509 values than the CA pool baseline values, or vice versa.

In all these cases, the API returns an invalid argument error.

CEL conflicts

CEL provides the ability to implement diverse expressions. There can be situations where the CEL expressions on the CA pool's issuance policy and on the certificate template conflict. These conflicts disallow certificates to be issued from the CA pool. For example, consider the situation that a CA pool had a CEL expression enforcing the common name of a certificate to end in .example.com and the certificate template had a CEL expression enforcing the common name of a certificate to end in .example.net. Since these two CEL expressions place different restrictions on the same field, all certificate issuance requests fail.

If you are using both certificate issuance policies and certificate templates, we recommend that you ensure that their CEL expressions do not conflict.

What's next