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 yaml 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 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"] 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 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 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 7\ rode o seguinte comando para validar o token command curl h "authorization bearer \<token>" k https //\<kubernetes api server> 16443/api/v1/nodes