authentication - Container Service for Kubernetes - Alibaba Cloud Documentation Center

Apply least-privilege authentication, authorization, and pod identity practices to secure ACK clusters.

Authentication and authorization in ACK clusters

Kubernetes authenticates API requests with X.509 certificates, bearer tokens, authentication proxies, or OIDC. ACK natively supports two access methods: Client certificates and Service account tokens.

Obtain a kubeconfig file with a client certificate from the Alibaba Cloud console or by calling an ACK OpenAPI operation.

Authorization in ACK includes RAM authorization and RBAC authorization. RAM supports two types of authorization policies: system policies and custom policies. Create custom RAM policies for operations such as managing cluster visibility, scaling clusters, or adding nodes. To manage Kubernetes resources such as pods and nodes, grant RAM users RBAC permissions on the Authorizations page of the ACK console. See Authorization overview.

Use temporary kubeconfig files and API server authentication

The default kubeconfig certificate is valid for three years. If compromised, an attacker can directly access the cluster API server. The default service account token is also a long-lived static credential—if compromised, an attacker gains the bound cluster access permissions until the service account is deleted.

Promptly revoke any compromised kubeconfig credential. See Obtain and use a kubeconfig file.
Follow the principle of least privilege to access Alibaba Cloud resources

When granting ACK cluster access, do not include permissions for other cloud products. Use RAM and RBAC to enforce minimum required permissions.
Use the principle of least privilege when you create RoleBindings and ClusterRoleBindings

Follow least privilege when creating RoleBinding and ClusterRoleBinding resources. Avoid ["*"] in Role and ClusterRole definitions—specify explicit verbs. Use a tool such as audit2rbac to generate roles and bindings from Kubernetes audit logs.
Control the access scope of ACK cluster endpoints

By default, an ACK cluster API server endpoint is accessible only from the internal network—within the cluster and its Virtual Private Cloud (VPC). To expose a service to the internet, configure Classic Load Balancer (CLB) with annotations.
Regularly audit cluster access permissions

Cluster access permissions change over time. Regularly review RAM and RBAC permissions to verify appropriate access. Use tools such as kubectl-who-can and rbac-lookup to audit permissions and remove excessive access.

Pod authentication

Some applications in a Kubernetes cluster need Kubernetes API access. For example, the ACK Cloud Controller Manager (CCM) requires permissions to create, read, update, and delete node resources.

Kubernetes service accounts

A service account assigns a Kubernetes RBAC role to a pod. Kubernetes creates a default service account for each namespace. Pods deployed without referencing a specific service account use the namespace default. A secret containing a JSON Web Token (JWT) is mounted at /var/run/secrets/kubernetes.io/serviceaccount. Decoding this token reveals the following metadata:
```
{
  "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 these Kubernetes API permissions:
```
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
```
This role grants unauthenticated and authenticated users read access to API discovery information and is considered safe for public access.

When a pod calls the Kubernetes API, assign it a service account with explicit API permissions. Limit the bound Role or ClusterRole to only the required API resources and methods, following least privilege. To use a non-default service account, set the spec.serviceAccountName field in the pod spec. See ServiceAccount permissions.
Use service account token volume projection

Enable service account token volume projection in ACK to mitigate security risks. The kubelet issues per-pod tokens with configurable audience and expiration, rotating them at 80% of their validity period or after 24 hours. See Use ServiceAccount token volume projection.
Restrict node access to the instance metadata API

ECS instance metadata is accessible from running instances and can contain sensitive data such as cloud resource details and user data. Unrestricted metadata access can be exploited in multi-tenant environments. For pods that do not require egress, use a network policy to restrict meta-server access. The following example uses a podSelector to block all egress for a specified pod, including meta-server access.
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metadata-access
  namespace: example
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Egress
  egress: []
```
See Use network policies in ACK clusters.
Disable automatic mounting of service account tokens for pods

Use one of the following methods to disable automatic service account token mounting.
Method 1: In the pod YAML, set automountServiceAccountToken to false.
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...
```
Method 2: Patch the default service account in the namespace to set the automountServiceAccountToken field to false.
```
kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'
```
Assign a dedicated service account to each application

Assign each application a dedicated service account for fine-grained permission isolation. See Configure Service Accounts for pods.
Run applications as a non-root user

Containers run as root by default, granting processes arbitrary file access. Instead, add the spec.securityContext.runAsUser property to the PodSpec to specify a non-root user ID.

In this example, all pod processes run under 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" ]
```
Container processes cannot access root-only files. Adding fsGroup to the securityContext grants read access to files within the container.
```
spec:
  securityContext:
    fsGroup: 65534
```
Follow the principle of least privilege when you grant applications access to Alibaba Cloud resources

Avoid unnecessary RAM permissions on application nodes. Create fine-grained RAM policies following least privilege. Avoid wildcards such as ["*"] in permission policies, which can grant excessive access.

Authenticator webhook authentication

If you use RAM SSO integration and manage Kubernetes RBAC authorization independently, use ack-ram-authenticator for API server webhook authentication. Advantages:

Supports enterprise cloud SSO with flexible, controllable data plane RBAC authorization.
In role-based SSO integration scenarios, the API server audit log includes enterprise IDP identity information, enabling audit of different IDP users who assume the same role.
When an employee's RAM user or role is deleted, the associated cluster RBAC permissions are automatically revoked.