Container Service for Kubernetes:Identity verification and access control

RAM authorization and RBAC authorization

The authorization mechanism of ACK consists of RAM authorization and RBAC authorization:

For more information, see Authorization overview.

Use a temporary kubeconfig file for API server access

The default kubeconfig file of an ACK cluster contains a certificate that is valid for three years. If the kubeconfig file is exposed, attackers can use it to gain access to the Kubernetes API server of the cluster. The default service account token is a static credential that is permanently valid. If the default service account token is exposed, attackers can exploit the token to gain the same permissions as the relevant service account until the account is deleted.

If a delivered kubeconfig file is exposed, we recommend that you revoke the kubeconfig file at the earliest opportunity. For more information, see Revoke the kubeconfig file of a cluster. For more information about temporary kubeconfig files, see Generate a temporary kubeconfig file.

Grant access in compliance with the principle of least privilege

When you authorize a user to access ACK clusters, do not grant the permissions to access resources of other Alibaba Cloud services. You can use RAM authorization and RBAC authorization to grant a user only the permissions required to access ACK clusters.

Create RoleBindings and ClusterRoleBindings with minimal permissions

You must create RoleBindings and ClusterRoleBindings in compliance with the principle of least privilege. When you define a Role or ClusterRole, specify the required actions instead of ["*"] in the Verbs field. If you cannot decide the permissions to grant, you can use tools such as audit2rbac to generate roles and role bindings that cover all API operations recorded in the Kubernetes audit log.

Limit access to the cluster endpoint

By default, the endpoint of an ACK cluster can be accessed only from within the cluster and the virtual private cloud (VPC) in which the cluster is deployed. For more information about how to enable Internet access for Services and control access to the endpoint, see Add annotations to the YAML file of a Service to configure CLB instances.

Audit permissions regularly

The permissions that a user has on a cluster may change over time. The security administrators and operations and maintenance (O&M) engineers of a cluster must regularly check the RAM permissions and RBAC permissions of each RAM user and make sure that only the required permissions are granted. You can use open source tools to check the RBAC permissions that are granted to a service account, user, or group, and remove permissions that are not required. For more information, see kubectl-who-can and rbac-lookup.

Kubernetes service accounts

A service account can be used to assign an RBAC role to a Pod. Kubernetes creates a default service account for each namespace in the cluster. When you create a Pod, if you do not specify a service account, the Pod is automatically assigned the default service account in the same namespace. A Secret that stores a JSON Web Token (JWT) is mounted to the /var/run/secrets/kubernetes.io/serviceaccount directory of the Pod as a volume. If you decode the token, the following metadata is returned:

{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "default-token-vpc2x",
  "kubernetes.io/serviceaccount/service-account.name": "default",
  "kubernetes.io/serviceaccount/service-account.uid": "1d059c50-0818-4b15-905d-bbf05e1d****",
  "sub": "system:serviceaccount:default:default"
}

The default service account has the following permissions on the Kubernetes API:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /openapi
  - /openapi/*
  - /version
  - /version/
  verbs:
  - get

The role can be used to grant unauthenticated and authenticated users the permissions to read API information. This role is deemed safe to be publicly accessible.

Service account best practices

Follow these practices to securely manage service accounts for Pods:

• Assign service accounts with the right permissions: When an application or program that runs in a Pod calls the Kubernetes API, the Pod must be assigned a service account that has the required permissions. The permissions defined in the Role or ClusterRole that is associated with the service account must be scoped to the API resources that the Pod needs to access and the methods that the Pod needs to use. This complies with the principle of least privilege. To use non-default service accounts, set the spec.serviceAccountName field in the Pod configuration to the name of the service account that you want to use. For more information about how to create a service account, see ServiceAccount permissions.

• Assign a separate service account to each application: To enable fine-grained application permission management, you must assign a separate service account to each application. For more information, see Configure service accounts for Pods.

• Disable automatic mounting of service account tokens: You can disable automatic mounting of service account tokens for Pods by using one of the following methods. Method 1: Set automountServiceAccountToken in PodSpec to false by using the following YAML template: Method 2: Run the following command to set the automountServiceAccountToken parameter of the default service account in a namespace to false by using a patch:

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      serviceAccountName: build-robot
      automountServiceAccountToken: false
      ...

    kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'

Enable Service Account Token Volume Projection

ACK provides Service Account Token Volume Projection to reduce security risks when Pods use service accounts to access the Kubernetes API server. This feature enables the kubelet to request and store the token on behalf of a Pod. This feature also allows you to configure token properties, such as the audience and validity period. If a token has existed for more than 24 hours or only 20% or less of its validity period remains, kubelet automatically rotates the token. For more information, see Enable service account token volume projection.

Limit access to instance metadata

Elastic Compute Service (ECS) instance metadata contains information about ECS instances in Alibaba Cloud. You can view the metadata of running instances and configure or manage the instances based on their metadata. Instance metadata contains sensitive information, such as the used cloud resources and user data. If the metadata of an instance is exposed to Pods that are deployed on the instance, the information may be exploited by attackers in multi-tenant scenarios.

For Pods that do not need to send outbound requests, you can use network policies to forbid the Pods from accessing meta-server. The following code block shows a network policy that blocks all outbound requests from Pods with the labels that are specified in the podSelector parameter. This way, the matching Pods cannot access meta-server.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metadata-access
  namespace: example
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Egress
  egress: []

For more information, see Use network policies in ACK clusters.

Run applications as non-root users

By default, a container runs as a root user. This allows processes in a container to perform read and write operations on data in the container, which violates security best practices. To run a container as a non-root user, add the spec.securityContext.runAsUser parameter to PodSpec. Set runAsUser to a proper value based on your requirements.

The following template specifies that all processes in the Pod run with the user ID that is specified in the runAsUser field:

apiVersion: v1
kind: Pod
metadata:
  name: security-test
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: sec-test
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]

This way, processes in the container cannot access files that require root privileges. If you add fsgroup=65534 [Nobody] to the securityContext parameter, processes in the container are allowed to access these files.

spec:
  securityContext:
    fsGroup: 65534

Grant permissions on Alibaba Cloud resources with minimal privileges

Do not grant excessive permissions to RAM users or RAM roles. You must configure RAM policies in compliance with the principle of least privilege and must not configure settings that may grant excessive permissions, such as specifying ["*"] in the policy content.