Red Hat SummitDieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 4. Supported Red Hat Advanced Cluster Management for Kubernetes policies
View the supported policies to learn how to define rules, processes, and controls on the hub cluster when you create and manage policies in Red Hat Advanced Cluster Management for Kubernetes.
4.1. Table of sample configuration policies
View the following sample configuration policies:
| Policy sample | Description |
|---|---|
| Namespace policy | Ensure consistent environment isolation and naming with namespaces. |
| Pod policy | Ensure cluster workload configuration. |
| Memory usage policy | Limit workload resource usage using limit ranges. |
| Pod security policy (Deprecated) | Ensure consistent workload security. |
| Role policy and Role binding policy | Manage role permissions and bindings using roles and role bindings. |
| Security content constraints (SCC) policy | Manage workload permissions with Security Context Constraints. |
| ETCD encryption policy | Ensure data security with etcd encryption. |
| Compliance operator policy | Deploy the Compliance Operator to scan and enforce the compliance state of clusters leveraging OpenSCAP. |
| Compliance operator E8 scan | After applying the Compliance operator policy, deploy an Essential 8 (E8) scan to check for compliance with E8 security profiles. |
| Compliance operator CIS scan | After applying the Compliance operator policy, deploy a Center for Internet Security (CIS) scan to check for compliance with CIS security profiles. |
| Image vulnerability policy | Deploy the Container Security Operator and detect known image vulnerabilities in pods running on the cluster. |
| Gatekeeper operator deployment | Gatekeeper is an admission webhook that enforces custom resource definition-based policies that are run by the Open Policy Agent (OPA) policy engine. The Gatekeeper operator is available for installing Gatekeeper. |
| Gatekeeper compliance policy | After deploying Gatekeeper to the clusters, deploy this sample Gatekeeper policy that ensures namespaces that are created on the cluster are labeled as specified. |
| Red Hat OpenShift Platform Plus policy set |
Red Hat OpenShift Platform Plus is a hybrid-cloud suite of products to securely build, deploy, run, and manage applications for multiple infrastructures. You can deploy Red Hat OpenShift Platform Plus to managed clusters using |
Red Hat OpenShift Container Platform 4.x also supports the Red Hat Advanced Cluster Management configuration policies.
4.2. Additional resources
View the following policy documentation to learn how to apply policies:
- To learn about the supported policies, see Supported Red Hat Advanced Cluster Management for Kubernetes policies.
- Find more details about Kubernetes role-based access control in the Kubernetes RBAC documentation.
- Review the OpenShift Container Platform documentation for more details about Managing Security Context Constraints documentation.
- Review the OpenShift Container Platform documentation for more information about Encrypting etcd data.
- See Understanding the Compliance Operator in the OpenShift Container Platform documentation.
- For more details about the Container Security Operator, see the Quay GitHub repository.
- Learn how you can use Gatekeeper with Red Hat Advanced Cluster Management by reading the Gatekeeper operator overview.
- To learn more about what policy libraries are offered or just overall functionality of Gatekeeper, see the Gatekeeper documentation.
- See the OpenShift Container Platform documentation for OpenShift Platform Plus.
- For details about running Ansible jobs on violated policies, see Configuring Ansible Automation Platform for Governance.
- See Governance for more details about the feature.
4.3. Namespace policy
The Kubernetes configuration policy controller monitors the status of your namespace policy. Apply the namespace policy to define specific rules for your namespace.
Learn more details about the namespace policy structure in the following sections:
4.3.1. Namespace policy YAML structure
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name:
namespace:
annotations:
policy.open-cluster-management.io/standards:
policy.open-cluster-management.io/categories:
policy.open-cluster-management.io/controls:
policy.open-cluster-management.io/description:
spec:
remediationAction:
disabled:
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name:
spec:
remediationAction:
severity:
object-templates:
- complianceType:
objectDefinition:
kind: Namespace
apiVersion: v1
metadata:
name:
...4.3.2. Namespace policy YAML table
| Field | Optional or required | Description |
|---|---|---|
|
| Required |
Set the value to |
|
| Required |
Set the value to |
|
| Required | The name for identifying the policy resource. |
|
| Required | The namespace of the policy. |
|
| Optional |
Specifies the remediation of your policy. The parameter values are |
|
| Required |
Set the value to |
|
| Required | Used to list configuration policies containing Kubernetes objects that must be evaluated or applied to the managed clusters. |
4.3.3. Namespace policy sample
-
To view the policy sample, see the
policy-namespace.yaml. - For more details, see Managing security policies.
- Refer to Hub cluster policy framework documentation, and to the Kubernetes configuration policy controller to learn about other configuration policies.
4.4. Pod policy
The Kubernetes configuration policy controller monitors the status of your pod policies. Apply the pod policy to define the container rules for your pods. A pod must exist in your cluster to use this information.
Learn more details about the pod policy structure in the following sections:
4.4.1. Pod policy YAML structure
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name:
namespace:
annotations:
policy.open-cluster-management.io/standards:
policy.open-cluster-management.io/categories:
policy.open-cluster-management.io/controls:
policy.open-cluster-management.io/description:
spec:
remediationAction:
disabled:
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name:
spec:
remediationAction:
severity:
namespaceSelector:
exclude:
include:
matchLabels:
matchExpressions:
object-templates:
- complianceType:
objectDefinition:
apiVersion: v1
kind: Pod
metadata:
name:
spec:
containers:
- image:
name:
...4.4.2. Pod policy table
| Field | Optional or required | Description |
|---|---|---|
|
| Required |
Set the value to |
|
| Required |
Set the value to |
|
| Required | The name for identifying the policy resource. |
|
| Required | The namespace of the policy. |
|
| Optional |
Specifies the remediation of your policy. The parameter values are |
|
| Required |
Set the value to |
|
| Required | Used to list configuration policies containing Kubernetes objects that must be evaluated or applied to the managed clusters. |
4.4.3. Pod policy sample
Refer to Kubernetes configuration policy controller to view other configuration policies that are monitored by the configuration controller, and see the Hub cluster policy framework to see a full description of the policy YAML structure and additional fields. Return to Creating configuration policies documentation to manage other policies.
4.5. Memory usage policy
The Kubernetes configuration policy controller monitors the status of the memory usage policy. Use the memory usage policy to limit or restrict your memory and compute usage. For more information, see Limit Ranges in the Kubernetes documentation.
Learn more details about the memory usage policy structure in the following sections:
4.5.1. Memory usage policy YAML structure
Your memory usage policy might resemble the following YAML file:
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name:
namespace:
annotations:
policy.open-cluster-management.io/standards:
policy.open-cluster-management.io/categories:
policy.open-cluster-management.io/controls:
policy.open-cluster-management.io/description:
spec:
remediationAction:
disabled:
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name:
spec:
remediationAction:
severity:
namespaceSelector:
exclude:
include:
matchLabels:
matchExpressions:
object-templates:
- complianceType: mustonlyhave
objectDefinition:
apiVersion: v1
kind: LimitRange
metadata:
name:
spec:
limits:
- default:
memory:
defaultRequest:
memory:
type:
...4.5.2. Memory usage policy table
| Field | Optional or required | Description |
|---|---|---|
|
| Required |
Set the value to |
|
| Required |
Set the value to |
|
| Required | The name for identifying the policy resource. |
|
| Required | The namespace of the policy. |
|
| Optional |
Specifies the remediation of your policy. The parameter values are |
|
| Required |
Set the value to |
|
| Required | Used to list configuration policies containing Kubernetes objects that must be evaluated or applied to the managed clusters. |
4.5.3. Memory usage policy sample
-
To view a sample of the policy, review the
policy-limitmemory.yaml. - For more details, see Managing security policies.
- Refer to the Hub cluster policy framework documentation, and to Kubernetes configuration policy controller to view other configuration policies that are monitored by the controller.
4.6. Pod security policy (Deprecated)
The Kubernetes configuration policy controller monitors the status of the pod security policy. Apply a pod security policy to secure pods and containers.
Learn more details about the pod security policy structure in the following sections:
4.6.1. Pod security policy YAML structure
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name:
namespace:
annotations:
policy.open-cluster-management.io/standards:
policy.open-cluster-management.io/categories:
policy.open-cluster-management.io/controls:
policy.open-cluster-management.io/description:
spec:
remediationAction:
disabled:
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name:
spec:
remediationAction:
severity:
namespaceSelector:
exclude:
include:
matchLabels:
matchExpressions:
object-templates:
- complianceType:
objectDefinition:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name:
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames:
spec:
privileged:
allowPrivilegeEscalation:
allowedCapabilities:
volumes:
hostNetwork:
hostPorts:
hostIPC:
hostPID:
runAsUser:
seLinux:
supplementalGroups:
fsGroup:
...4.6.2. Pod security policy table
| Field | Optional or required | Description |
|---|---|---|
|
| Required |
Set the value to |
|
| Required |
Set the value to |
|
| Required | The name for identifying the policy resource. |
|
| Required | The namespace of the policy. |
|
| Optional |
Specifies the remediation of your policy. The parameter values are |
|
| Required |
Set the value to |
|
| Required | Used to list configuration policies containing Kubernetes objects that must be evaluated or applied to the managed clusters. |
4.6.3. Pod security policy sample
The support of pod security policies is removed from OpenShift Container Platform and from Kubernetes v1.25 and later. If you apply a PodSecurityPolicy resource, you might receive the following non-compliant message:
violation - couldn't find mapping resource with kind PodSecurityPolicy, please check if you have CRD deployed- For more information including the deprecation notice, see Pod Security Policies in the Kubernetes documentation.
-
To view the sample policy, review
policy-psp.yaml. View Creating configuration policies for more information. - Refer to the Hub cluster policy framework documentation for a full description of the policy YAML structure, and Kubernetes configuration policy controller to view other configuration policies that are monitored by the controller.
4.7. Role policy
The Kubernetes configuration policy controller monitors the status of role policies. Define roles in the object-template to set rules and permissions for specific roles in your cluster.
Learn more details about the role policy structure in the following sections:
4.7.1. Role policy YAML structure
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name:
namespace:
annotations:
policy.open-cluster-management.io/standards:
policy.open-cluster-management.io/categories:
policy.open-cluster-management.io/controls:
policy.open-cluster-management.io/description:
spec:
remediationAction:
disabled:
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name:
spec:
remediationAction:
severity:
namespaceSelector:
exclude:
include:
matchLabels:
matchExpressions:
object-templates:
- complianceType:
objectDefinition:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name:
rules:
- apiGroups:
resources:
verbs:
...4.7.2. Role policy table
| Field | Optional or required | Description |
|---|---|---|
|
| Required |
Set the value to |
|
| Required |
Set the value to |
|
| Required | The name for identifying the policy resource. |
|
| Required | The namespace of the policy. |
|
| Optional |
Specifies the remediation of your policy. The parameter values are |
|
| Required |
Set the value to |
|
| Required | Used to list configuration policies containing Kubernetes objects that must be evaluated or applied to the managed clusters. |
4.7.3. Role policy sample
Apply a role policy to set rules and permissions for specific roles in your cluster. For more information on roles, see Role-based access control.
To learn how to manage role policies, refer to Creating configuration policies for more information. See the Kubernetes configuration policy controller to view other configuration policies that are monitored the controller.
4.8. Role binding policy
The Kubernetes configuration policy controller monitors the status of your role binding policy. Apply a role binding policy to bind a policy to a namespace in your managed cluster.
Learn more details about the namespace policy structure in the following sections:
4.8.1. Role binding policy YAML structure
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name:
namespace:
annotations:
policy.open-cluster-management.io/standards:
policy.open-cluster-management.io/categories:
policy.open-cluster-management.io/controls:
policy.open-cluster-management.io/description:
spec:
remediationAction:
disabled:
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name:
spec:
remediationAction:
severity:
namespaceSelector:
exclude:
include:
matchLabels:
matchExpressions:
object-templates:
- complianceType:
objectDefinition:
kind: RoleBinding # role binding must exist
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name:
subjects:
- kind:
name:
apiGroup:
roleRef:
kind:
name:
apiGroup:
...4.8.2. Role binding policy table
| Field | Optional or required | Description |
|---|---|---|
|
| Required |
Set the value to |
|
| Required |
Set the value to |
|
| Required | The name for identifying the policy resource. |
|
| Required | The namespace of the policy. |
|
| Optional |
Specifies the remediation of your policy. The parameter values are |
|
| Required |
Set the value to |
|
| Required | Used to list configuration policies containing Kubernetes objects that must be evaluated or applied to the managed clusters. |
4.8.3. Role binding policy sample
For a full description of the policy YAML structure and additional fields, see the Hub cluster policy framework. Refer to Kubernetes configuration policy controller documentation to learn about other configuration policies.
4.9. Security Context Constraints policy
The Kubernetes configuration policy controller monitors the status of your Security Context Constraints (SCC) policy. Apply an Security Context Constraints (SCC) policy to control permissions for pods by defining conditions in the policy.
Learn more details about SCC policies in the following sections:
4.9.1. SCC policy YAML structure
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name:
namespace:
annotations:
policy.open-cluster-management.io/standards:
policy.open-cluster-management.io/categories:
policy.open-cluster-management.io/controls:
policy.open-cluster-management.io/description:
spec:
remediationAction:
disabled:
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name:
spec:
remediationAction:
severity:
namespaceSelector:
exclude:
include:
matchLabels:
matchExpressions:
object-templates:
- complianceType:
objectDefinition:
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
name:
allowHostDirVolumePlugin:
allowHostIPC:
allowHostNetwork:
allowHostPID:
allowHostPorts:
allowPrivilegeEscalation:
allowPrivilegedContainer:
fsGroup:
readOnlyRootFilesystem:
requiredDropCapabilities:
runAsUser:
seLinuxContext:
supplementalGroups:
users:
volumes:
...4.9.2. SCC policy table
| Field | Optional or required | Description |
|---|---|---|
|
| Required |
Set the value to |
|
| Required |
Set the value to |
|
| Required | The name for identifying the policy resource. |
|
| Required | The namespace of the policy. |
|
| Optional |
Specifies the remediation of your policy. The parameter values are |
|
| Required |
Set the value to |
|
| Required | Used to list configuration policies containing Kubernetes objects that must be evaluated or applied to the managed clusters. |
For explanations on the contents of a SCC policy, see Managing Security Context Constraints from the OpenShift Container Platform documentation.
4.9.3. SCC policy sample
Apply a Security context constraints (SCC) policy to control permissions for pods by defining conditions in the policy. For more information, see Managing Security Context Constraints.
To view the policy sample, see policy-scc.yaml. For a full description of the policy YAML structure and additional fields, see the Hub cluster policy framework documentation. Refer to Kubernetes configuration policy controller documentation to learn about other configuration policies.
4.10. ETCD encryption policy
Apply the etcd-encryption policy to detect, or enable encryption of sensitive data in the ETCD data-store. The Kubernetes configuration policy controller monitors the status of the etcd-encryption policy. For more information, see Encrypting etcd data in the OpenShift Container Platform documentation. Note: The ETCD encryption policy only supports Red Hat OpenShift Container Platform 4 and later.
Learn more details about the etcd-encryption policy structure in the following sections:
4.10.1. ETCD encryption policy YAML structure
Your etcd-encryption policy might resemble the following YAML file:
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name:
namespace:
annotations:
policy.open-cluster-management.io/standards:
policy.open-cluster-management.io/categories:
policy.open-cluster-management.io/controls:
policy.open-cluster-management.io/description:
spec:
remediationAction:
disabled:
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name:
spec:
remediationAction:
severity:
object-templates:
- complianceType:
objectDefinition:
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
name:
spec:
encryption:
...4.10.2. ETCD encryption policy table
| Field | Optional or required | Description |
|---|---|---|
|
| Required |
Set the value to |
|
| Required |
Set the value to |
|
| Required | The name for identifying the policy resource. |
|
| Required | The namespace of the policy. |
|
| Optional |
Specifies the remediation of your policy. The parameter values are |
|
| Required |
Set the value to |
|
| Required | Used to list configuration policies containing Kubernetes objects that must be evaluated or applied to the managed clusters. |
4.10.3. ETCD encryption policy sample
See the Hub cluster policy framework documentation and the Kubernetes configuration policy controller to view additional details on policy and configuration policy fields.
4.11. Compliance Operator policy
You can use the Compliance Operator to automate the inspection of numerous technical implementations and compare those against certain aspects of industry standards, benchmarks, and baselines. The Compliance Operator is not an auditor. To be compliant or certified with these various standards, you need to engage an authorized auditor such as a Qualified Security Assessor (QSA), Joint Authorization Board (JAB), or other industry recognized regulatory authority to assess your environment.
Recommendations that are generated from the Compliance Operator are based on generally available information and practices regarding such standards, and might assist you with remediations, but actual compliance is your responsibility. Work with an authorized auditor to achieve compliance with a standard.
For the latest updates, see the Compliance Operator release notes.
4.11.1. Compliance Operator policy overview
You can install the Compliance Operator on your managed cluster by using the Compliance Operator policy. The Compliance operator policy is created as a Kubernetes configuration policy in Red Hat Advanced Cluster Management. OpenShift Container Platform supports the compliance operator policy.
Note: The Compliance operator policy relies on the OpenShift Container Platform Compliance Operator, which is not supported on the IBM Power or IBM Z architectures. See Understanding the Compliance Operator in the OpenShift Container Platform documentation for more information about the Compliance Operator.
4.11.2. Compliance operator resources
When you create a compliance operator policy, the following resources are created:
-
A compliance operator namespace (
openshift-compliance) for the operator installation:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name: comp-operator-ns
spec:
remediationAction: inform # will be overridden by remediationAction in parent policy
severity: high
object-templates:
- complianceType: musthave
objectDefinition:
apiVersion: v1
kind: Namespace
metadata:
name: openshift-compliance-
An operator group (
compliance-operator) to specify the target namespace:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name: comp-operator-operator-group
spec:
remediationAction: inform # will be overridden by remediationAction in parent policy
severity: high
object-templates:
- complianceType: musthave
objectDefinition:
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: compliance-operator
namespace: openshift-compliance
spec:
targetNamespaces:
- openshift-compliance-
A subscription (
comp-operator-subscription) to reference the name and channel. The subscription pulls the profile, as a container, that it supports. See the following sample, with the current version replacing4.x:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name: comp-operator-subscription
spec:
remediationAction: inform # will be overridden by remediationAction in parent policy
severity: high
object-templates:
- complianceType: musthave
objectDefinition:
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: compliance-operator
namespace: openshift-compliance
spec:
channel: "4.x"
installPlanApproval: Automatic
name: compliance-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
After you install the compliance operator policy, the following pods are created: compliance-operator, ocp4, and rhcos4.
4.11.3. Additional resources
- For more information, see Managing the Compliance Operator in the OpenShift Container Platform documentation for more details.
- You can also create and apply the E8 scan policy and OpenShift CIS scan policy, after you have installed the compliance operator. For more information, see E8 scan policy and OpenShift CIS scan policy.
- To learn about managing compliance operator policies, see Managing security policies for more details. Refer to Kubernetes configuration policy controller for more topics about configuration policies.
4.12. E8 scan policy
An Essential 8 (E8) scan policy deploys a scan that checks the master and worker nodes for compliance with the E8 security profiles. You must install the compliance operator to apply the E8 scan policy.
The E8 scan policy is created as a Kubernetes configuration policy in Red Hat Advanced Cluster Management. OpenShift Container Platform supports the E8 scan policy. For more information, see Managing the Compliance Operator in the OpenShift Container Platform documentation for more details.
4.12.1. E8 scan policy resources
When you create an E8 scan policy the following resources are created:
A
ScanSettingBindingresource (e8) to identify which profiles to scan:apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: compliance-suite-e8 spec: remediationAction: inform severity: high object-templates: - complianceType: musthave # this template checks if scan has completed by checking the status field objectDefinition: apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: e8 namespace: openshift-compliance profiles: - apiGroup: compliance.openshift.io/v1alpha1 kind: Profile name: ocp4-e8 - apiGroup: compliance.openshift.io/v1alpha1 kind: Profile name: rhcos4-e8 settingsRef: apiGroup: compliance.openshift.io/v1alpha1 kind: ScanSetting name: defaultA
ComplianceSuiteresource (compliance-suite-e8) to verify if the scan is complete by checking thestatusfield:apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: compliance-suite-e8 spec: remediationAction: inform severity: high object-templates: - complianceType: musthave # this template checks if scan has completed by checking the status field objectDefinition: apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceSuite metadata: name: e8 namespace: openshift-compliance status: phase: DONEA
ComplianceCheckResultresource (compliance-suite-e8-results) which reports the results of the scan suite by checking theComplianceCheckResultcustom resources (CR):apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: compliance-suite-e8-results spec: remediationAction: inform severity: high object-templates: - complianceType: mustnothave # this template reports the results for scan suite: e8 by looking at ComplianceCheckResult CRs objectDefinition: apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceCheckResult metadata: namespace: openshift-compliance labels: compliance.openshift.io/check-status: FAIL compliance.openshift.io/suite: e8
Note: Automatic remediation is supported. Set the remediation action to enforce to create ScanSettingBinding resource.
See Managing security policies for more information. Note: After your E8 policy is deleted, it is removed from your target cluster or clusters.
4.13. OpenShift CIS scan policy
An OpenShift CIS scan policy deploys a scan that checks the master and worker nodes for compliance with the OpenShift CIS security benchmark. You must install the compliance operator to apply the OpenShift CIS policy.
The OpenShift CIS scan policy is created as a Kubernetes configuration policy in Red Hat Advanced Cluster Management. OpenShift Container Platform supports the OpenShift CIS scan policy. For more information, see Understanding the Compliance Operator in the OpenShift Container Platform documentation for more details.
4.13.1. OpenShift CIS resources
When you create an OpenShift CIS scan policy the following resources are created:
A
ScanSettingBindingresource (cis) to identify which profiles to scan:apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: compliance-cis-scan spec: remediationAction: inform severity: high object-templates: - complianceType: musthave # this template creates ScanSettingBinding:cis objectDefinition: apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: cis namespace: openshift-compliance profiles: - apiGroup: compliance.openshift.io/v1alpha1 kind: Profile name: ocp4-cis - apiGroup: compliance.openshift.io/v1alpha1 kind: Profile name: ocp4-cis-node settingsRef: apiGroup: compliance.openshift.io/v1alpha1 kind: ScanSetting name: defaultA
ComplianceSuiteresource (compliance-suite-cis) to verify if the scan is complete by checking thestatusfield:apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: compliance-suite-cis spec: remediationAction: inform severity: high object-templates: - complianceType: musthave # this template checks if scan has completed by checking the status field objectDefinition: apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceSuite metadata: name: cis namespace: openshift-compliance status: phase: DONEA
ComplianceCheckResultresource (compliance-suite-cis-results) which reports the results of the scan suite by checking theComplianceCheckResultcustom resources (CR):apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: compliance-suite-cis-results spec: remediationAction: inform severity: high object-templates: - complianceType: mustnothave # this template reports the results for scan suite: cis by looking at ComplianceCheckResult CRs objectDefinition: apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceCheckResult metadata: namespace: openshift-compliance labels: compliance.openshift.io/check-status: FAIL compliance.openshift.io/suite: cis
For more information on creating policies, see Managing security policies.
4.14. Image vulnerability policy
Apply the image vulnerability policy to detect if container images have vulnerabilities by leveraging the Container Security Operator. The policy installs the Container Security Operator on your managed cluster if it is not installed.
The image vulnerability policy is checked by the Kubernetes configuration policy controller. For more information about the Security Operator, see the Container Security Operator from the Quay repository.
Notes:
- Image vulnerability policy is not functional during a disconnected installation.
- The Image vulnerability policy is not supported on the ARM architecture.
View the following sections to learn more:
4.14.1. Image vulnerability policy YAML structure
When you create the container security operator policy, it involves the following policies:
A policy that creates the subscription (
container-security-operator) to reference the name and channel. This operator policy must havespec.remediationActionset toenforceto create the resources. View the following example:apiVersion: policy.open-cluster-management.io/v1beta1 kind: OperatorPolicy metadata: name: operatorpolicy-imagemanifestvuln spec: remediationAction: enforce severity: high complianceType: musthave upgradeApproval: Automatic subscription: name: container-security-operator namespace: openshift-operators source: redhat-operators sourceNamespace: openshift-marketplaceAn
informconfiguration policy to audit whether anyImageManifestVulnobjects were created by the image vulnerability scans. View the following example:apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: policy-imagemanifestvuln-example-imv spec: remediationAction: inform # will be overridden by remediationAction in parent policy severity: high namespaceSelector: exclude: ["kube-*"] include: ["*"] object-templates: - complianceType: mustnothave # mustnothave any ImageManifestVuln object objectDefinition: apiVersion: secscan.quay.redhat.com/v1alpha1 kind: ImageManifestVuln # checking for a Kind
4.14.2. Image vulnerability policy sample
For more information, see:
-
See Managing security policies and
policy-imagemanifestvuln.yaml. - Refer to Kubernetes configuration policy controller to view other configuration policies that are monitored by the configuration controller.
4.15. Red Hat OpenShift Platform Plus policy set
Configure and apply the OpenShift Platform Plus policy set (openshift-plus) to install Red Hat OpenShift Platform Plus.
The OpenShift Platform Plus policy set contains two PolicySets that are deployed. The OpenShift Plus policy set applies multiple policies that are set to install OpenShift Platform Plus products. The Red Hat Advanced Cluster Security secured cluster services and the Compliance Operator are deployed onto all of your OpenShift Container Platform managed clusters.
4.15.1. Prerequisites
- Install Red Hat OpenShift Container Platform on Amazon Web Services (AWS) environment.
- Install Red Hat Advanced Cluster Management for Kubernetes.
- Install the Policy Generator Kustomize plugin. See the Policy Generator documentation for more information.
4.15.2. OpenShift Platform Plus policy set components
When you apply the policy set to the hub cluster, the following OpenShift Platform Plus components are installed:
| Component | Policy | Description |
|---|---|---|
| Red Hat Advanced Cluster Security |
| Policy used to install the central server onto the Red Hat Advanced Cluster Management for Kubernetes hub cluster and the managed clusters. |
|
| Deployments to receive Red Hat Advanced Cluster Security status. | |
|
| Configuration for the Red Hat Advanced Cluster Security central operator. | |
|
| Policy used to verify that the Red Hat Advanced Cluster Security resources are created. | |
| OpenShift Container Platform |
| The managed hub cluster. Manager of the managed cluster. |
| Compliance operator |
| Policy used to install the Compliance operator. |
| Red Hat Quay |
| Configuration policy for Red Hat Quay. |
|
| Policy used to install Red Hat Quay. | |
|
| Installed onto the Red Hat Advanced Cluster Management hub cluster. | |
| Red Hat Advanced Cluster Management |
| Sets up the Red Hat Advanced Cluster Management observability service. |
| Red Hat OpenShift Data Platform |
| Available storage for the hub cluster components that is used by Red Hat Advanced Cluster Management observability and Quay. |
|
| Policy used to configure the Red Hat OpenShift Data Platform status. |
4.15.3. Additional resources
4.16. Managing security policies
Create a security policy to report and validate your cluster compliance based on your specified security standards, categories, and controls.
View the following sections:
4.16.1. Creating a security policy
You can create a security policy from the command line or from the console.
Required access: Cluster administrator
Important: * You must define a placement and placement binding to apply your policy to a specific cluster. The PlacementBinding resource binds the placement. Enter a valid value for the cluster Label selector field to define a Placement and PlacementBinding resource. * In order to use a Placement resource, a ManagedClusterSet resource must be bound to the namespace of the Placement resource with a ManagedClusterSetBinding resource. Refer to Creating a ManagedClusterSetBinding resource for additional details.
4.16.1.1. Creating a security policy from the command line interface
Complete the following steps to create a policy from the command line:
Create a policy by running the following command:
oc create -f policy.yaml -n <policy-namespace>Define the template that the policy uses. Edit your YAML file by adding a
policy-templatesfield to define a template. Your policy might resemble the following YAML file:apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: policy1 spec: remediationAction: "enforce" # or inform disabled: false # or true namespaceSelector: include: - "default" - "my-namespace" policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: operator # namespace: # will be supplied by the controller via the namespaceSelector spec: remediationAction: "inform" object-templates: - complianceType: "musthave" # at this level, it means the role must exist and must have the following rules apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: example objectDefinition: rules: - complianceType: "musthave" # at this level, it means if the role exists the rule is a musthave apiGroups: ["extensions", "apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "delete","patch"]Define a
PlacementBindingresource to bind your policy to yourPlacementresource. YourPlacementBindingresource might resemble the following YAML sample:apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding1 placementRef: name: placement1 apiGroup: cluster.open-cluster-management.io kind: Placement subjects: - name: policy1 apiGroup: policy.open-cluster-management.io kind: Policy
4.16.1.1.1. Viewing your security policy from the command line
Complete the following steps to view your security policy from the command line:
View details for a specific security policy by running the following command:
oc get policies.policy.open-cluster-management.io <policy-name> -n <policy-namespace> -o yamlView a description of your security policy by running the following command:
oc describe policies.policy.open-cluster-management.io <policy-name> -n <policy-namespace>
4.16.1.2. Creating a cluster security policy from the console
After you log in to your Red Hat Advanced Cluster Management, navigate to the Governance page and click Create policy. As you create your new policy from the console, a YAML file is also created in the YAML editor. To view the YAML editor, select the toggle at the beginning of the Create policy form to enable it.
Complete the Create policy form, then select the Submit button. Your YAML file might resemble the following policy:
apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: policy-pod annotations: policy.open-cluster-management.io/categories: 'SystemAndCommunicationsProtections,SystemAndInformationIntegrity' policy.open-cluster-management.io/controls: 'control example' policy.open-cluster-management.io/standards: 'NIST,HIPAA' policy.open-cluster-management.io/description: spec: complianceType: musthave namespaces: exclude: ["kube*"] include: ["default"] pruneObjectBehavior: None object-templates: - complianceType: musthave objectDefinition: apiVersion: v1 kind: Pod metadata: name: pod1 spec: containers: - name: pod-name image: 'pod-image' ports: - containerPort: 80 remediationAction: enforce disabled: falseSee the following
PlacementBindingexample:apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-pod placementRef: name: placement-pod kind: Placement apiGroup: cluster.open-cluster-management.io subjects: - name: policy-pod kind: Policy apiGroup: policy.open-cluster-management.ioSee the following
Placementexample:apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement-pod spec: predicates: - requiredClusterSelector: labelSelector: matchLabels: cloud: "IBM" tolerations: - key: cluster.open-cluster-management.io/unavailable operator: Exists - key: cluster.open-cluster-management.io/unreachable operator: Exists- Optional: Add a description for your policy.
- Click Create Policy. A security policy is created from the console.
4.16.1.2.1. Viewing your security policy from the console
View any security policy and the status from the console.
- Navigate to the Governance page to view a table list of your policies. Note: You can filter the table list of your policies by selecting the Policies tab or Cluster violations tab.
-
Select one of your policies to view more details. The Details, Clusters, and Templates tabs are displayed. When the cluster or policy status cannot be determined, the following message is displayed:
No status. - Alternatively, select the Policies tab to view the list of policies. Expand a policy row to view the Description, Standards, Controls, and Categories details.
4.16.1.3. Creating policy sets from the command line
By default, the policy set is created with no policies or placements. You must create a placement for the policy set and have at least one policy that exists on your cluster. When you create a policy set, you can add numerous policies.
Run the following command to create a policy set from the command line:
oc apply -f <policyset-filename>4.16.1.4. Creating policy sets from the console
- From the navigation menu, select Governance.
- Select the Policy sets tab.
- Select the Create policy set button and complete the form.
- Add the details for your policy set and select the Submit button.
Your policy is listed from the policy table.
4.16.2. Updating security policies
Learn to update security policies.
4.16.2.1. Adding a policy to a policy set from the command line
Run the following command to edit your policy set:
oc edit policysets <your-policyset-name>-
Add the policy name to the list in the
policiessection of the policy set. - Apply your added policy in the placement section of your policy set with the following command:
oc apply -f <your-added-policy.yaml>
PlacementBinding and Placement are both created.
Note: If you delete the placement binding, the policy is still placed by the policy set.
4.16.2.2. Adding a policy to a policy set from the console
- Add a policy to the policy set by selecting the Policy sets tab.
- Select the Actions icon and select Edit. The Edit policy set form appears.
- Navigate to the Policies section of the form to select a policy to add to the policy set.
4.16.2.3. Disabling security policies
Your policy is enabled by default. Disable your policy from the console.
After you log in to your Red Hat Advanced Cluster Management for Kubernetes console, navigate to the Governance page to view a table list of your policies.
Select the Actions icon > Disable policy. The Disable Policy dialog box appears.
Click Disable policy. Your policy is disabled.
4.16.3. Deleting a security policy
Delete a security policy from the command line or the console.
Use the following procedure to delete from the command line:
Delete a security policy by running the following command:
oc delete policies.policy.open-cluster-management.io <policy-name> -n <policy-namespace>-
Verify that your policy is removed by running the following command:
oc get policies.policy.open-cluster-management.io <policy-name> -n <policy-namespace>
Use the following procedure to delete a security policy from the console.
- From the navigation menu, click Governance to view a table list of your policies.
- Click the Actions icon for the policy you want to delete in the policy violation table.
- Click Remove.
- From the Remove policy dialog box, click Remove policy.
4.16.3.1. Deleting policy sets from the console
- From the Policy sets tab, select the Actions icon for the policy set. When you click Delete, the Permanently delete Policyset? dialogue box appears.
- Click the Delete button.
4.16.4. Cleaning up resources that are created by policies
Use the pruneObjectBehavior parameter in a configuration policy to clean up resources that are created by the policy. When pruneObjectBehavior is set, the related objects are only cleaned up after the configuration policy (or parent policy) associated with them is deleted.
View the following descriptions of the values that can be used for the parameter:
-
DeleteIfCreated: Cleans up any resources created by the policy. -
DeleteAll: Cleans up all resources managed by the policy. -
None: This is the default value and maintains the same behavior from previous releases, where no related resources are deleted.
You can set the value directly in the YAML file as you create a policy from the command line.
From the console, you can select the value in the Prune Object Behavior section of the Policy templates step.
Notes:
-
If a policy that installs an operator has the
pruneObjectBehaviorparameter defined, then additional clean up is needed to complete the operator uninstall. You might need to delete the operatorClusterServiceVersionobject as part of this cleanup. -
As you disable the
config-policy-addonresource on the managed cluster, thepruneObjbectBehavioris ignored. To automatically clean up the related resources on the policies, you must remove the policies from the managed cluster before the add-on is disabled.
4.16.5. Policy command-line tool
With the policytools command-line tool, you can interact with policies locally to help with creating and debugging. The policytools command-line tool is available for download from the hub cluster console. See Command line tools.
template-resolverThe
template-resolveris a subcommand forpolicytoolsthat resolves managed cluster and hub cluster templates that are embedded in policies. Thetemplate-resolverreads from either a file, or from standard input.To resolve a policy with hub cluster templates, you must provide the
--cluster-nameargument with the name of a managed cluster that is imported into Red Hat Advanced Cluster Management, and you must provide the--hub-kubeconfigargument with the path to akubeconfigfile that references the hub cluster.If the input policy uses the
.ObjectNameor.ObjectNamespacetemplate variables, you need to set the values with the--object-nameand--object-namespacearguments.The
template-resolversubcommand connects to the managed cluster and hub cluster to retrieve information that is necessary to resolve the templates. Provide paths by using the--save-resourcesand--save-hub-resourcesarguments to save the resources that thetemplate-resolverretrieves. Those saved files can be used as inputs for thedryrunsubcommand.Technology Preview: The
policytoolscommand-line interface introduces a--lintargument for thetemplate-resolversubcommand to print any linting issues, along with the resolved Go templates from the input policy.dryrunThe
dryrunis a subcommand forpolicytoolsthat evaluates aConfigurationPolicyresource locally by using static input resources for the cluster state.To run a policy, add the path to the
ConfigurationPolicyYAML by using the--policyflag. You can provide additional resource YAML files, which are used as the current cluster state. For example, if your policy defines a specific configuration for a namespace, provide the current namespace state to see what the policy does. Multiple resources can be in the same resource file.To evaluate a policy against the current state of a live cluster, use the
--from-clusterflag or set theDRYRUN_FROM_CLUSTERenvironment variable totrue.
The dryrun subcommand reads the current state of resources directly from the cluster that you configured in your kubeconfig file or from the cluster that is specified by the KUBECONFIG environment variable. In both these scenarios, the dryun subcommand does not gather information from the resource files.
When you enable the --from-cluster flag, it ignores any YAML resource files that are provided as input. Enabling the --from-cluster flag allows you to test a policy against your actual cluster state without manually exporting and supporting resource files.
+ By default, dryrun prints the differences between the desired states of objects that are defined in the policy and the current state of those resources, as well as compliance messages that the ConfigurationPolicy creates.
To save the compliance messages to a separate file, use the --messages-path argument. To save the full policy status, including additional information about the related objects, use the --status-path argument.
+ If the policy is NonCompliant based on the input, the tool returns a non-zero exit code. To compare the resulting status against a known status, use the --desired-status argument. For example, to verify that the policy reports a missing resource, provide a YAML file with the missing resource inside a .relatedObjects list. To verify that the policy is NonCompliant, create a YAML file with the compliant: NonCompliant line.
4.16.6. Additional resources
- View more descriptions of the policy YAML files in the Hub cluster policy framework[Policy overview].
- See Resources that support support set-based requirements in the Kubernetes documentation for a valid expression.
-
View the stable
Policysets, which require the Policy Generator for deployment, PolicySets-- Stable. - Refer to Governance for more topics about policies.
4.16.7. Managing operator policies in disconnected environments
You might need to deploy Red Hat Advanced Cluster Management for Kubernetes policies on Red Hat OpenShift Container Platform clusters that are not connected to the internet (disconnected). If the policies you deploy are used to deploy policies that install an Operator Lifecycle Manager operator, you must follow the procedure for Mirroring an Operator catalog.
Complete the following steps to validate access to the operator images:
See Verify required packages are available to validate that packages you require to use with policies are available. You must validate availability for each image registry used by any managed cluster that the following policies are deployed to:
-
container-security-operator -
Deprecated:
gatekeeper-operator-product -
compliance-operator
-
See Configure image content source policies to validate that the sources are available. The image content source policies must exist on each of the disconnected managed clusters and can be deployed using a policy to simplify the process. See the following table of image source locations:
Expand Governance policy type Image source location Container security
registry.redhat.io/quayCompliance
registry.redhat.io/complianceGatekeeper
registry.redhat.io/rhacm2
4.16.8. Installing Red Hat OpenShift Platform Plus by using a policy set
Continue reading for guidance to apply the Red Hat Openshift Platform Plus policy set. When you apply the Red Hat OpenShift policy set, the Red Hat Advanced Cluster Security secured cluster services and the Compliance Operator are deployed onto all of your OpenShift Container Platform managed clusters.
4.16.8.1. Prerequisites
Complete the following steps before you apply the policy set:
To allow for subscriptions to be applied to your cluster, you must apply the
policy-configure-subscription-admin-hub.yamlpolicy and set the remediation action toenforce. Copy and paste the following YAML into the YAML editor of the console:apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: policy-configure-subscription-admin-hub annotations: policy.open-cluster-management.io/standards: NIST SP 800-53 policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration spec: remediationAction: inform disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: policy-configure-subscription-admin-hub spec: remediationAction: inform severity: low object-templates: - complianceType: musthave objectDefinition: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: open-cluster-management:subscription-admin rules: - apiGroups: - app.k8s.io resources: - applications verbs: - '*' - apiGroups: - apps.open-cluster-management.io resources: - '*' verbs: - '*' - apiGroups: - "" resources: - configmaps - secrets - namespaces verbs: - '*' - complianceType: musthave objectDefinition: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: open-cluster-management:subscription-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: open-cluster-management:subscription-admin subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: kube:admin - apiGroup: rbac.authorization.k8s.io kind: User name: system:admin --- apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: binding-policy-configure-subscription-admin-hub placementRef: name: placement-policy-configure-subscription-admin-hub kind: Placement apiGroup: cluster.open-cluster-management.io subjects: - name: policy-configure-subscription-admin-hub kind: Policy apiGroup: policy.open-cluster-management.io --- apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement-policy-configure-subscription-admin-hub spec: predicates: - requiredClusterSelector: labelSelector: matchExpressions: - {key: name, operator: In, values: ["local-cluster"]} tolerations: - key: cluster.open-cluster-management.io/unavailable operator: Exists - key: cluster.open-cluster-management.io/unreachable operator: ExistsTo apply the previous YAML from the command line interface, run the following command:
oc apply -f policy-configure-subscription-admin-hub.yaml- Install the Policy Generator kustomize plugin. Use Kustomize v4.5 or newer. See Generating a policy to install an Operator.
Policies are installed to the
policiesnamespace. You must bind that namespace to aClusterSet. For example, copy and apply the following example YAML to bind the namespace to the defaultClusterSet:apiVersion: cluster.open-cluster-management.io/v1beta2 kind: ManagedClusterSetBinding metadata: name: default namespace: policies spec: clusterSet: defaultRun the following command to apply the
ManagedClusterSetBindingresource from the command line interface:oc apply -f managed-cluster.yaml
After you meet the prerequisite requirements, you can apply the policy set.
4.16.8.2. Applying Red Hat OpenShift Platform Plus policy set
-
Use the
openshift-plus/policyGenerator.yamlfile that includes the prerequisite configuration for Red Hat OpenShift Plus. Apply the policies to your hub cluster by using the
kustomizecommand:kustomize build --enable-alpha-plugins | oc apply -f -Note: For any components of OpenShift Platform Plus that you do not want to install, edit the
policyGenerator.yamlfile and remove or comment out the policies for those components.
4.16.8.3. Additional resources
- See Red Hat OpenShift Platform Plus policy set for an overview of the policy set.
- Return to the beginning of the topic, Installing Red Hat OpenShift Platform Plus by using a policy set
4.16.9. Installing an operator by using the OperatorPolicy resource
To install Operator Lifecycle Manager (OLM) managed operators on your managed clusters, use an OperatorPolicy policy template in a Policy definition.
4.16.9.1. Creating an OperatorPolicy resource to install Quay
See the following operator policy sample that installs the latest Quay operator in the stable channel using the Red Hat operator catalog:
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name: install-quay
namespace: open-cluster-management-global-set
spec:
disabled: false
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1beta1
kind: OperatorPolicy
metadata:
name: install-quay
spec:
remediationAction: enforce
severity: critical
complianceType: musthave
upgradeApproval: None
subscription:
channel: <stable-version>
name: quay-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
After you add the OperatorPolicy policy template, the operatorGroup and subscription objects are created on the cluster by using the controller. As a result, the rest of the installation is completed by OLM. You can view the health of owned resources in the .status.Conditions and .status.relatedObjects fields of the OperatorPolicy resource on your managed cluster.
To verify the operator policy status, run the following command on your managed cluster:
oc -n <managed cluster namespace> get operatorpolicy install-quay
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}