Container Service for Kubernetes:FAQ about container security

• Why do containers fail to communicate with each other?

• How do I specify a security group for an ACK cluster?

• Can I disable cluster auditing when I create a cluster or enable cluster auditing after the cluster is created?

• How do I renew the certificate of a dedicated Kubernetes cluster and renew the certificates of the components in the cluster?

• How do I fix the "no providers available to validate pod request" error during pod creation?

• Why am I unable to use existing Secrets in a new namespace?

• How do I fix the mount error when I mount the default token?

• How do I query the auditing log?

• How do I collect the diagnostic information of nodes in an ACK Edge cluster?

• The kubelet log of an ACK cluster that uses the CentOS 7.6 operating system contains the "Reason:KubeletNotReady Message:PLEG is not healthy:" information

Why do containers fail to communicate with each other?

The following section describes the causes of network failures of different security group settings and provides solutions to the failures.

• Cause: The inbound rule in which Authorization Object is Pod CIDR Block and Protocol Type is All is deleted.

  1. Log on to the ACK console. In the left-side navigation pane, click Clusters.

  2. On the Clusters page, click the name of the cluster that you want to manage and click Cluster Information in the left-side navigation pane.

  3. On the Cluster Information tab, click the Cluster Resources tab, and then click the link to the right of VPC.

  4. On the Resources tab, click the number below Security Group.

  5. Find the security group that you want to manage, and click Add Rules in the Actions column.

  6. On the Inbound tab, click Add Rule.

  7. Configure Protocol Type, Port Range, and Authorization Object. Then, click Save.

     Note

     • Set Protocol Type to All.

     • Set Authorization Object to the pod CIDR block of the cluster.

       You can find the pod CIDR block in the Cluster Information section of the cluster details page in the ACK console.

       For more information about Authorization Object, see Security groups for different use cases.

     In the added inbound rule, Authorization Object is set to the Pod CIDR Block of the cluster and Protocol Type is set to All.

• Cause: The new Elastic Compute Service (ECS) instance and the Kubernetes cluster belong to different security groups.

  1. Log on to the ACK console. In the left-side navigation pane, click Clusters.

  2. On the Clusters page, click the name of the cluster that you want to manage and click Cluster Information in the left-side navigation pane.

  3. On the Cluster Information tab, click the Cluster Resources tab. Then, click the link to the right of VPC.

  4. On the VPC Details page, click the number below Security Group on the Resources tab. You are redirected to the Security Groups page in the ECS console. You can view the details of the security group on this page.

  5. On the Security Groups page, view the name of the security group.

  6. In the left-side navigation pane of the ECS console, choose Instances & Images > Instances.

  7. On the Instances page, find the instance that you want to manage, and choose More > Network and Security Group > Add to Security Group in the Actions column. The Add to Security Group dialog box appears.

  8. In the Security Group drop-down list, enter the security group name that you obtained in step d.

  9. Click OK.

  Verify the result

  1. In the left-side navigation pane of the ECS console, choose Instances & Images > Instances. On the Instances page, click the name of the instance that is added to the security group.

  2. On the Security Groups tab, verify that the ECS instance is added to the security group to which the Kubernetes cluster belongs.

How do I specify a security group for an ACK cluster?

You cannot specify a security group for an ACK cluster. A default security group is automatically specified for an ACK cluster when the cluster is created. You can modify the rules of the default security group.

Can I disable cluster auditing when I create a cluster or enable cluster auditing after the cluster is created?

Yes, you can disable cluster auditing when you create a cluster or enable cluster auditing after the cluster is created. For more information, see Work with cluster auditing.

How do I renew the certificate of a dedicated Kubernetes cluster and renew the certificates of the components in the cluster?

• Approximately two months before a certificate expires, an internal message and a text message are sent to remind you about the expiration of the certificate. You can go to the clusters page in the console and click Renew to renew the certificate. For more information, see Renew expiring Kubernetes cluster certificates.

• For more information about how to renew an expired certificate, see Update expired certificates of a Kubernetes cluster.

How do I fix the "no providers available to validate pod request" error during pod creation?

• If no custom pod security policy (PSP) is defined, the error appears because you deleted the default PSP. You can restore the default PSP to fix the error. For more information, see [Deprecated] Use pod security policies.

• If you want to use a custom PSP, see Configure pod security policies (earlier version).

Why am I unable to use existing Secrets in a new namespace?

Secrets are scoped to namespaces. You must create new Secrets in a new namespace.

How do I fix the mount error when I mount the default token?

Normal Scheduled 13m default-scheduler Successfully assigned dev/alibaba-demo-67fcdbfb8-zklnp to cn-hangzhou.10.7.3.16  Warning FailedMount 13m (x2 over 13m) kubelet, cn-hangzhou.10.7.3.16 MountVolume.SetUp failed for volume 'default-token-8twx9' : mount failed: exit status 1 Mounting command: systemd-run Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/62d39b35-9a4d-11ea-9870-c24d56a0e904/volumes/kubernetes.io~secret/default-token-8twx9 --scope -- mount -t tmpfs tmpfs /var/lib/kubelet/pods/62d39b35-9a4d-11ea-9870-c24d56a0e904/volumes/kubernetes.io~secret/default-token-8twx9 Output: Failed to start transient scope unit: Argument list too long  Warning FailedCreatePodContainer 3m40s (x49 over 13m) kubelet, cn-hangzhou.10.7.3.16 unable to ensure pod container exists: failed to create container for [kubepods burstable pod62d39b35-9a4d-11ea-9870-c24d56a0e904] : Argument list too long

The systemd version is outdated.

• Upgrade systemd. For more information, see systemd.

• Run the sudo systemctl daemon-reload command to reload units. For more information, see systemd.

How do I query the auditing log?

Query the auditing log about Role-Based Access Control (RBAC) operations

1. Log on to the ACK console. In the left-side navigation pane, click Clusters.

2. On the Clusters page, click the name of the cluster that you want to manage and click Cluster Information in the left-side navigation pane.

3. On the Cluster Information page, click the Cluster Resources tab. Then, click the link to the right of Log Service Project.

4. On the Log Storage > Logstores page, click the audit-<cluster_id> Logstore that you want to query and click Search & Analysis.

   

5. In the upper-right corner, click 15 Minutes(Relative) to specify the time period that you want to query.

   Note

   Select a time period that covers the time when errors occurred, for example, 3 days, 7 day, or 15 days.

6. In the Search & Analyze search bar, enter the following SQL statement and then click Search & Analyze.

   requestURI: "rbac.authorization.k8s.io" not (verb: get or verb: watch) 

7. Click the icon. In the Log Download dialog box, select Download All Logs with Cloud Shell and click OK.

Query the auditing log about ConfigMap operations

requestURI: "configmaps" and <configmap_name> not (verb: get or verb: watch or verb: list) 

Query the auditing log about Deployment scaling operations

requestURI: deployments and (verb: update or verb: patch) and replicas and deployments and <deployment_name> not deployment-controller