Criar API Token
Introdução
Esta documentação descreve o processo para criar um token de API não expirável e persistente para uma ServiceAccount no Kubernetes, utilizando um Secret do tipo kubernetes.io/service-account-token. Esse método é útil quando o mecanismo de solicitação de token não é adequado, fornecendo tokens de longa duração.
Crie tokens de API de longa duração apenas se o mecanismo de solicitação de token não for adequado. O mecanismo de solicitação de token fornece tokens com tempo limitado; devido à sua expiração, representam um risco menor à segurança da informação.
Passos para Criar um Token de API Persistente
1. Criação de um Secret
Para criar um token de API não expirável para uma ServiceAccount, crie um Secret do tipo kubernetes.io/service-account-token com uma anotação referenciando a ServiceAccount. O plano de controle gerará um token de longa duração e atualizará o Secret com os dados do token gerado.
2. Manifesto de Exemplo
Altere os campos my-serviceaccount e my-namespace para os valores de sua preferência.
Service Account:
apiVersion: v1
kind: ServiceAccount
metadata:
name: discovery
namespace: defaultSecret:
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
name: discovery-token
namespace: default
annotations:
kubernetes.io/service-account.name: discovery3. Crie um ClusterRole e um ClusterRoleBinding com permissões de READ para o Cluster:
ClusterRole:
Regra para somente ler no cluster os pods, services e deployments.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: read-cluster-discovery
rules:
- apiGroups: ["", "*"]
resources: ["*"]
verbs: ["get", "list"]Para realizar um gerenciamento eficaz do inventário em um ambiente Kubernetes, é necessário utilizar ConfigMaps e Secrets para estabelecer correlações entre os serviços. No entanto, o Simon não interpreta metadados, incluindo dados sensíveis, o que torna essencial a recuperação de ConfigMaps e Secrets para identificar e relacionar os recursos corretamente no cluster.
Ao extrair estas informações, é importante notar que as chaves armazenadas em Secrets não são expostas, garantindo a segurança dos dados sensíveis.
ClusterRoleBinding:
O ClusterRoleBinding dá as regras criadas no ClusterRole para a ServiceAccount (my-serviceaccount) criada anteriomente.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: discovery
subjects:
- kind: ServiceAccount
name: discovery
namespace: default
apiGroup: ""
roleRef:
kind: ClusterRole
name: read-cluster-discovery
apiGroup: rbac.authorization.k8s.ioE então o secret usado por essa ServiceAccount pode ser usado somente para ler o Cluster, como indicado em "verbs: ["get"]"
4. Verificação dos Detalhes do Secret
Para ver os detalhes do Secret criado, execute:
kubectl -n my-namespace describe secret my-secretname5. Exemplo de Saída
A saída será semelhante a:
6. Rode o seguinte comando mostrar o Token Gerado:
kubectl get secret my-secretname -n my-namespace -o jsonpath='{.data.token}' | base64 --decode7. Rode o seguinte comando para validar o Token:
curl -H "Authorization: Bearer <TOKEN>" -k https://<kubernetes-api-server>:16443/api/v1/nodes