Criar API Token

10min
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:
yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: discovery
  namespace: default
apiVersion: v1
kind: ServiceAccount
metadata:
  name: discovery
  namespace: default
﻿
Secret:
yaml
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: discovery-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: discovery
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: discovery-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: discovery
﻿
3. Crie um ClusterRole e um ClusterRoleBinding com permissões de READ para o Cluster:
ClusterRole:
Regra para somente ler recursos necessário para estabelecer as correlações entre os serviços. Entretanto, é possível fazer mudanças, se julgar essencial a retirada de recursos, como o secret, ou adicionar outros recursos.
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: read-cluster-discovery
rules:
  - apiGroups: [""]
    resources:
      - pods
      - services
      - secret
      - configmaps
      - namespaces
    verbs: ["get", "list"]
  - apiGroups: ["apps"]
    resources:
      - deployments
      - statefulsets
      - daemonsets
    verbs: ["get", "list"]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: read-cluster-discovery
rules:
  - apiGroups: [""]
    resources:
      - pods
      - services
      - secret
      - configmaps
      - namespaces
    verbs: ["get", "list"]
  - apiGroups: ["apps"]
    resources:
      - deployments
      - statefulsets
      - daemonsets
    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.
yaml
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.io
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.io
﻿
E 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:
command
kubectl -n my-namespace describe secret my-secretname
kubectl -n my-namespace describe secret my-secretname
﻿
5. Exemplo de Saída
A saída será semelhante a:
Namespace:      my-namespace
Labels:         <none>
Annotations:    kubernetes.io/service-account.name=my-serviceaccount
                kubernetes.io/service-account.uid=8a85c4c4-8483-11e9-bc42-526af7764f64

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1362 bytes
namespace:      9 bytes
token:          <TOKEN_GERADO>
6. Rode o seguinte comando mostrar o Token Gerado:
Exemplo
kubectl get secret my-secretname -n my-namespace -o jsonpath='{.data.token}' | base64 --decode
kubectl get secret my-secretname -n my-namespace -o jsonpath='{.data.token}' | base64 --decode
﻿
7. Rode o seguinte comando para validar o Token:
command
curl -H "Authorization: Bearer <TOKEN>" -k https://<kubernetes-api-server>:16443/api/v1/nodes

curl -H "Authorization: Bearer <TOKEN>" -k https://<kubernetes-api-server>:16443/api/v1/nodes
﻿
﻿
Visualizar a porta da API do Cluster Kubernetes
Exportar métricas do Istio