Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 5. Gatekeeper operator overview
The Gatekeeper operator installs Gatekeeper, which is a validating webhook with auditing capabilities. Install the Gatekeeper operator on a Red Hat OpenShift Container Platform cluster from the Operator Lifecycle Manager operator catalog. With Red Hat Advanced Cluster Management for Kubernetes, you can install Gatekeeper on your hub cluster by using the Gatekeeper operator policy. After you install Gatekeeper, use it for the following benefits:
-
Deploy and check Gatekeeper
ConstraintTemplatesand constraints on managed clusters by using the Red Hat Advanced Cluster Management policy integration. - Enforce Kubernetes custom resource definition-based policies that run with your Open Policy Agent (OPA).
- Evaluate Kubernetes resource compliance requests for the Kubernetes API by using the Gatekeeper constraints.
- Use OPA as the policy engine and use Rego as the policy language.
To learn more about using the Gatekeeper operator, see the following resources:
5.1. General support Link kopierenLink in die Zwischenablage kopiert!
Red Hat supports only the Gatekeeper Operator and does not support individual Gatekeeper policies. Support ensures that the operator is functioning. To receive support, you need a Red Hat Advanced Cluster Management for Kubernetes or Red Hat OpenShift Container Platform Plus subscription.
To understand the support you receive from the Gatekeeper operator, see the following list:
- Supports current version of the Gatekeeper operator, preceding versions, and all z-stream releases of those versions.
- Receive maintenance support and relevant security vulnerability fixes for preceding and current versions.
- Support for all Red Hat OpenShift Container Platform versions that receive standard support. Note: The Gatekeeper operator is not supported on end-of-life OpenShift Container Platform versions or versions that receive extended support.
To view the release notes for the Gatekeeper operator, see gatekeeper-operator-bundle.
5.2. Operator channels Link kopierenLink in die Zwischenablage kopiert!
With the Gatekeeper operator, you have access to two types of channels to help you make upgrades. These channels are the stable channel and the y-stream version channel.
With the stable channel, you can access the latest available version, whether it is an x-stream, y-stream, or z-stream. The stable channel includes the latest version of the latest y-stream channel.
With the y-stream version channel, you can access all the z-stream versions for a particular y-stream.
5.3. Configuring the Gatekeeper operator Link kopierenLink in die Zwischenablage kopiert!
Install the Gatekeeper operator from the Operator Lifecycle Manager catalog to install Gatekeeper on your cluster. With Red Hat Advanced Cluster Management you can use a policy to install the Gatekeeper operator by using the governance framework. After you install the Gatekeeper operator, configure the Gatekeeper operator custom resource to install Gatekeeper.
Required access: Cluster administrator
Prerequisites
- You need a Red Hat Advanced Cluster Management for Kubernetes or Red Hat OpenShift Container Platform Plus subscription to install Gatekeeper and apply Gatekeeper policies to your cluster.
- Understand how to use the Operator Lifecycle Manager and the Red Hat OpenShift Software Catalog by completing the Adding Operators to a cluster and the Additional resources section in the OpenShift Container Platform documentation.
Procedure
The Gatekeeper operator custom resource is a cluster-scoped resource and must be named gatekeeper. Both the validating and mutating webhooks are enabled by default. Use the validatingWebhook and mutatingWebhook parameters to enable or disable the webhooks. Complete the following steps to configure the Gatekeeper operator custom resource:
Enable the
validatingWebhookandmutatingWebhookparameters. Your YAML file might resemble the following example:apiVersion: operator.gatekeeper.sh/v1alpha1 kind: Gatekeeper metadata: name: gatekeeper spec: validatingWebhook: Enabled mutatingWebhook: EnabledEnable the
auditEventsInvolvedNamespaceparameter to manage the namespace audit event you want to create. When you enable this parameter, the Gatekeeper controller deployment runs with the following argument:--audit-events-involved-namespace=true. See the following example:... spec: audit: auditEventsInvolvedNamespace: EnabledSpecify
containerArgumentsin theauditandwebhookspecification by providing a list of argument names and values to pass to the container. Omit leading dashes from the argument name. An omitted value is treated astrue. Arguments that you provide are ignored if the argument is set previously by the operator or configurations from other fields. See the following list of flags that are deny-listed and are not currently supported:-
port -
prometheus-port -
health-addr -
validating-webhook-configuration-name -
mutating-webhook-configuration-name -
disable-cert-rotation -
client-cert-name tls-min-versionView the following partial YAML file example:
... spec: webhook: containerArguments: - name: exempt-namespace-prefix value: sample-test--
For Gatekeeper version 3.20 and later, specify
audit.podAnnotationsthat are specific to the audit pod by providing a list of annotation names and values to add to the pod. View the following example:... spec: audit: podAnnotations: foo: barEnable the
admissionEventsInvolvedNamespaceparameter to manage the namespace admission event you want to create. When you enable this parameter, the Gatekeeper controller deployment runs with the following argument:--admission-events-involved-namespace=true. See the following example:... spec: webhook: admissionEventsInvolvedNamespace: EnabledOptional: If you want to enforce your Gatekeeper constraints, set the
failurePolicyparameter toFail. By default, thefailurePolicyparameter for Gatekeeper is set toIgnore. If the Gatekeeper webhook becomes unavailable, constraints are not enforced.... spec: webhook: failurePolicy: FailDefine
operationsfor your webhook. Use one or more of the following supported values:CREATE,UPDATE,CONNECT, andDELETE. By default, the operations areCREATEandUPDATE. See the following example:... spec: webhook: operations: - CREATE - UPDATE - CONNECTFor version 3.20 and later, specify
rulesto overwrite therulesin thewebhookandmutatingWebhookConfigspecifications. Therulesparameter supersedes theoperationsfield. See the following example:... spec: webhook: rules: - apiGroups: - "" apiVersions: - v1 operations: - CREATE - UPDATE resources: - Pods - DeploymentsFor version 3.20 and later, specify a custom timeout for the webhook configuration by defining a value for the
timeoutSecondsparameter.... spec: webhook: timeoutSeconds: 10For version 3.20 and later, configure the mutating webhook by adding configurations for the
mutatingWebhookConfigspecification. The configurations override the values fromspec.webhookor are specific to the mutating webhook. See the following example:... spec: mutatingWebhookConfig: failurePolicy: Ignore logMutations: Disabled mutationAnnotations: Disabled namespaceSelector: {} operations: [] rules: [] timeoutSeconds: 1Use the
configsection to exclude namespaces from certain processes for all constraints on your cluster using the GatekeeperConfigcustom resource. See the following example:... spec: config: matches: - excludedNamespaces: ["test-*", "my-namespace"] processes: ["*"]The
disableDefaultMatchesparameter is a boolean parameter that disables appending the default exempt namespaces provided by the Gatekeeper operator. The default exempt namespaces are OpenShift Container Platform or Kubernetes system namespaces. By default, this parameter is set tofalseto allow the default namespaces to be appended. See the following example:... spec: config: disableDefaultMatches: falseSee the following sample YAML file:
apiVersion: operator.gatekeeper.sh/v1alpha1 kind: Gatekeeper metadata: name: gatekeeper spec: audit: auditChunkSize: 66 auditEventsInvolvedNamespace: Enabled auditFromCache: Enabled auditInterval: 10s constraintViolationLimit: 55 containerArguments: - name: "" value: "" resources: limits: cpu: 500m memory: 150Mi requests: cpu: 500m memory: 130Mi emitAuditEvents: Enabled logLevel: DEBUG podAnnotations: {} replicas: 1 validatingWebhook: Enabled mutatingWebhook: Enabled webhook: admissionEventsInvolvedNamespace: Enabled containerArguments: - name: "" value: "" disabledBuiltins: - http.send emitAdmissionEvents: Enabled failurePolicy: Fail operations: - CREATE - UPDATE - CONNECT replicas: 3 resources: limits: cpu: 480m memory: 140Mi requests: cpu: 400m memory: 120Mi rules: - operations: [] resources: [] timeoutSeconds: 3 mutatingWebhookConfig: failurePolicy: "" logMutations: Disabled mutationAnnotations: Disabled namespaceSelector: {} operations: [] rules: - operations: [] resources: [] timeoutSeconds: 1 config: matches: - excludedNamespaces: ["test-*", "my-namespace"] processes: ["*"] disableDefaultMatches: false nodeSelector: region: "EMEA" affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: auditKey: "auditValue" topologyKey: topology.kubernetes.io/zone tolerations: - key: "Example" operator: "Exists" effect: "NoSchedule" podAnnotations: some-annotation: "this is a test" other-annotation: "another test"
5.3.1. Configuring auditFromCache for sync details Link kopierenLink in die Zwischenablage kopiert!
The Gatekeeper operator exposes a setting in the Gatekeeper operator custom resource for the audit configuration with the auditFromCache parameter, which is disabled by default. Configure the auditFromCache parameter to collect resources from constraints.
When you set the auditFromCache parameter to Automatic, the Gatekeeper operator collects resources from constraints and inserts those resources into your Gatekeeper Config resource. If the resource does not exist, the Gatekeeper operator creates the Config resource.
To configure the auditFromCache parameter for resource collection from constraints, complete the following steps:
Set
auditFromCachetoAutomaticin theGatekeeperresource. See the following example:apiVersion: operator.gatekeeper.sh/v1alpha1 kind: Gatekeeper metadata: name: gatekeeper spec: audit: replicas: 2 logLevel: DEBUG auditFromCache: AutomaticNote: If you set the
auditFromCacheparameter toEnabled, you need to manually set the GatekeeperConfigresource with the objects to sync to the cache. For more information, see Configuring Audit in the Gatekeeper documentation.To verify that the resources are added to your
Configresource, view that thesyncOnlyparameter section is added. Run the following command:oc get configs.config.gatekeeper.sh config -n openshift-gatekeeper-systemYour
Configresource might resemble the following example:apiVersion: config.gatekeeper.sh/v1alpha1 kind: Config metadata: name: config namespace: "openshift-gatekeeper-system" spec: sync: syncOnly: - group: "" version: "v1" kind: "Namespace" - group: "" version: "v1" kind: "Pod"Optional: You can view the explanation of the
auditFromCachesetting from the description of the Gatekeeper operator custom resource by running the following command:oc explain gatekeeper.spec.audit.auditFromCache
Additional resources
- For more information, see Configuring Audit in the Gatekeeper documentation.
- For more information about configuring fail-open and fail-closed behavior, see Gatekeeper documentation.
-
For a list of arguments to use for the
containerArgumentsparameter, see Runtime Flags in the Gatekeeper documentation. -
To read explanations about the difference betewwen the
Configresource and the flags for exempting namespaces, see Exempting Namespaces in the Gatekeeper documentation.
5.4. Managing the Gatekeeper operator installation policies Link kopierenLink in die Zwischenablage kopiert!
Use the Red Hat Advanced Cluster Management policy to install the Gatekeeper operator and Gatekeeper on a managed cluster.
Required access: Cluster administrator
To create, view, and update your Gatekeeper operator installation policies, complete the following sections:
- Installing Gatekeeper using a Gatekeeper operator policy
- Creating a Gatekeeper policy from the console
- Upgrading Gatekeeper and the Gatekeeper operator
- Disabling Gatekeeper operator policy
- Deleting Gatekeeper operator policy
- Uninstalling Gatekeeper constraints, Gatekeeper instance, and Gatekeeper operator policy
5.4.1. Installing Gatekeeper using a Gatekeeper operator policy Link kopierenLink in die Zwischenablage kopiert!
To install the Gatekeeper operator policy, use the configuration policy controller. During the install, the operator group and subscription pull the Gatekeeper operator to install it on your managed cluster. Then, the policy creates a Gatekeeper custom resource to configure Gatekeeper.
The Red Hat Advanced Cluster Management configuration policy controller checks the Gatekeeper operator policy and supports the enforce remediation action. When you set the controller to enforce it automatically creates the Gatekeeper operator objects on the managed cluster.
5.4.2. Creating a Gatekeeper policy from the console Link kopierenLink in die Zwischenablage kopiert!
When you create a Gatekeeper policy from the console, you must set your remediation enforce to install Gatekeeper.
5.4.2.1. Viewing the Gatekeeper operator policy Link kopierenLink in die Zwischenablage kopiert!
To view your Gatekeeper operator policy and its status from the console, complete the following steps:
-
Select the
policy-gatekeeper-operatorpolicy to view more details. - Select the Clusters tab to view the policy violations.
5.4.3. Upgrading Gatekeeper and the Gatekeeper operator Link kopierenLink in die Zwischenablage kopiert!
You can upgrade the versions for Gatekeeper and the Gatekeeper operator. When you install the Gatekeeper operator with the Gatekeeper operator policy, notice the value for upgradeApproval. The operator upgrades automatically when you set upgradeApproval to Automatic.
If you set upgradeApproval to Manual, you must manually approve the upgrade for each cluster where the Gatekeeper operator is installed.
5.4.4. Disabling Gatekeeper operator policy Link kopierenLink in die Zwischenablage kopiert!
To disable your policy-gatekeeper-operator policy, select the Disable option from the Actions menu in the console, or set spec.disabled: true from the CLI.
5.4.5. Deleting Gatekeeper operator policy Link kopierenLink in die Zwischenablage kopiert!
To delete your Gatekeeper operator policy from your CLI, complete the following steps:
Delete Gatekeeper operator policy by running the following command:
oc delete policies.policy.open-cluster-management.io <policy-gatekeeper-operator-name> -n <namespace>Verify that you deleted your policy by running the following command:
oc get policies.policy.open-cluster-management.io <policy-gatekeeper-operator-name> -n <namespace>
To delete your Gatekeeper operator policy from the console, click the Actions icon for the policy-gatekeeper-operator policy and select Delete.
5.4.6. Uninstalling Gatekeeper constraints, Gatekeeper instance, and Gatekeeper operator policy Link kopierenLink in die Zwischenablage kopiert!
To uninstall Gatekeeper policy, complete the steps in the following sections:
5.4.6.1. Removing Gatekeeper constraints Link kopierenLink in die Zwischenablage kopiert!
To remove the Gatekeeper constraint and ConstraintTemplate from your managed cluster, complete the following steps:
-
Edit your Gatekeeper constraint or
ConstraintTemplatepolicy. -
Locate the template that you used to create the Gatekeeper
ConstraintandConstraintTemplate. - Delete the entries from the list of templates. (Or delete the policy if they’re the only templates.)
- Save and apply the policy.
Note: The constraint and ConstraintTemplate are provided directly in the policy-templates instead of within a ConfigurationPolicy.
5.4.6.2. Removing Gatekeeper instance Link kopierenLink in die Zwischenablage kopiert!
To remove the Gatekeeper instance from your managed cluster, complete the following steps:
- Edit your Gatekeeper operator policy.
-
Locate the
ConfigurationPolicytemplate that you used to create the Gatekeeper operator custom resource. -
Change the value for
complianceTypeof theConfigurationPolicytemplate tomustnothave. Changing the value deletes the Gatekeeper operator custom resource, signaling to the Gatekeeper operator to clean up the Gatekeeper deployment.
5.4.6.3. Removing Gatekeeper operator Link kopierenLink in die Zwischenablage kopiert!
To remove the Gatekeeper operator from your managed cluster, complete the following steps:
- Edit your Gatekeeper operator policy.
-
Locate the
OperatorPolicytemplate that you used to create the Subscription CR. -
Change the value for
complianceTypeof theOperatorPolicytemplate tomustnothave.
5.4.7. Additional resources Link kopierenLink in die Zwischenablage kopiert!
For more details, see the following resources:
- Integrating Gatekeeper constraints and constraint templates.
- Policy Gatekeeper.
- For an explanation of the optional parameters that can be used for the Gatekeeper operator policy, see Gatekeeper Helm Chart.
5.5. Integrating Gatekeeper constraints and constraint templates Link kopierenLink in die Zwischenablage kopiert!
Integrate Gatekeeper constraints and constraint templates to create Gatekeeper policies for multicluster distribution of Gatekeeper constraints and audit results. Add templates and constraints to the policy-templates of a Policy resource.
View the following YAML examples that use Gatekeeper constraints in Red Hat Advanced Cluster Management policies:
ConstraintTemplatesand constraints: Use the Gatekeeper integration feature by using Red Hat Advanced Cluster Management policies for multicluster distribution of Gatekeeper constraints and Gatekeeper audit results aggregation on the hub cluster. The following example defines a GatekeeperConstraintTemplateand constraint (K8sRequiredLabels) to ensure thegatekeeperlabel is set on all namespaces:apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: require-gatekeeper-labels-on-ns spec: remediationAction: inform1 disabled: false policy-templates: - objectDefinition: apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8srequiredlabels annotations: policy.open-cluster-management.io/severity: low2 spec: crd: spec: names: kind: K8sRequiredLabels validation: openAPIV3Schema: properties: labels: type: array items: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8srequiredlabels violation[{"msg": msg, "details": {"missing_labels": missing}}] { provided := {label | input.review.object.metadata.labels[label]} required := {label | label := input.parameters.labels[_]} missing := required - provided count(missing) > 0 msg := sprintf("you must provide labels: %v", [missing]) } - objectDefinition: apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: ns-must-have-gk annotations: policy.open-cluster-management.io/severity: low3 spec: enforcementAction: dryrun match: kinds: - apiGroups: [""] kinds: ["Namespace"] parameters: labels: ["gatekeeper"]- 1
- Since the
remediationActionis set toinform, theenforcementActionfield of the Gatekeeper constraint is overridden towarn. This means that Gatekeeper detects and warns you about creating or updating a namespace that is missing thegatekeeperlabel. If the policyremediationActionis set toenforce, the Gatekeeper constraintenforcementActionfield is overridden todeny. In this context, this configuration prevents any user from creating or updating a namespace that is missing thegatekeeperlabel. - 2 3
- Optional: Set a severity value for the
policy.open-cluster-management.io/severityannotation for each Gatekeeper constraint or constraint template. Valid values are the same as for other Red Hat Advanced Cluster Management policy types:low,medium,high, orcritical.
With the previous policy, you might receive the following policy status message:
warn - you must provide labels: {"gatekeeper"} (on Namespace default); warn - you must provide labels: {"gatekeeper"} (on Namespace gatekeeper-system). When you delete Gatekeeper constraints orConstraintTemplatesfrom a policy, the constraints andConstraintTemplatesare also deleted from your managed cluster.To view the Gatekeeper audit results for a specific managed cluster from the console, go to to the policy template Results page. If search is enabled, view the YAML of the Kubernetes objects that failed the audit.
Notes:
- The Related resources section is only available when Gatekeeper generates audit results.
- The Gatekeeper audit runs every minute by default. Audit results are sent back to the hub cluster to be viewed in the Red Hat Advanced Cluster Management policy status of the managed cluster.
policy-gatekeeper-admission: Use thepolicy-gatekeeper-admissionconfiguration policy within a Red Hat Advanced Cluster Management policy to check for Kubernetes API requests denied by the Gatekeeper admission webhook. View the following example:apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: policy-gatekeeper-admission spec: remediationAction: inform1 severity: low object-templates: - complianceType: mustnothave objectDefinition: apiVersion: v1 kind: Event metadata: namespace: openshift-gatekeeper-system2 annotations: constraint_action: deny constraint_kind: K8sRequiredLabels constraint_name: ns-must-have-gk event_type: violation
5.5.1. Additional resources Link kopierenLink in die Zwischenablage kopiert!
For more details, see the following resources: