authentication - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Aplique práticas de autenticação, autorização e identidade de pods com privilégio mínimo para proteger clusters ACK.

Autenticação e autorização em clusters ACK

O Kubernetes autentica requisições de API por meio de certificados X.509, bearer tokens, proxies de autenticação ou OIDC. O ACK suporta nativamente dois métodos de acesso: Client certificates e Service account tokens.

Obtain a kubeconfig file com um certificado de cliente pelo console do Alibaba Cloud ou chamando uma operação da OpenAPI do ACK.

A autorização no ACK inclui autorização RAM e RBAC. O RAM oferece dois tipos de políticas de autorização: políticas do sistema e políticas personalizadas. Crie políticas personalizadas do RAM para operações como gerenciar a visibilidade do cluster, dimensionar clusters ou adicionar nós. Para gerenciar recursos do Kubernetes, como pods e nós, conceda permissões RBAC aos usuários RAM na página Authorizations do ACK console. Consulte Authorization overview.

Use arquivos kubeconfig temporários e autenticação no servidor de API

O certificado padrão do kubeconfig tem validade de três anos. Se comprometido, um invasor poderá acessar diretamente o servidor de API do cluster. O token da conta de serviço padrão também é uma credencial estática de longa duração; caso seja comprometida, o invasor obtém as permissões de acesso ao cluster vinculadas até a exclusão da conta de serviço.

Imediatamente revoke any compromised kubeconfig credential. Consulte Obtain and use a kubeconfig file.
Siga o princípio do privilégio mínimo para acessar recursos do Alibaba Cloud

Ao conceder acesso a clusters ACK, não inclua permissões para outros produtos cloud. Use RAM e RBAC para aplicar apenas as permissões estritamente necessárias.
Adote o princípio do privilégio mínimo ao criar RoleBindings e ClusterRoleBindings

Siga o privilégio mínimo ao criar recursos RoleBinding e ClusterRoleBinding. Evite ["*"] nas definições de Role e ClusterRole — especifique verbs explicitamente. Utilize ferramentas como audit2rbac para gerar funções e vínculos a partir dos logs de auditoria do Kubernetes.
Controle o escopo de acesso dos endpoints do cluster ACK

Por padrão, o endpoint do servidor de API de um cluster ACK é acessível apenas pela rede interna — dentro do cluster e de sua Virtual Private Cloud (VPC). Para expor um service à internet, configure Classic Load Balancer (CLB) with annotations.
Audite regularmente as permissões de acesso ao cluster

As permissões de acesso ao cluster mudam ao longo do tempo. Revise periodicamente as permissões RAM e RBAC para verificar se o acesso está adequado. Empregue ferramentas como kubectl-who-can e rbac-lookup para auditar permissões e remover acessos excessivos.

Autenticação de pods

Algumas aplicações em um cluster Kubernetes precisam acessar a API do Kubernetes. Por exemplo, o ACK Cloud Controller Manager (CCM) requer permissões para criar, ler, atualizar e excluir recursos de nó.

Contas de serviço do Kubernetes

Uma conta de serviço atribui uma função RBAC do Kubernetes a um pod. O Kubernetes cria uma conta de serviço padrão para cada namespace. Pods implantados sem referência a uma conta de serviço específica utilizam o padrão do namespace. Um segredo contendo um JSON Web Token (JWT) é montado em /var/run/secrets/kubernetes.io/serviceaccount. A decodificação desse token revela os seguintes metadados:
```
{
  "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"
}
```
A conta de serviço padrão possui as seguintes permissões da API do Kubernetes:
```
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
```
Essa função concede acesso de leitura às informações de descoberta de API para usuários autenticados e não autenticados, sendo considerada segura para acesso público.

Quando um pod chamar a API do Kubernetes, atribua a ele uma conta de serviço com permissões explícitas de API. Limite a Role ou ClusterRole vinculada apenas aos recursos e métodos de API necessários, seguindo o princípio do privilégio mínimo. Para usar uma conta de serviço diferente do padrão, defina o campo spec.serviceAccountName na especificação do pod. Consulte ServiceAccount permissions.
Use projeção de volume de token de conta de serviço

Ative a projeção de volume de token de conta de serviço no ACK para mitigar riscos de segurança. O kubelet emite tokens por pod com público-alvo e expiração configuráveis, rotacionando-os após 80% do período de validade ou depois de 24 horas. Consulte Use ServiceAccount token volume projection.
Restrinja o acesso dos nós à API de metadados da instância

Os metadados de instâncias ECS são acessíveis a partir de instâncias em execução e podem conter dados sensíveis, como detalhes de recursos cloud e dados do usuário. O acesso irrestrito a metadados pode ser explorado em ambientes multilocatários. Para pods que não exigem tráfego de saída, use uma política de rede para restringir o acesso ao meta-server. O exemplo abaixo utiliza um podSelector para bloquear todo o tráfego de saída de um pod específico, incluindo o acesso ao meta-server.
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metadata-access
  namespace: example
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Egress
  egress: []
```
Consulte Use network policies in ACK clusters.
Desative a montagem automática de tokens de conta de serviço nos pods

Escolha um dos métodos a seguir para desativar a montagem automática do token de conta de serviço.
Método 1: No YAML do pod, defina automountServiceAccountToken como false.
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...
```
Método 2: Aplique um patch na conta de serviço padrão do namespace para definir o campo automountServiceAccountToken como false.
```
kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'
```
Atribua uma conta de serviço dedicada a cada aplicação

Atribua uma conta de serviço exclusiva para cada aplicação, garantindo isolamento granular de permissões. Consulte Configure Service Accounts for pods.
Execute aplicações como usuário não root

Os containers executam como root por padrão, o que concede aos processos acesso arbitrário a arquivos. Em vez disso, adicione a propriedade spec.securityContext.runAsUser ao PodSpec para especificar um ID de usuário não root.

Neste exemplo, todos os processos do pod são executados sob o campo runAsUser.
```
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" ]
```
Os processos do container não conseguem acessar arquivos restritos ao root. Adicionar fsGroup ao securityContext concede acesso de leitura aos arquivos dentro do container.
```
spec:
  securityContext:
    fsGroup: 65534
```
Siga o princípio do privilégio mínimo ao conceder acesso das aplicações a recursos do Alibaba Cloud

Evite permissões RAM desnecessárias nos nós da aplicação. Elabore políticas RAM granulares seguindo o privilégio mínimo. Não utilize curingas como ["*"] nas políticas de permissão, pois eles podem conceder acesso excessivo.

Autenticação via webhook do Authenticator

Se você utilizar integração com SSO do RAM e gerenciar a autorização RBAC do Kubernetes independentemente, use ack-ram-authenticator for API server webhook authentication. Vantagens:

Suporta SSO cloud corporativo com autorização RBAC flexível e controlável no plano de dados.
Em cenários de integração SSO baseada em funções, o log de auditoria do API server inclui informações de identidade do IDP corporativo, permitindo auditar diferentes usuários do IDP que assumem a mesma função.
Quando um usuário ou função RAM de um colaborador é excluído, as permissões RBAC associadas no cluster são revogadas automaticamente.