All Products
Search
Document Center

Security Center:Add a self-managed Kubernetes cluster to Security Center

Last Updated:Sep 09, 2026

Security Center supports connecting self-managed K8s (Kubernetes) clusters for centralized management and security risk detection. This topic describes how to connect a self-managed K8s cluster.

Version Limits

  • Subscription: Ultimate (If your current edition does not support this feature, upgrade).

    Note

    The protection edition of the server must be set to the edition you purchased. For more information, see Bind a server protection edition.

  • Pay-as-you-go: Host and Container Security pay-as-you-go is activated (If not activated, purchase).

    Note

    The server protection level must be set to Host and Container Security. For more information, see Bind a server protection level.

Restrictions

The region restrictions on onboarding are as follows:

  • If the network type of the self-managed K8s cluster is VPC, the cluster can be connected only in the China (Hangzhou), China (Beijing), China (Shanghai), China (Shenzhen), and China (Hong Kong) regions.

  • If the network type of the self-managed K8s cluster is public network, no region restrictions apply.

Prerequisites

  • A K8s cluster is set up on the server.

  • Docker is installed.

  • If you want to use the cluster exposure analysis feature, you must also complete the following network configurations based on your cluster deployment mode and access control policy configurations. For more information, see Analyze cluster exposure.

    • If your K8s cluster is deployed in a hybrid cloud and cannot be directly accessed over the public network, configure traffic forwarding rules to ensure network connectivity before you connect the cluster to Security Center.

      Configure traffic forwarding rules

      Specify an ECS instance and forward the access traffic of the ECS instance to the IDC server on which the API server of the third-party K8s cluster resides.

      For example, forward the traffic of port A on the ECS instance 10.0.XX.XX that performs the forwarding task to port B on the IDC server 192.168.XX.XX where the API server of the third-party K8s cluster resides.

      • CentOS 7 commands

        • Use firewall-cmd:

          firewall-cmd --permanent --add-forward-port=port=<Port A>:proto=tcp:toaddr=<192.168.XX.XX>:toport=<Port B>
        • Use iptables.

        • # Enable port forwarding
          echo "1" > /proc/sys/net/ipv4/ip_forward
          # Configure port forwarding
          iptables -t nat -A PREROUTING -p tcp --dport <Port A> -j DNAT --to-destination <192.168.XX.XX>:<Port B>
      • Windows commands

        netsh interface portproxy add v4tov4 listenport=<Port A> listenaddress=* connectaddress=<192.168.XX.XX> connectport=<Port B> protocol=tcp
    • If access control policies are configured for your cluster, make sure that the IP address pool of the region in which the containers reside is added to the whitelist of the access control policies.

      IP address pools that must be added to the whitelist

      Region

      Public IP address

      Private IP address

      China (Hangzhou)

      47.96.166.214

      100.104.12.64/26

      China (Shanghai)

      139.224.15.48, 101.132.180.26, 47.100.18.171, 47.100.0.176, 139.224.8.64, 101.132.70.106, 101.132.156.228, 106.15.36.12, 139.196.168.125, 47.101.178.223, 47.101.220.176

      100.104.43.0/26

      China (Qingdao)

      47.104.111.68

      100.104.87.192/26

      China (Beijing)

      47.95.202.245

      100.104.114.192/26

      China (Zhangjiakou)

      39.99.229.195

      100.104.187.64/26

      China (Hohhot)

      39.104.147.68

      100.104.36.0/26

      China (Shenzhen)

      120.78.64.225

      100.104.250.64/26

      China (Guangzhou)

      8.134.118.184

      100.104.111.0/26

      China (Hong Kong)

      8.218.59.176

      100.104.130.128/26

      Japan (Tokyo)

      47.74.24.20

      100.104.69.0/26

      Singapore

      8.219.240.137

      100.104.67.64/26

      US (Silicon Valley)

      47.254.39.224

      100.104.145.64/26

      US (Virginia)

      47.252.4.238

      100.104.36.0/26

      Germany (Frankfurt)

      47.254.158.71

      172.16.0.0/20

      UK (London)

      8.208.14.12

      172.16.0.0/20

      Indonesia (Jakarta)

      149.129.238.99

      100.104.193.128/26

Add a self-managed Kubernetes cluster to Security Center

  1. Log on to Security Center console.

  2. In the left-side navigation pane, choose Asset Center > Container. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

  3. On the Cluster tab, click Self-built cluster access.

  4. In the Self-built cluster management panel, click Self-built cluster access, configure the information about the self-managed K8s cluster that you want to connect, and then click Generate Command.

    Parameter

    Description

    Cluster name

    Enter the name of the self-managed K8s cluster. Example: text-001.

    Expiration Time

    Select the expiration time of the command used to connect the self-managed K8s cluster.

    Group

    Select the group of the cluster after the cluster is connected (that is, the group to which the server on which the cluster resides belongs).

    Service Provider

    Select the provider of the server on which the cluster resides.

  5. (Optional) In the Enable Log Collection section, specify whether to enable K8s log-based threat detection.

    After you enable K8s log-based threat detection, Security Center can obtain more audit logs to detect security risks in a more comprehensive manner. Before you enable threat detection, you must install Logtail components in the K8s cluster and complete the audit-related configurations. For more information, see Enable log-based threat detection.

  6. Log on to the server on which the cluster resides, create a file named text-001.yaml, copy the generated command to the file, and then run the kubectl apply -f text-001.yaml command to connect the cluster.

    By default, the command generated in Step 4 does not connect master nodes or tainted nodes. If you want to connect master nodes and tainted nodes, modify the configurations in the YAML file based on the following instructions.

    Instructions on connecting master and tainted nodes

    To connect master nodes or tainted nodes to Security Center as part of the cluster, you must configure tolerations in the pod template of the DaemonSet to allow pods to be scheduled on master nodes or tainted nodes.

    • For master nodes, under spec>template>spec in the YAML file, configure the following Toleration, which allows the pods of this DaemonSet to be scheduled on master nodes with the node-role.kubernetes.io/master:NoSchedule taint. This connects the master nodes to Security Center as part of the cluster.

      spec:
        template:
          spec:
            tolerations:
            - key: node-role.kubernetes.io/master
              operator: Exists
              effect: NoSchedule
    • For nodes to which taints are added, refer to the preceding Toleration configuration for master nodes to schedule the pods of the DaemonSet on the tainted nodes. This connects the tainted nodes to Security Center as part of the cluster.

    Note

    The text-001 in the preceding text-001.yaml file name and the kubectl apply -f text-001.yaml command is an example of Cluster name. When you perform the operations, replace text-001 with the actual Cluster name.

After you connect a self-managed K8s cluster, you can view the information about the connected clusters in the cluster list on the Cluster tab.

Enable log-based threat detection

If the version of the K8s cluster is 1.16 or later, you can enable K8s log-based threat detection to provide more comprehensive security risk detection for the self-managed cluster, such as detecting high-risk operations and attacks.

Step 1. Install Logtail

For more information, see Install Logtail components in a self-managed Kubernetes cluster, specifically the Install Logtail section.

Step 2. Enable cluster auditing

The following steps are for reference only. For more information, see Use cluster auditing.

  1. A registered cluster is created and the self-managed Kubernetes cluster is connected to the registered cluster. For more information, see Create an ACK One registered cluster.

  2. Configure the audit policy file on master nodes.

    Log on to a master node and edit /etc/kubernetes/audit-policy.yaml using the template below. Repeat this step on all other master nodes.

    Note

    The apiVersion value depends on your Kubernetes version:

    • Kubernetes earlier than 1.24: use audit.k8s.io/v1beta1

    • Kubernetes 1.24 and later: use audit.k8s.io/v1

    For details, see Kubernetes 1.24 release notes.

    apiVersion: audit.k8s.io/v1beta1  # Use audit.k8s.io/v1 for Kubernetes >= 1.24
    kind: Policy
    # Suppress events in the RequestReceived stage.
    omitStages:
      - "RequestReceived"
    rules:
      # High-volume, low-risk requests — not logged.
      - level: None
        users: ["system:kube-proxy"]
        verbs: ["watch"]
        resources:
          - group: "" # core
            resources: ["endpoints", "services"]
      - level: None
        users: ["system:unsecured"]
        namespaces: ["kube-system"]
        verbs: ["get"]
        resources:
          - group: "" # core
            resources: ["configmaps"]
      - level: None
        users: ["kubelet"] # legacy kubelet identity
        verbs: ["get"]
        resources:
          - group: "" # core
            resources: ["nodes"]
      - level: None
        userGroups: ["system:nodes"]
        verbs: ["get"]
        resources:
          - group: "" # core
            resources: ["nodes"]
      - level: None
        users:
          - system:kube-controller-manager
          - system:kube-scheduler
          - system:serviceaccount:kube-system:endpoint-controller
        verbs: ["get", "update"]
        namespaces: ["kube-system"]
        resources:
          - group: "" # core
            resources: ["endpoints"]
      - level: None
        users: ["system:apiserver"]
        verbs: ["get"]
        resources:
          - group: "" # core
            resources: ["namespaces"]
      # Read-only URLs — not logged.
      - level: None
        nonResourceURLs:
          - /healthz*
          - /version
          - /swagger*
      # Events — not logged.
      - level: None
        resources:
          - group: "" # core
            resources: ["events"]
      # Secrets, ConfigMaps, and TokenReviews contain sensitive or binary data —
      # log metadata only.
      - level: Metadata
        resources:
          - group: "" # core
            resources: ["secrets", "configmaps"]
          - group: authentication.k8s.io
            resources: ["tokenreviews"]
      # Read requests for known API groups — log request metadata only (responses can be large).
      - level: Request
        verbs: ["get", "list", "watch"]
        resources:
          - group: "" # core
          - group: "admissionregistration.k8s.io"
          - group: "apps"
          - group: "authentication.k8s.io"
          - group: "authorization.k8s.io"
          - group: "autoscaling"
          - group: "batch"
          - group: "certificates.k8s.io"
          - group: "extensions"
          - group: "networking.k8s.io"
          - group: "policy"
          - group: "rbac.authorization.k8s.io"
          - group: "settings.k8s.io"
          - group: "storage.k8s.io"
      # Write requests for known API groups — log full request and response.
      - level: RequestResponse
        resources:
          - group: "" # core
          - group: "admissionregistration.k8s.io"
          - group: "apps"
          - group: "authentication.k8s.io"
          - group: "authorization.k8s.io"
          - group: "autoscaling"
          - group: "batch"
          - group: "certificates.k8s.io"
          - group: "extensions"
          - group: "networking.k8s.io"
          - group: "policy"
          - group: "rbac.authorization.k8s.io"
          - group: "settings.k8s.io"
          - group: "storage.k8s.io"
      # All other requests — log metadata only.
      - level: Metadata
  3. Configure the Kube API Server file on master nodes.

    Log on to all master nodes one by one and complete the following configurations in the Kube API Server file at the path /etc/kubernetes/manifests/kube-apiserver.yaml:

    • dd the --audit-log-* parameter to the command based on the following example:

      ...
      spec:
        containers:
        - command:
          - kube-apiserver
          - --audit-log-maxbackup=10
          - --audit-log-maxsize=100
          - --audit-log-path=/var/log/kubernetes/kubernetes.audit
          - --audit-log-maxage=30
          - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
          ...
    • Add the env parameter aliyun_logs_audit-* based on the following example:

      You must replace {cluster_id} in the following example with the Cluster ID of your cluster. You can log on to Security Center console and obtain the Cluster ID of the cluster on the Container page. ${cluster_id} specifies the cluster ID. You can log on to the Security Center console and obtain the Cluster ID of the destination cluster from the Cluster Information column in the cluster list on the Container Assets > Cluster page.

      ...
      spec:
        containers:
        - command:
          - kube-apiserver
          - --audit-log-maxbackup=10
          - --audit-log-maxsize=100
          - --audit-log-path=/var/log/kubernetes/kubernetes.audit
          - --audit-log-maxage=30
          - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
          ...
          ...
          env:
          - name: aliyun_logs_audit-${cluster_id}
            value: /var/log/kubernetes/kubernetes.audit
          - name: aliyun_logs_audit-${cluster_id}_tags
            value: audit=apiserver
          - name: aliyun_logs_audit-${cluster_id}_product
            value: k8s-audit
          - name: aliyun_logs_audit-${cluster_id}_jsonfile
            value: "true"
          image: registry-vpc.cn-shenzhen.aliyuncs.com/acs/kube-apiserver:v1.20.4-aliyun.1
    • Mount /etc/kubernetes/audit-policy.yaml to the API Server Pod as shown in the following example.

      ...
      spec:
        containers:
        - command:
          - kube-apiserver
          - --audit-log-maxbackup=10
          - --audit-log-maxsize=100
          - --audit-log-path=/var/log/kubernetes/kubernetes.audit
          - --audit-log-maxage=30
          - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
          ...
          ...
          env:
          - name: aliyun_logs_audit-${cluster_id}
            value: /var/log/kubernetes/kubernetes.audit
          - name: aliyun_logs_audit-${cluster_id}_tags
            value: audit=apiserver
          - name: aliyun_logs_audit-${cluster_id}_product
            value: k8s-audit
          - name: aliyun_logs_audit-${cluster_id}_jsonfile
            value: "true"
          image: registry-vpc.cn-shenzhen.aliyuncs.com/acs/kube-apiserver:v1.20.4-aliyun.1
          ...
          ...
          volumeMounts:
          - mountPath: /var/log/kubernetes
            name: k8s-audit
          - mountPath: /etc/kubernetes/audit-policy.yaml
            name: audit-policy
            readOnly: true
          ...
          ...
        volumes:
        - hostPath:
            path: /var/log/kubernetes
            type: DirectoryOrCreate
          name: k8s-audit
        - hostPath:
            path: /etc/kubernetes/audit-policy.yaml
            type: FileOrCreate
          name: audit-policy
        ...

Step 3. Verify log collection

  1. Log on to the Simple Log Service console.

  2. Click the name of the destination project.

  3. Check whether the related logs are collected to the Logstore under the destination project.

Step 4. Enable threat detection

  1. Log on to Security Center console.

  2. In the left-side navigation pane, choose Asset Center > Container. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

  3. On the Cluster tab, click Self-built cluster access.

  4. Find the self-managed cluster for which you want to enable K8s log-based threat detection. In the Actions column, click Edit.

  5. On the Enable Log Collection tab, select Enable Kubernetes Log Reporting to Detect Threats, configure the audit log information, and then click Save.

    • Region of Log Audit Service: Select the region in which audit logs are stored.

    • Project of Log Audit Service: Enter the name of the project created in Step 1. Install Logtail. Example: k8s-log-custom-sd89ehdq.

    • Logstore of Log Audit Service: Enter the name of the Logstore automatically created in Step 1. Install Logtail. Example: audit-027b007a7dd11967a9f7e2449d8dc497.