Container Cluster Protection Overview

What Is Container Cluster Protection?

In a Kubernetes cluster, you can use Open Policy agent (OPA) or native Kubernetes policies to manage the security of cluster resource creation or update. However, these security policy tools require users to manually write policy code, deploy plug-ins, and troubleshoot faults; and their O&M operations are complex.

To address this issue, HSS has integrated OPA capabilities to provide container cluster protection based on native Kubernetes policies. Container cluster protection provides GUI for policy configuration, automatically deploys protection plug-ins, and checks cluster resources before they are created or modified to identify and block security risks (such as vulnerabilities and malicious files) and resources with unsafe settings, enhancing cluster security. You can flexibly configure container cluster protection policies to harden your clusters and prevent unsafe resources from deployment.

Container Cluster Protection Principles

In a Kubernetes cluster, HSS deploys the Gatekeeper and cgs-provider plug-ins to check the compliance of cluster resources (including Pods, Deployments, ReplicaSets, CronJobs, and Services) to be created or updated based on the policies you configured. Once a resource with non-compliant settings is detected, it will be automatically blocked. In this way, HSS implements fine-grained access control and risk prevention to improve cluster security and compliance.

Figure 1 How a container cluster is protected

• Protection policy: A container cluster protection policy configured on the HSS console is sent to the cluster to generate a custom resource (CR), which defines the rules for checking cluster resources.
• Gatekeeper: It consists of the gatekeeper-controller-manager and gatekeeper-audit components. It is deployed in a cluster as a Deployment to monitor the creation and modification of Kubernetes cluster resources and check whether they comply with protection policies. If they do not comply with the policies, the Gatekeeper prevents their execution.
• cgs-provider: It is deployed in a cluster as a Deployment to obtain image scan results (detected vulnerabilities, baselines, and malicious files) from the HSS cloud protection center and to send the results to the Gatekeeper as a reference for image blocking.

Container Cluster Protection Scenarios

• Container image blocking

  The container image scan function of HSS can comprehensively check container images to identify risks. However, it cannot prevent images (repository images and local images) with vulnerabilities from being created or used. To further secure the production environment, you can use the image blocking policy of the container cluster protection function to block risks before images are started or deployed.

• Resource admission control

  Admission control should be implemented on cluster resource creation and update requests. In this way, only the resources compliant with security policies, resource restrictions, and other compliance requirements can be started, and unsafe resources cannot enter the cluster.

Constraints

• Container cluster protection is available only in the HSS container edition. For details about how to purchase HSS, see Purchasing an HSS Quota.
• Container cluster protection applies only to container clusters where nodes run on the x86 architecture and the cluster version is 1.20 or later.
• In a CCE cluster, to operate and protect resource objects, you need to obtain either of the following operation permissions:
  • IAM permissions: Tenant Administrator or CCE Administrator.
  • Namespace permissions (authorized by Kubernetes RBAC): O&M permissions. For details about how to configure permissions, see Configuring namespace permissions.

Process of Using Container Cluster Protection

Figure 2 Usage process