Feature Introduction
Cluster Security Enhancement is a cluster-level security hardening capability provided by TKE for high-security-demand scenarios such as enterprise-grade AI Agents. After it is enabled, TKE automatically deploys and continuously maintains a set of security policies within the specified scope. These policies cover three types of mechanisms: MetaServer blocking, admission control, and network isolation. This achieves "one-click enablement and full lifecycle management", eliminating the need for users to manually configure and maintain various security components.
Core Capability
Automatic Deployment: When automatic deployment is enabled, all policies are deployed in full at once. Newly created Namespaces are automatically supplemented.
Continuous Reconciliation: The built-in Controller continuously performs detection, and policies that are accidentally deleted are automatically repaired.
Canary Support: It controls the effective scope through Namespace or Pod Label and supports progressive validation.
Clean Reclamation: When security enhancement is disabled, all related policies are automatically reclaimed, leaving no residue.
Use Limits
Security enhancement policies take effect on all newly created Pods within the specified scope. Pods that violate the policies are denied creation.
The following system namespaces are exempt by default and are not constrained by policies: kube-system, kube-public, kube-node-lease, gatekeeper-system, tke-backup, crane-system.
Security enhancement requires that the Gatekeeper component be installed on the cluster.
Policy Description
After you enable security enhancement, TKE automatically deploys the following policies:
Gatekeeper Assign (Mutation Injection)
|
MetaServer Blocking | addinitcontainer | Automatically injects a security-defense initContainer into each Pod, blocks the Tencent Cloud MetaServer address via iptables before the Pod starts, and prevents containers from obtaining node cloud credentials. |
Gatekeeper Constraint (Admission Blocking)
|
Block Dangerous Host Path Mounts | blockvolumemountpath | Prevents pods from mounting the host root directory and prefix paths such as /opt via HostPath, to block containers from accessing sensitive node files. |
Block Dangerous Volume Types | blockmountablevolumetype | Prohibits pods from using gitRepo type volumes, to prevent containers from automatically pulling and executing code from external Git repositories at startup. |
Block Privileged Containers | k8spspprivilegedcontainer | Prevents containers from running with privileged: true, to block container escape to the host. |
Block Automatic SA Token Mounting | k8spspautomountserviceaccounttokenpod | Prevents containers from automatically mounting ServiceAccount Tokens, to block containers from directly obtaining Kubernetes API access permissions. |
Note:
All Constraints are configured with enforcementAction: deny. Violations result in Pod creation being denied. All resources deployed by security enhancement carry the Tag app.kubernetes.io/managed-by: tke-security-mode, which is used for identification and management.
NetworkPolicy (Network Isolation)
|
security-mode-block-container-subnet | Egress | Blocks pods from directly connecting to the container subnet to prevent lateral movement between pods via direct IP address communication. Allows normal public network traffic and DNS (UDP/TCP 53). |
Egress Rules for Each Network Mode:
|
Block container subnet | 0.0.0.0/0 except ENI subnet CIDR | 0.0.0.0/0 except ClusterCIDR |
Allow Service CIDR | No separate allow rule is required (ServiceCIDR and the container subnet do not overlap by design). | Exclusively allow ServiceCIDR to ensure Pod-to-ClusterIP communication works properly. |
Allow DNS | UDP/TCP 53 | UDP/TCP 53 |
Operation Steps
Enabling Security Enhancement
Enabling During Cluster Creation
When you create a cluster in the TKE console, enable cluster security enhancement in Advanced Settings. Enabling for an Existing Cluster
For existing clusters, you can go to the cluster Basic Information page to enable security enhancement. We recommend that you first verify compatibility in a canary manner before it is enabled fully. The canary mode supports canary deployment in two dimensions: Namespace or Pod Label.
Canary by Namespace: It takes effect only on Pods within the specified namespace.
Canary by Pod Label: It takes effect only on Pods that carry the specified Label. Pods without the Label in the same Namespace are not affected.
Disabling Security Enhancement
After you disable it, TKE automatically and completely reclaims all OPA policies and NetworkPolicies deployed by security enhancement. No manual cleanup is required.
FAQs
Why Do Some Pods Fail to Be Created After Security Enhancement Is Enabled?
The security enhancement policy blocks the following common configurations. Before it is enabled, we recommend that you check them in advance. You can view the specific denial reason by running kubectl describe pod <pod-name>, or locate the triggered policy by querying the Gatekeeper audit logs.
Pods that use HostPath to mount host paths (for example, log collection DaemonSets).
Privileged containers that use privileged: true (for example, some middleware).
Pods for which automountServiceAccountToken: false is not explicitly set.
Pods that use gitRepo-type Volumes.
Will System Components Be Affected?
System namespaces such as kube-system are exempt by default and are not constrained by policies. For special components in business namespaces that require exemption, you can exclude the corresponding namespace by narrowing the scope of SecurityModeNamespaces.
Will NetworkPolicy Affect Normal Service Access?
No. NetworkPolicy only blocks direct access between Pods via container IPs. Traffic from Pods accessing other services through ClusterIP Services is not affected. In VPC-CNI mode, the ServiceCIDR and the container subnet do not overlap by nature. In GlobalRouter mode, the ServiceCIDR is already allowed separately. DNS resolution (UDP/TCP 53) is also included in the allow rules.