OS policy and OS policy assignment

An OS policy is a file that contains the declarative configuration for OS resources such as packages, repositories, files, or custom resources defined by scripts. For more information, see the resource definition for OSPolicy .

An OS policy assignment is an API resource that is used by VM Manager to apply OS policies to VMs. For more information, see the resource definition for OSPolicyAssignment .

OS policy

An OS policy is a JSON or YAML file that has three sections:

  • Mode. The policy behavior. The following two modes are available:

    • Validation : for this mode, the policy checks to see if the resources are in the chosen state but doesn't take any action.
    • Enforcement : for this mode, the policy checks to see if the resources are in the chosen state and, if not, performs the necessary actions to bring them to that chosen state.

    For both modes, VM Manager reports compliance for the OS policy and the associated resources.

  • Resource groups. The operating system name and version that the associated resource specifications apply to. For example, you can define a single policy to install or deploy an agent across different operating system distributions and versions.

  • Resources. The specifications needed for the VM to attain the selected configuration. You can specify a maximum of 10 resource IDs in each resource group. The following resource types are supported:

    • pkg : used for installing or removing Linux and Windows packages
    • repository : used for specifying which repository software packages can be installed from
    • exec : used to enable the running of an ad hoc shell ( /bin/sh ) or PowerShell script
    • file : used to manage files on the system

Example OS policies

The following examples show how to create OS policies. You can upload these OS policies to the Google Cloud console when creating an OS policy assignment.

  • Example 1: installs a package.
  • Example 2: runs a script.
  • Example 3: runs a script that is stored in a Cloud Storage bucket and copies the output file to a Cloud Storage bucket.
  • Example 4: specifies a download repository and installs packages from that repository.
  • Example 5: configures CIS benchmark scanning on VMs running Container-Optimized OS (COS). For more information about using OS policy for CIS benchmark scanning, see Automate enabling and checking of CIS compliance status .

For a full list of sample OS policies that you can apply in your environment, see the GoogleCloudPlatform/osconfig GitHub repository.

Example 1

Create an OS policy that installs a Windows MSI downloaded from a Cloud Storage bucket.

  # An OS policy to install a Windows MSI downloaded from a Google Cloud Storage bucket. 
 id 
 : 
  
 install-msi-policy 
 mode 
 : 
  
 ENFORCEMENT 
 resourceGroups 
 : 
  
 - 
  
 resources 
 : 
  
 - 
  
 id 
 : 
  
 install-msi 
  
 pkg 
 : 
  
 desiredState 
 : 
  
 INSTALLED 
  
 msi 
 : 
  
 source 
 : 
  
 gcs 
 : 
  
 bucket 
 : 
  
 my-bucket 
  
 object 
 : 
  
 my-app.msi 
  
 generation 
 : 
  
 1619136883923956 
 

Example 2

Create an OS policy that verifies if the Apache web server is running on your Linux VMs.

  # An OS policy that ensures Apache web server is running on Linux OSes. 
 id 
 : 
  
 apache-always-up-policy 
 mode 
 : 
  
 ENFORCEMENT 
 resourceGroups 
 : 
  
 - 
  
 resources 
 : 
  
 id 
 : 
  
 ensure-apache-is-up 
  
 exec 
 : 
  
 validate 
 : 
  
 interpreter 
 : 
  
 SHELL 
  
 # If Apache web server is already running, return an exit code 100 to indicate 
  
 # that exec resource is already in desired state. In this scenario, 
  
 # the `enforce` step will not be run. 
  
 # Otherwise return an exit code of 101 to indicate that exec resource is not in 
  
 # desired state. In this scenario, the `enforce` step will be run. 
  
 script 
 : 
  
 if systemctl is-active --quiet httpd; then exit 100; else exit 101; fi 
  
 enforce 
 : 
  
 interpreter 
 : 
  
 SHELL 
  
 # Start Apache web server and return an exit code of 100 to indicate that the 
  
 # resource is now in its desired state. 
  
 script 
 : 
  
 systemctl start httpd && exit 100 
 

Example 3

Create an OS policy that verifies if the Apache web server is running on your Linux VMs. In this example, the apache-validate.sh script is stored in a Cloud Storage bucket. To copy the output to a Cloud Storage bucket, the apache-enforce.sh script must include a command similar to the following:

gcsutil cp my-exec-output-file gs://my-gcs-bucket
  # An OS policy that ensures Apache web server is running on Linux OSes. 
 id 
 : 
  
 gcs-test-apache-always-up-policy 
 mode 
 : 
  
 ENFORCEMENT 
 resourceGroups 
 : 
  
 - 
  
 resources 
 : 
  
 id 
 : 
  
 ensure-apache-is-up 
  
 exec 
 : 
  
 validate 
 : 
  
 interpreter 
 : 
  
 SHELL 
  
 # If Apache web server is already running, return an exit code 100 to indicate 
  
 # that exec resource is already in desired state. In this scenario, 
  
 # the enforce step will not be run. 
  
 # Otherwise return an exit code of 101 to indicate that exec resource is not in 
  
 # desired state. In this scenario, the enforce step will be run. 
  
 file 
 : 
  
 gcs 
 : 
  
 bucket 
 : 
  
 my-gcs-bucket 
  
 object 
 : 
  
 apache-validate.sh 
  
 generation 
 : 
  
 1726747503303299 
  
 enforce 
 : 
  
 interpreter 
 : 
  
 SHELL 
  
 # Start Apache web server and return an exit code of 100 to indicate that the 
  
 # resource is now in its desired state. 
  
 file 
 : 
  
 gcs 
 : 
  
 bucket 
 : 
  
 my-gcs-bucket 
  
 object 
 : 
  
 apache-enforce.sh 
  
 generation 
 : 
  
 1726747503250884 
 

Example 4

Create an OS policy that installs Google Cloud Observability agents on CentOS VMs.

  id 
 : 
  
 cloudops-policy 
 mode 
 : 
  
 ENFORCEMENT 
 resourceGroups 
 : 
  
 - 
  
 resources 
 : 
  
 - 
  
 id 
 : 
  
 add-repo 
  
 repository 
 : 
  
 yum 
 : 
  
 id 
 : 
  
 google-cloud-ops-agent 
  
 displayName 
 : 
  
 Google Cloud Ops Agent Repository 
  
 baseUrl 
 : 
  
 https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-el7-x86_64-all 
  
 gpgKeys 
 : 
  
 - 
  
 https://packages.cloud.google.com/yum/doc/yum-key.gpg 
  
 - 
  
 https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg 
  
 - 
  
 id 
 : 
  
 install-pkg 
  
 pkg 
 : 
  
 desiredState 
 : 
  
 INSTALLED 
  
 yum 
 : 
  
 name 
 : 
  
 google-cloud-ops-agent 
  
 - 
  
 id 
 : 
  
 exec-script 
  
 exec 
 : 
  
 validate 
 : 
  
 script 
 : 
  
 |- 
  
 if [[ $(rpm --query --queryformat '%{VERSION} 
  
 ' google-cloud-ops-agent) == '1.0.2' ]]; then exit 100; else exit 101; fi 
  
 interpreter 
 : 
  
 SHELL 
  
 enforce 
 : 
  
 script 
 : 
  
 sudo yum remove -y google-cloud-ops-agent || true; sudo yum install 
  
 -y 'google-cloud-ops-agent-1.0.2*' && exit 100 
  
 interpreter 
 : 
  
 SHELL 
  
 - 
  
 id 
 : 
  
 ensure-agent-running 
  
 exec 
 : 
  
 validate 
 : 
  
 script 
 : 
  
 if (ps aux | grep 'opt[/].*google-cloud-ops-agent.*bin/'); then exit 
  
 100; else exit 101; fi 
  
 interpreter 
 : 
  
 SHELL 
  
 enforce 
 : 
  
 script 
 : 
  
 sudo systemctl start google-cloud-ops-agent.target && exit 100 
  
 interpreter 
 : 
  
 SHELL 
 

Example 5

Configures periodic CIS Level 1 scanning with the default period of once a day.

  # An OS policy to check CIS level 1 compliance once a day. 
 id 
 : 
  
 ensure-cis-level1-compliance-once-a-day-policy 
 mode 
 : 
  
 ENFORCEMENT 
 resourceGroups 
 : 
  
 - 
  
 resources 
 : 
  
 id 
 : 
  
 ensure-cis-level1-compliance-once-a-day 
  
 exec 
 : 
  
 validate 
 : 
  
 interpreter 
 : 
  
 SHELL 
  
 # If cis-compliance-scanner.service is active, return an exit code 
  
 # 100 to indicate that the instance is in compliant state. 
  
 # Otherwise, return an exit code of 101 to run `enforce` step. 
  
 script 
 : 
  
 |- 
  
 is_active=$(systemctl is-active cis-compliance-scanner.timer) 
  
 result=$(systemctl show -p Result --value cis-compliance-scanner.service) 
  
 if [ "$is_active" == "active" ] && [ "$result" == "success" ]; then 
  
 exit 100; 
  
 else 
  
 exit 101; 
  
 fi 
  
 enforce 
 : 
  
 interpreter 
 : 
  
 SHELL 
  
 # COS 97 images are by-default CIS Level 1 compliant and there is no 
  
 # additional configuration needed. However, if certain changes 
  
 # cause non-compliance because of the workload on the instance, this 
  
 # section can be used to automate to make fixes. For example, the 
  
 # workload might generate a file that does not comply with the 
  
 # recommended file permissions. 
  
 # Return an exit code of 100 to indicate that the desired changes 
  
 # successfully applied. 
  
 script 
 : 
  
 |- 
  
 # optional <your code> 
  
 # Check the compliance of the instance once a day. 
  
 systemctl start cis-compliance-scanner.timer && exit 100 
 

OS policy assignment

An OS policy assignment has the following sections:

  • OS Policies. One or more OS policies that you want to apply to your VM. To download or create a policy, see OS policies .

  • Target VMs. A set of VMs within a single zone that you want to apply the policy to. Within a zone you can limit or restrict VMs by using OS families and include or exclude labels. You can select a combination of the following options:

    • OS families: specifies the target operating systems that the OS policy applies to. For a full list of operating systems and versions that support OS policies, see Operating system details .
    • Include set: specifies the VMs that the OS policy applies to based on VM or system labels.
    • Exclude set: specifies the VMs that the OS policy should ignore based on VM or system labels.

    For both include and exclude label sets, a single string label is accepted if it matches the naming convention used by the system. However, most labels are specified in key:value pairs. For more information about labels, see Labeling resources .

    For example, you can select all the Ubuntu VMs in your test environment, and exclude those that are running Google Kubernetes Engine, by specifying the following:

    • OS family: ubuntu
    • Include: env:test , env:staging
    • Exclude: goog-gke-node
  • A rollout rate. Specifies the pace at which to apply the OS policies to the VMs. The OS policies are rolled out gradually to let you track system health and make modifications if the updates cause regressions in your environment. A rollout plan has the following components:

    • Wave size (disruption budget): the fixed number or percentage of VMs that can experience a rollout at one time. This means that at any moment of the rollout only a specified number of VMs are targeted.
    • Wait time: the time between when the service applies policies to the VM and when a VM is removed from the disruption threshold. For example, a wait time of 15 minutes means that the rollout process must wait 15 minutes after applying the policies to a VM before it can remove the VM from the disruption threshold and the rollout can proceed. The wait time helps control the speed of a rollout and also lets you catch and resolve potential rollout issues early. Select a time that is long enough for you to monitor the status of your rollouts.

    For example, if you set a target of 10 VMs, set the disruption threshold at 20%, and set a bake time of 15 minutes, then at any given time, only 2 VMs are scheduled to be updated. After each VM is updated, 15 minutes must pass before the VM is removed from the disruption threshold and another VM is added to the rollout.

    For more information about rollouts, see Rollouts .

Example OS policy assignment

The following examples show how to create OS policy assignments. You can use these examples to create OS policy assignments from the Google Cloud CLI or the OS Config API.

  • Example 1: installs a package.
  • Example 2: runs a script.
  • Example 3: specifies a download repository and installs packages from that repository.

For a list of sample OS policy assignments that you can apply in your environment, see the GoogleCloudPlatform/osconfig GitHub repository.

Example 1

Create an OS policy assignment that installs a Windows MSI downloaded from a Cloud Storage bucket.

  # An OS policy assignment to install a Windows MSI downloaded from a Google Cloud Storage bucket 
 # on all VMs running Windows Server OS. 
 osPolicies 
 : 
  
 - 
  
 id 
 : 
  
 install-msi-policy 
  
 mode 
 : 
  
 ENFORCEMENT 
  
 resourceGroups 
 : 
  
 - 
  
 resources 
 : 
  
 - 
  
 id 
 : 
  
 install-msi 
  
 pkg 
 : 
  
 desiredState 
 : 
  
 INSTALLED 
  
 msi 
 : 
  
 source 
 : 
  
 gcs 
 : 
  
 bucket 
 : 
  
 my-bucket 
  
 object 
 : 
  
 my-app.msi 
  
 generation 
 : 
  
 1619136883923956 
 instanceFilter 
 : 
  
 inventories 
 : 
  
 - 
  
 osShortName 
 : 
  
 windows 
 rollout 
 : 
  
 disruptionBudget 
 : 
  
 fixed 
 : 
  
 10 
  
 minWaitDuration 
 : 
  
 300s 
 

Example 2

Create an OS policy assignment that verifies if the Apache web server is running on all your Linux VMs.

  # An OS policy assignment that ensures Apache web server is running on Linux OSes. 
 # The assignment is applied only to those VMs that have the label `type:webserver` assigned to them. 
 osPolicies 
 : 
  
 - 
  
 id 
 : 
  
 apache-always-up-policy 
  
 mode 
 : 
  
 ENFORCEMENT 
  
 resourceGroups 
 : 
  
 - 
  
 resources 
 : 
  
 id 
 : 
  
 ensure-apache-is-up 
  
 exec 
 : 
  
 validate 
 : 
  
 interpreter 
 : 
  
 SHELL 
  
 # If Apache web server is already running, return an exit code 100 to indicate 
  
 # that exec resource is already in desired state. In this scenario, 
  
 # the `enforce` step will not be run. 
  
 # Otherwise return an exit code of 101 to indicate that exec resource is not in 
  
 # desired state. In this scenario, the `enforce` step will be run. 
  
 script 
 : 
  
 if systemctl is-active --quiet httpd; then exit 100; else exit 101; fi 
  
 enforce 
 : 
  
 interpreter 
 : 
  
 SHELL 
  
 # Start Apache web server and return an exit code of 100 to indicate that the 
  
 # resource is now in its desired state. 
  
 script 
 : 
  
 systemctl start httpd && exit 100 
 instanceFilter 
 : 
  
 inclusionLabels 
 : 
  
 - 
  
 labels 
 : 
  
 type 
 : 
  
 webserver 
 rollout 
 : 
  
 disruptionBudget 
 : 
  
 fixed 
 : 
  
 10 
  
 minWaitDuration 
 : 
  
 300s 
 

Example 3

Creates an OS policy assignment that installs Google Cloud Observability agents on CentOS VMs.

  # An OS policy assignment that ensures google-cloud-ops-agent is running on all Centos VMs in the project 
 osPolicies 
 : 
  
 - 
  
 id 
 : 
  
 cloudops-policy 
  
 mode 
 : 
  
 ENFORCEMENT 
  
 resourceGroups 
 : 
  
 resources 
 : 
  
 - 
  
 id 
 : 
  
 add-repo 
  
 repository 
 : 
  
 yum 
 : 
  
 id 
 : 
  
 google-cloud-ops-agent 
  
 displayName 
 : 
  
 Google Cloud Ops Agent Repository 
  
 baseUrl 
 : 
  
 https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-el7-x86_64-all 
  
 gpgKeys 
 : 
  
 - 
  
 https://packages.cloud.google.com/yum/doc/yum-key.gpg 
  
 - 
  
 https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg 
  
 - 
  
 id 
 : 
  
 install-pkg 
  
 pkg 
 : 
  
 desiredState 
 : 
  
 INSTALLED 
  
 yum 
 : 
  
 name 
 : 
  
 google-cloud-ops-agent 
  
 - 
  
 id 
 : 
  
 exec-script 
  
 exec 
 : 
  
 validate 
 : 
  
 script 
 : 
  
 |- 
  
 if [[ $(rpm --query --queryformat '%{VERSION} 
  
 ' google-cloud-ops-agent) == '1.0.2' ]]; then exit 100; else exit 101; fi 
  
 interpreter 
 : 
  
 SHELL 
  
 enforce 
 : 
  
 script 
 : 
  
 sudo yum remove -y google-cloud-ops-agent || true; sudo yum install 
  
 -y 'google-cloud-ops-agent-1.0.2*' && exit 100 
  
 interpreter 
 : 
  
 SHELL 
  
 - 
  
 id 
 : 
  
 ensure-agent-running 
  
 exec 
 : 
  
 validate 
 : 
  
 script 
 : 
  
 if (ps aux | grep 'opt[/].*google-cloud-ops-agent.*bin/'); then exit 
  
 100; else exit 101; fi 
  
 interpreter 
 : 
  
 SHELL 
  
 enforce 
 : 
  
 script 
 : 
  
 sudo systemctl start google-cloud-ops-agent.target && exit 100 
  
 interpreter 
 : 
  
 SHELL 
 instanceFilter 
 : 
  
 inventories 
 : 
  
 - 
  
 osShortName 
 : 
  
 centos 
 rollout 
 : 
  
 disruptionBudget 
 : 
  
 fixed 
 : 
  
 10 
  
 minWaitDuration 
 : 
  
 300s 
 

What's next?

Create a Mobile Website
View Site in Mobile | Classic
Share by: