Configure organization policies

Organization policies give you centralized and programmatic control over your organization's resources. As the organization policy administrator, you can configure policies across your entire organization.

In this version of Google Distributed Cloud (GDC) air-gapped, there is no UI or CLI for organization policies. You must use the API or kubectl CLI to manage them.

Benefits

Configuring organization policies provides several benefits:

• Centralize control to configure restrictions on how to use your organization's resources.
• Define and establish guardrails for your development teams to stay within compliance boundaries.
• Help project owners and their teams move quickly without breaking compliance.

Differences from Identity and Access Management

Identity and Access Management focuses on who , and lets the administrator authorize who can take action on specific resources based on permissions.

Organization policies focus on what , and let the administrator set restrictions on specific resources to determine how to configure them.

List of available organization policy types

In this release of GDC, you can use the following policy type.

GDCHRestrictedService

The GDCHRestrictedService policy type lets you restrict which service you can use on GDC. When applied, the policy prevents the use of the APIs that it references. For example, you can use this policy type to restrict the use of a given service to certain projects. You can also use the policy to completely restrict the access to a new GDC service that you want to run tests on before allowing your teams to use it.

Create this policy in the same cluster as the service resources. You can create multiple instances of this policy for different services or different projects.

The following is a template for this policy:

  apiVersion 
 : 
  
 constraints.gatekeeper.sh/v1beta1 
 kind 
 : 
  
 GDCHRestrictedService 
 metadata 
 : 
  
 name 
 : 
  
  POLICY_NAME 
 
 spec 
 : 
  
 match 
 : 
  
  MATCH_SCHEMA 
 
  
 parameters 
 : 
  
 disabledOperations 
 : 
  
 - 
  
  DISABLED_OPERATION 
 
 

Replace the following:

• POLICY_NAME : the name of the organization policy.

• MATCH_SCHEMA : the resources to match for this constraint. See the Define the scope of an organization policy within a cluster section for more information.

• DISABLED_OPERATION : the groups of operations that this policy blocks. The allowed values are CREATE and UPDATE . The default value for the disabledOperations field is * .

The GDCHRestrictedService policy only supports the UPDATE and CREATE operations. To restrict the GET , LIST , and DELETE operations, we recommend that you use IAM to assign roles.

The GDCHRestrictedService policy only supports the following subset of the available services on GDC.

You do not have to specify all of the kinds for a given service. You can restrict the usage of a subset of a service's features by specifying only the corresponding kinds.

For example, to restrict updates to marketplace services, create the following policy:

 apiVersion:  
constraints.gatekeeper.sh/v1beta1
kind:  
GDCHRestrictedService
metadata:  
name:  
no-update-to-marketplace-service
spec:  
match:  
kinds:  
-  
apiGroups:  
-  
 "marketplace.gdc.goog" 
  
kinds:  
-  
MarketplaceService  
parameters:  
disabledOperations:  
-  
 "UPDATE" 
 

This policy prevents any UPDATE operation on any marketplace.gdc.goog API group with the value of MarketplaceService for its kind. In effect, this policy prevents anyone from modifying any Marketplace service.

To completely disable a service, list both CREATE and UPDATE in the disabledOperations parameter, and list all the kinds documented here.

Grant IAM roles to manage organization policies

Each organization policy has an associated IAM role. Grant the IAM role to the users and groups that you want to manage that specific organization policy. To allow a user or group the ability to create, update, or delete policies of type GDCHRestrictedService , assign the user or group the gdchrestrictedservice-policy-manager IAM role.

Define the scope of an organization policy within a cluster

When defining an organization policy, decide if it should impact all namespaces, only specific namespaces, or all namespaces except a given list. To achieve this, use a combination of the .spec.match.excludedNamespaces , .spec.match.namespaceSelector , .spec.match.namespaces , and .spec.match.scope parameters of the policy definition.

Read the organization policy match section page to learn more about these parameters. For example, to allow the creation of databases only in namespaces that have the label owner: dba-team , create the following policy:

 apiVersion:  
constraints.gatekeeper.sh/v1beta1
kind:  
GDCHRestrictedService
metadata:  
name:  
db-restricted-to-dbas
spec:  
match:  
scope:  
Namespaced  
namespaceSelector:  
matchExpressions:  
 # We are restricting the use of the service in namespaces that 
  
 # don't have the owner: dba-team label 
  
-  
key:  
owner  
operator:  
NotIn  
values:  
-  
dba-team  
kinds:  
-  
apiGroups:  
-  
 "postgresql.dbadmin.gdc.goog" 
  
kinds:  
-  
DBCluster  
-  
BackupPlan  
-  
Import  
-  
Restore  
-  
apiGroups:  
-  
 "oracle.dbadmin.gdc.goog" 
  
kinds:  
-  
DBCluster  
-  
BackupPlan  
-  
Import  
parameters:  
disabledOperations:  
-  
 "UPDATE" 
  
-  
 "CREATE" 
 

Roll back an existing policy

To stop enforcing an existing policy, delete it using the kubectl CLI. Use a kubeconfig file that gives you access to the cluster where the policy is defined and to the gdchrestrictedservice-policy-manager IAM role.

To delete an organization policy, run:

 kubectl  
--kubeconfig  
 CLUSTER_KUBECONFIG 
  
delete  
 \ 
  
GDCHRestrictedService/ POLICY_NAME 
 

Replace the following:

• CLUSTER_KUBECONFIG : the kubeconfig file of the cluster where the organization policy resides.

• POLICY_NAME : the name of the organization policy to delete.

Test a policy in an audit mode

You can test a policy without enforcing it. Test a policy to make sure that a policy does not break existing systems before rolling it out, or to get an estimation of how widespread a behavior is. To add a test, add an enforcementAction to your policy definition. There are three possible values for this parameter:

• deny : the policy is enforced. This is the default setting.
• dryrun : the action is allowed, but you can see that there is a policy violation in both the audit logs and the policy status. Examine the violation with kubectl --kubeconfig CLUSTER_KUBECONFIG get POLICY_TYPE / POLICY_NAME .
• warn : equivalent to dryrun except the test also shows a warning in response to the request that triggered a policy violation.

For example, to test a policy that disables the Marketplace, create the following policy:

  apiVersion 
 : 
  
 constraints.gatekeeper.sh/v1beta1 
 kind 
 : 
  
 GDCHRestrictedService 
 metadata 
 : 
  
 name 
 : 
  
 disable-marketplace-service-project-alice 
 Spec 
 : 
  
 enforcementAction 
 : 
  
 warn 
  
 match 
 : 
  
 kinds 
 : 
  
 - 
  
 apiGroups 
 : 
  
 [ 
 "marketplace.gdc.goog" 
 ] 
  
 kinds 
 : 
  
 [ 
 "MarketplaceService" 
 ]