To meet cluster compliance requirements and enhance security, enable the policy governance feature. This feature provides a library of security policies for Kubernetes container applications that cover categories such as Infra (infrastructure-layer resources), Compliance (Kubernetes compliance standards), PSP (extensions of PodSecurityPolicy capabilities), and K8s-general (general policies). You can enable or customize security policies for your container applications in the ACK console to verify that Pod deployments and updates are secure and controlled.
Policy governance
As of Kubernetes v1.21, PodSecurityPolicy (PSP) is deprecated. In response, ACK has upgraded its original PSP-based policy management feature. Built on the Gatekeeper admission controller that uses Open Policy Agent (OPA) policies, ACK enhances the feature with capabilities such as policy governance status statistics, log reporting, and log search. ACK also includes a rich policy library with rules tailored for a wide range of Kubernetes application scenarios. You can configure these policies through a user-friendly interface in the ACK console, simplifying the use of policy governance.
Prerequisites
-
The cluster runs Kubernetes 1.16 or later. To upgrade your cluster, see Manually upgrade an ACK cluster.
-
If you use a RAM user to manage policies, ensure the RAM user has the following permissions:
-
cs:DescribePolicies: lists the policies in the policy library. -
cs:DescribePolicyDetails: obtains the details of a policy template. -
cs:DescribePolicyGovernanceInCluster: obtains the policy governance details of a cluster. -
cs:DescribePolicyInstances: lists the policy instances deployed in a cluster. -
cs:DescribePolicyInstancesStatus: obtains the deployment status of policy instances for different policy types in a cluster. -
cs:DeployPolicyInstance: deploys a policy instance in a specified cluster. -
cs:DeletePolicyInstance: deletes a policy instance in a specified cluster. -
cs:ModifyPolicyInstance: modifies a policy instance in a specified cluster.
For more information about how to create a custom RAM policy, see Grant access permissions on clusters and cloud resources by using RAM.
-
Policy governance components
ACK offers two types of policy governance components: a managed version and an unmanaged version. Only one type can be enabled in a cluster at a time. The following table compares the two versions.
|
Item |
Managed version |
Unmanaged version |
|
Deployment mode |
Control plane deployment: ACK deploys and fully manages the components on the cluster control plane. |
Data plane deployment: The components deploy as a workload in your cluster and are installed by default in the kube-system namespace, consuming Pod resources on worker nodes. |
|
Applicable clusters |
Auto Mode clusters of v1.30 or later |
ACK managed clusters and ACK dedicated clusters of v1.16 or later |
|
Startup parameter configuration |
The system configures the component startup parameters, which cannot be customized. |
You can customize the startup parameters of the components. |
|
Core component installation |
In the ACK console, on the Add-ons page, the component card for the managed version is marked with a Managed icon |
|
|
Policy log collection |
Collects logs by using the Collect logs of control plane components in an ACK managed cluster feature and sends them to a specified Log Service project. |
Installs a log collection component in the cluster to collect and send logs to a specified Log Service project. |
|
Policy library |
All policies in Predefined security policies for ACK |
|
Notes
-
This feature applies only to Linux nodes.
-
This feature does not support custom policies. All rules must come from the built-in ACK policy library.
Step 1: Install or upgrade policy governance
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click .
-
On the Policy page, follow the on-screen instructions to install or upgrade the components.
When you enable the policy governance feature, you must install the following components. These components are free of charge, but they will consume your Pod resources.
-
gatekeeper: a Kubernetes policy admission controller based on the OPA policy engine. It helps you manage and apply OPA policies in your cluster and implement features like namespace label management.
NoteYou must use the gatekeeper component provided by ACK. If you installed a gatekeeper component from another source, uninstall it and then reinstall the ACK-provided version. For more information about the release notes of the gatekeeper component, see gatekeeper.
-
log collection component: collects and retrieves events for requests denied or flagged by policy constraints.
-
policy-template-controller: a Kubernetes controller developed based on Alibaba Cloud policy templates. It helps you better manage policy instances deployed from different policy templates and the overall governance status of the cluster.
-
Step 2: Use policy governance
Entry point
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click .
-
On the Policy page, follow the on-screen instructions to install or upgrade components if prompted, and then perform operations as required.
View policy enforcement status
Click the Overview tab to view the current policy governance status of your cluster.
-
The policy overview section displays the total number of high-risk and medium-risk protection policies, the number of enabled policies, and a list of recommended policies to enable.
-
Statistics on denied requests and alerts over the last 7 days.
-
The policy enforcement records within the last 7 days are displayed. The table displays the 100 most recent logs of denied requests or alerts from the last 7 days by default. To view more audit logs, click the
icon next to Actions within Last 7 Days and click the Log Service link in the pop-up window to view all logs in the specified Logstore of the Log Service console. The Policy Enforcement Records for Last 7 Days table at the bottom of the page shows the Enforcement Time, Policy Type, Policy Name, Policy Description, Risk Level, Action, and Details for each policy. You can use the search box and filter buttons to locate specific records.
Create and manage policy instances
Click the My Policies tab, and then click Create Policy Instance. In the Create Policy Instance dialog box, configure the parameters.
|
Parameter |
Description |
|
Policy Type |
Select a policy type. Valid values:
For more information, see Predefined security policies for ACK. |
|
Policy Name |
Based on the selected policy type, select the name of the policy template that you want to deploy from the drop-down list. |
|
Action |
|
|
Scope |
Select the namespaces in the cluster to which the policy instance applies. |
|
Parameters |
|
View policies and instances
Click the My Policies tab to view all deployable policies in the cluster.
-
You can filter the displayed policies in the upper-right corner of the list. Enabled policies are displayed first. The Instances column shows the number of instances deployed for the corresponding policy in the cluster.
If the value in the Instances column is empty, the policy has not been deployed in the cluster. You can click Enabled in the Actions column to configure parameters and deploy the policy instance.
-
Click Edit in the Actions column to modify the configuration of a policy instance.
If a policy has multiple instances, click View Instances in the Actions column, and then click Edit on the desired instance to modify it.
-
Click Delete in the Actions column to delete all instances of the policy deployed in the cluster.
For more information about policy descriptions and template examples, see Predefined security policies for ACK.
Related operations
Enable deletion protection
After you enable the policy governance feature as described in Step 1: Install or upgrade policy governance, you can also enable deletion protection for namespaces or Services that involve critical business or sensitive data to prevent accidental deletion. When deletion protection is enabled, you must manually disable it before you can delete the corresponding resources.
This section shows how to enable deletion protection for an existing namespace. The process is similar for other resources.
-
Enable deletion protection for an existing namespace
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click Namespaces and Quotas.
-
In the list of namespaces, find the namespace that you want to manage, click Edit in the Actions column, and then follow the on-screen instructions in the dialog box to enable deletion protection.
-
Enable deletion protection for an existing Service
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click .
-
In the list of Services, find the Service that you want to manage, click
in the Actions column, click Enable Deletion Protection, and then follow the on-screen instructions in the dialog box to enable deletion protection.
Cross-resource validation with ack-policy-external-provider
By default, Gatekeeper makes policy decisions based only on the object under review. However, complex security scenarios often require a policy to check the state of other cluster resources for accurate enforcement.
The managed component ack-policy-external-provider acts as an external data source for Gatekeeper, allowing policy developers to query Kubernetes resources from within their Rego code. This capability is required for advanced policies such as the built-in CRD deletion protection policy.
The ack-policy-external-provider component must be used with gatekeeper. Make sure that gatekeeper is deployed in your cluster.
Install and configure ack-policy-external-provider
On the ACK Clusters page, click the name of your cluster. In the left navigation pane, click Add-ons.
-
Search for ack-policy-external-provider and follow the on-screen instructions to complete the configuration.
-
ProviderPodNumber: the number of component instances.
-
ProtectedKinds: Add the resource types corresponding to the CRDs that you want to protect.
CRD deletion protection requires checking whether instances of the resource type exist in the cluster. Following the principle of least privilege, ack-policy-external-provider does not have the required query permissions by default and must be manually configured.
Set ProviderPodNumber (number of replicas, default:
1). In the ProtectedKinds section, enter the resource type names (such aspods,policies, orcustomresources). Click Add to add multiple entries, or click Delete to remove an entry. Click OK.
-
API definition and parameters
ack-policy-external-provider implements a standard Gatekeeper external data Provider. In a Rego policy template, you can send a resource query request to this component by calling the external_data function and specifying provider: ack-policy-external-data-provider.
The request parameters are defined in JSON format. The following shows some examples.
// Example 1
{
"action": "ListK8sResource",
"namespaced": false,
"group": "",
"version": "v1",
"resource": "persistentvolumeclaims"
"requestID": review.uid,
"userInfo": review.userInfo,
"requestFrom": "PVCProtector",
"labelSelector": "protected",
"limit": 1
}
// Example 2
{
"action": "GetK8sResource",
"namespaced": true,
"namespace": "default",
"group": "apps",
"version": "v1",
"resource": "deployments",
"requestID": review.uid,
"userInfo": review.userInfo,
"requestFrom": "FinOpsPolicy",
"labelSelector": "protected",
"limit": 1
}
The following table describes the core parameters.
|
Parameter |
Description |
Required |
|
|
The operation type. Supported values are |
Yes |
|
|
The API group of the target resource. |
Yes |
|
|
The API version of the target resource. |
No |
|
|
The plural name of the target resource (such as |
Yes |
|
|
Whether the target resource is located within a namespace. For cluster-scoped resources, use
|
Yes |
|
|
When |
No |
|
|
When |
No |
|
|
Filters resources based on labels, following the Kubernetes label selector syntax. |
No |
|
|
The maximum number of resources returned by |
No |
|
|
The unique ID of the request. We recommend that you use |
No |
|
|
The information about the user who initiates the request. We recommend that you use |
No |
|
|
An identifier for the request source, typically the name of the policy template, used for log tracing. |
Yes |
Example: Prevent CRD deletion
This example shows how to use ack-policy-external-provider to implement a common advanced policy: prohibit the deletion of a CustomResourceDefinition (CRD) if associated custom resource (CR) instances still exist.
This policy is a built-in rule and does not require manual deployment. This section is for demonstration purposes only.
-
Policy logic
-
Query: Rego policies use
external_datato call ack-policy-external-provider. -
Check: Based on the request parameters, the ack-policy-external-provider component queries the cluster to check whether corresponding CR instances exist.
-
Decision: If the query result returns at least one CR instance, ack-policy-external-provider will return the result to the Rego policy, and the policy will ultimately
deny(reject) this deletion operation.
-
-
Policy template (ConstraintTemplate)
Defines the policy logic.
apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: blockcrddeletion annotations: meta.helm.sh/release-name: gatekeeper meta.helm.sh/release-namespace: kube-system metadata.gatekeeper.sh/version: 1.0.0 labels: app.kubernetes.io/managed-by: Helm spec: crd: spec: names: kind: BlockCrdDeletion validation: legacySchema: true targets: - target: admission.k8s.gatekeeper.sh rego: | package block_crd_deletion violation[{"msg": msg}] { before(input.review.operation) response := handle(input.review) msg := after(response) } before(operation) { operation == "DELETE" } handle(review) = response { customrequest := { "action": "ListK8sResource", "namespaced": false, "group": review.object.spec.group, "version": "", "resource": review.object.spec.names.plural, "requestID": review.uid, "userInfo": review.userInfo, "requestFrom": "BlockCrdDeletion", "labelSelector": "protected", "limit": 1 } request_keys := [json.marshal(customrequest)] response := external_data({ "provider": "ack-policy-external-data-provider", "keys": request_keys }) } after(response) = msg { count(response.responses[0]) > 0 msg := sprintf( "The CRD %v is not allowed to be deleted. Reason: It is not allowed to delete a CRD object when it contains a collection of custom resources. Current existing custom resources: %v, etc.", [input.review.name, response.responses[0][0]] ) } -
Policy instance (Constraint)
Applies the template to specific resources. This example applies the policy to all CRDs.
apiVersion: constraints.gatekeeper.sh/v1beta1 kind: BlockCrdDeletion metadata: name: block-crd-deletion-rule spec: enforcementAction: deny match: kinds: - apiGroups: - '*' kinds: - CustomResourceDefinition -
Verify the result
-
Create a test CRD and a corresponding CR instance.
# Create a CRD apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: simplestthings.example.com spec: group: example.com scope: Namespaced names: plural: simplestthings singular: simplestthing kind: SimplestThing versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: message: type: string --- # Create a CR instance apiVersion: example.com/v1 kind: SimplestThing metadata: name: my-simple-thing namespace: default labels: protected: "false" spec: message: "Hello" -
Attempt to delete the CRD.
kubectl delete crd simplestthings.example.com -
Verify that the policy blocks the deletion and returns a clear error message.
Expected output:
Error from server (Forbidden): admission webhook "delete.validation.gatekeeper.sh" denied the request: [block-crd-deletion-rule] The CRD simplestthings.example.com is not allowed to be deleted. Reason: It is not allowed to delete a CRD object when it contains a collection of custom resources. Current existing custom resources: my-simple-thing, etc.
-
Related topics
The inspection feature allows you to scan for security risks in workload configurations. For more information, see Configure inspection to check cluster workloads.