Referência

Esta seção da documentação do Kubernetes contém referências.

Referência da API

• Visão geral da API do Kubernetes - Visão geral da API para Kubernetes.
• Referência da API Kubernetes v1.35

Biblioteca de clientes da API

Para chamar a API Kubernetes de uma linguagem de programação, você pode usar bibliotecas de clientes. Bibliotecas oficialmente suportadas:

• Biblioteca do cliente Kubernetes em Go
• Biblioteca do cliente Kubernetes em Python
• Biblioteca do cliente Kubernetes em Java
• Biblioteca do cliente Kubernetes em JavaScript

Referência da CLI

• kubectl - Ferramenta CLI principal para executar comandos e gerenciar clusters do Kubernetes.
  • JSONPath - Guia de sintaxe para usar Expressões JSONPath com o kubectl.
• kubeadm - Ferramenta CLI para provisionar facilmente um cluster Kubernetes seguro.

Referência de configuração

• kubelet - O principal agente do nó que é executado em cada nó. O kubelet usa um conjunto de PodSpecs e garante que os contêineres descritos estejam funcionando e saudáveis.
• kube-apiserver - API REST que valida e configura dados para objetos de API, como pods, serviços, controladores de replicação.
• kube-controller-manager - Daemon que incorpora os principais loops de controle enviados com o Kubernetes.
• kube-proxy - É possível fazer o encaminhamento de fluxo TCP/UDP de forma simples ou utilizando o algoritimo de Round Robin encaminhando através de um conjunto de back-ends.
• kube-scheduler - Agendador que gerencia disponibilidade, desempenho e capacidade.

Documentos de design

Um arquivo dos documentos de design para as funcionalidades do Kubernetes. Bons pontos de partida são Arquitetura Kubernetes e Visão geral do design do Kubernetes.

1 - Glossário

2 - Autenticação

Essa página demonstra uma visão geral sobre autenticação

Usuários no Kubernetes

Todos os clusters Kubernetes possuem duas categorias de usuários: contas de serviço gerenciadas pelo Kubernetes e usuários normais.

Assume-se que um serviço independente do cluster gerencia usuários normais das seguintes formas:

• Um administrador distribuindo chaves privadas
• Uma base de usuários como Keystone

  Keystone é o serviço de identidade usado pelo OpenStack para autenticação (authN) e autorização de alto nível (authZ). Atualmente, ele oferece suporte a authN com base em token e autorização de serviço do usuário. Recentemente, foi reprojetado para permitir a expansão para oferecer suporte a serviços externos de proxy e mecanismos AuthN / AuthZ, como oAuth, SAML e openID em versões futuras.

  ou Google Accounts
• Um arquivo com uma lista de nomes de usuários e senhas

Neste quesito, Kubernetes não possui objetos que possam representar as contas de um usuário normal. Usuários normais não podem ser adicionados ao cluster através de uma chamada para a API.

Apesar de um usuário normal não poder ser adicionado através de uma chamada para a API, qualquer usuário que apresente um certificado válido e assinado pela autoridade de certificados (CA) do cluster é considerado autenticado. Nesta configuração, Kubernetes determina o nome do usuário baseado no campo de nome comum no sujeito (subject) do certificado (por exemplo: "/CN=bob"). A partir daí, o subsistema de controle de acesso baseado em função (RBAC) determina se o usuário é autorizado a realizar uma operação específica sobre o recurso. Para mais detalhes, veja a referência sobre o tópico de usuários normais dentro de requisição de certificado.

Em contraste a usuários normais, contas de serviço são considerados usuários gerenciados pela API do Kubernetes. Elas estão vinculadas à namespaces específicas e criadas automaticamente pelo servidor de API ou manualmente através de chamadas da API. Contas de serviço estão ligadas a um conjunto de credenciais armazenados como Secrets, aos quais são montados dentro dos pods assim permitindo que processos internos ao cluster comuniquem-se com a API do Kubernetes.

Requisições para a API estão ligadas a um usuário normal, conta de serviço ou serão tratadas como requisições anônimas. Isto significa que cada processo dentro ou fora do cluster, desde um usuário humano utilizando o kubectl de uma estação de trabalho, a kubelets rodando nos nós, a membros da camada de gerenciamento (s/painel de controle) devem autenticar-se ao realizarem suas requisições para o servidor API ou serão tratados como usuário anônimo.

Estratégias de autenticação

Kubernetes usa certificados de clientes, bearer Token, um proxy realizando autenticação, ou uma autenticação básica HTTP para autenticar requisições para o servidor de API através de plugins. Como requisições HTTP são feitas no servidor de API, plugins tentam associar os seguintes atributos junto a requisição:

• Username

  Um nome de usuário é um nome que identifica exclusivamente alguém em um sistema de computador. Por exemplo, um computador pode ser configurado com várias contas, com nomes de usuário diferentes para cada conta. Muitos sites permitem que os usuários escolham um nome de usuário para que possam personalizar suas configurações ou configurar uma conta online. Por exemplo, seu banco pode permitir que você escolha um nome de usuário para acessar suas informações bancárias. Você pode precisar escolher um nome de usuário para postar mensagens em um determinado quadro de mensagens na web. Os serviços de e-mail, como o Hotmail, exigem que os usuários escolham um nome de usuário para usar o serviço.

  Um nome de usuário geralmente é pareado com uma senha. Essa combinação de nome de usuário / senha é conhecida como login e geralmente é necessária para que os usuários façam login em sites. Por exemplo, para acessar seu e-mail pela Web, é necessário inserir seu nome de usuário e senha. Depois de fazer o login, seu nome de usuário pode aparecer na tela, mas sua senha é mantida em segredo. Ao manter sua senha privada, as pessoas podem criar contas seguras para vários sites. A maioria dos nomes de usuário pode conter letras e números, mas não espaços. Quando você escolhe um nome de usuário para uma conta de e-mail, a parte antes de "@" é o seu nome de usuário.

  : um valor (String) que identifica o usuário final. Valores comuns podem ser kube-admin ou jane@example.com
• UID

  Uma string gerada pelos sistemas do Kubernetes para identificar objetos de forma única.

  Cada objeto criado durante todo o ciclo de vida do cluster do Kubernetes possui um UID distinto. O objetivo deste identificador é distinguir ocorrências históricas de entidades semelhantes.

  : um valor (String) que identifica o usuário final e tenta ser mais consistente e único do que username.
• Groups: Um conjunto de valores em que cada item indica a associação de um usuário à uma coleção lógica de usuários. Valores comuns podem ser system:masters ou devops-team.
• Campos extras: um mapa que pode conter uma lista de atributos que armazena informações adicionais em que autorizadores podem achar útil.

Todos os valores são transparentes para o sistema de autenticação e somente trazem significado quando interpretados por um autorizador.

É possível habilitar múltiplos métodos de autenticação. Deve-se normalmente usar pelo menos dois métodos:

• Tokens para contas de serviço;
• Pelo menos um outro método de autenticação para usuários.

Quando múltiplos módulos de autenticação estão habilitados, o primeiro módulo a autenticar com sucesso uma requisição termina, o fluxo de avaliação da mesma.

O servidor de API não garante a ordem em que os autenticadores são processados.

O grupo system:authenticated é incluído na lista de grupos de todos os usuários autenticados.

Integrações com outros protocolos de autenticação, como LDAP

Abreviatura para "Lightweight Directory Access Protocol". Se você deseja disponibilizar informações de diretório na Internet, esta é a maneira de fazê-lo. O LDAP é uma versão simplificada de um padrão de diretório anterior denominado X.500. O que torna o LDAP tão útil é que ele funciona muito bem em redes TCP / IP (ao contrário do X.500), de modo que as informações podem ser acessadas por meio do LDAP por qualquer pessoa com uma conexão à Internet. Também é um protocolo aberto, o que significa que os diretórios podem ser armazenados em qualquer tipo de máquina (por exemplo, Windows 2000, Red Hat Linux, Mac OS X).

Para dar uma ideia de como um diretório LDAP é organizado, aqui estão os diferentes níveis de uma hierarquia de árvore LDAP simples:

O diretório raiz Países Organizações Divisões, departamentos, etc. Indivíduos Recursos individuais, como arquivos e impressoras. A maior parte da conectividade LDAP é feita nos bastidores, então o usuário típico provavelmente não notará ao navegar na web. No entanto, é uma boa tecnologia para se conhecer. Se nada mais, é outro termo para impressionar seus pais.

SAML significa Linguagem de Marcação para Asserção de Segurança. É um padrão aberto baseado em XML para transferência de dados de identidade entre duas partes: um provedor de identidade (IdP) e um provedor de serviços (SP).

Provedor de identidade - executa autenticação e passa a identidade do usuário e o nível de autorização para o provedor de serviços.

Provedor de serviços - confia no provedor de identidade e autoriza o usuário fornecido a acessar o recurso solicitado.

A autenticação de logon único SAML normalmente envolve um provedor de serviços e um provedor de identidade. O fluxo do processo geralmente envolve os estágios de estabelecimento de confiança e fluxo de autenticação.

Considere este exemplo:

Nosso provedor de identidade é Auth0 Nosso provedor de serviços é um serviço fictício, Zagadat Nota: O provedor de identidade pode ser qualquer plataforma de gerenciamento de identidade.

Agora, um usuário está tentando obter acesso ao Zagadat usando a autenticação SAML.

Este é o fluxo do processo:

O usuário tenta fazer login no Zagadat a partir de um navegador. O Zagadat responde gerando uma solicitação SAML.

Kerberos é um protocolo de rede que usa criptografia de chave secreta para autenticar aplicativos cliente-servidor. O Kerberos solicita um tíquete criptografado por meio de uma sequência de servidor autenticada para usar os serviços.

Kerberos foi desenvolvido pelo Project Athena - um projeto conjunto entre o Massachusetts Institute of Technology (MIT), Digital Equipment Corporation e IBM que funcionou entre 1983 e 1991.

Um servidor de autenticação usa um tíquete Kerberos para conceder acesso ao servidor e, em seguida, cria uma chave de sessão com base na senha do solicitante e outro valor aleatório. O tíquete de concessão de tíquete (TGT) é enviado ao servidor de concessão de tíquete (TGS), que é necessário para usar o mesmo servidor de autenticação.

O solicitante recebe uma chave TGS criptografada com um registro de data e hora e um tíquete de serviço, que é retornado ao solicitante e descriptografado. O solicitante envia ao TGS essas informações e encaminha a chave criptografada ao servidor para obter o serviço desejado. Se todas as ações forem tratadas corretamente, o servidor aceita o tíquete e realiza o atendimento ao usuário desejado, que deve descriptografar a chave, verificar a data e hora e entrar em contato com o centro de distribuição para obter as chaves de sessão. Essa chave de sessão é enviada ao solicitante, que descriptografa o tíquete.

Se as chaves e o carimbo de data / hora forem válidos, a comunicação cliente-servidor continuará. O tíquete TGS tem carimbo de data / hora, o que permite solicitações simultâneas dentro do período de tempo alocado.

X.509 é um formato padrão para certificados de chave pública, documentos digitais que associam com segurança pares de chaves criptográficas a identidades como sites, indivíduos ou organizações.

Introduzido pela primeira vez em 1988 junto com os padrões X.500 para serviços de diretório eletrônico, o X.509 foi adaptado para uso na Internet pelo grupo de trabalho Public-Key Infrastructure (X.509) (PKIX) da IETF. O RFC 5280 define o perfil do certificado X.509 v3, a lista de revogação de certificado X.509 v2 (CRL) e descreve um algoritmo para a validação do caminho do certificado X.509.

As aplicações comuns de certificados X.509 incluem:

- SSL / TLS e HTTPS para navegação na web autenticada e criptografada
- E-mail assinado e criptografado por meio do protocolo S / MIME
- Assinatura de código
- Assinatura de documento
- Autenticação de cliente
- Identificação eletrônica emitida pelo governo

Certificados de cliente X509

Autenticação via certificados de cliente pode ser habilitada ao passar a opção --client-ca-file=ARQUIVO para o servidor de API. O arquivo referenciado deve conter um ou mais autoridades de certificação usadas para validar o certificado de cliente passado para o servidor de API. Se o certificado de cliente é apresentado e verificado, o common name

O nome comum é normalmente composto de Host + Nome de domínio e será semelhante a www.seusite.com ou seusite.com. Os certificados de servidor SSL são específicos para o nome comum para o qual foram emitidos no nível do host.

O nome comum deve ser igual ao endereço da Web que você acessará ao se conectar a um site seguro. Por exemplo, um certificado de servidor SSL para o domínio domínio.com receberá um aviso do navegador se o acesso a um site chamado www.domain.com ou secure.domain.com, pois www.domain.com e secure.domain.com são diferentes de dominio.com. Você precisaria criar um CSR para o nome comum correto.

Por exemplo, utilizando o comando de linha openssl para gerar uma requisição de assinatura de certificado:

openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"

Isto criaria um arquivo de tipo CSR (requisição de assinatura de certificado) para o usuário "jbeda" pertencendo a dois grupos: "app1" e "app2".

Veja como gerar um certificado de cliente em Gerenciando Certificados

Arquivo estático de Token

O servidor de API lê bearer tokens de um arquivo quando recebe uma requisição contendo a opção --token-auth-file=ARQUIVO via linha de comando. Atualmente, tokens têm duração indefinida, e a lista de tokens não pode ser modificada sem reiniciar o servidor de API.

O arquivo de token é do tipo CSV contendo no mínimo 3 colunas: token, nome de usuário, identificador de usuário (uid), seguido pelos nomes de grupos (opcional).

token,usuario,uid,"grupo1,grupo2,grupo3"

Adicionando um bearer token em uma requisição

Quando utilizando-se de bearer token para autenticação de um cliente HTTP, o servidor de API espera um cabeçalho Authorization com um valor Bearer TOKEN. O token deve ser uma sequência de caracteres que pode ser colocada como valor em um cabeçalho HTTP não utilizando-se mais do que as facilidades de codificação e citação de HTTP. Por exemplo, se o valor de um token é 31ada4fd-adec-460c-809a-9e56ceb75269 então iria aparecer dentro de um cabeçalho HTTP como:

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

Tokens de inicialização

Para permitir a inicialização simplificada para novos clusters, Kubernetes inclui um token dinamicamente gerenciado denominado Bootstrap Token. Estes tokens são armazenados como Secrets dentro do namespace kube-system, onde eles podem ser dinamicamente criados e gerenciados. O componente Gerenciador de Controle (Controller Manager) possui um controlador "TokenCleaner" que apaga os tokens de inicialização expirados.

Os tokens seguem o formato [a-z0-9]{6}.[a-z0-9]{16}. O primeiro componente é um identificador do token e o segundo é o segredo. Você pode especificar o token como um cabeçalho HTTP como:

Authorization: Bearer 781292.db7bc3a58fc5f07e

Deve-se habilitar os tokens de inicialização com a opção --enable-bootstrap-token-auth no servidor de API. Deve-se habilitar o controlador TokenCleaner através da opção --controllers no Gerenciador de Controle. Isso é feito, por exemplo, como: --controllers=*,tokencleaner. O kubeadm, por exemplo, irá realizar isso caso seja utilizado para a inicialização do cluster.

O autenticador o autentica como system:bootstrap:<Token ID> e é incluído no grupo system:bootstrappers. O nome e grupo são intencionalmente limitados para desencorajar usuários a usarem estes tokens após inicialização. Os nomes de usuários e grupos podem ser utilizados (e são utilizados pelo kubeadm) para elaborar as políticas de autorização para suportar a inicialização de um cluster.

Por favor veja Bootstrap Tokens para documentação detalhada sobre o autenticador e controladores de Token de inicialização, bem como gerenciar estes tokens com kubeadm.

Tokens de Contas de serviço

Uma conta de serviço é um autenticador habilitado automaticamente que usa bearer tokens para verificar as requisições. O plugin aceita dois parâmetros opcionais:

• --service-account-key-file Um arquivo contendo uma chave codificada no formato PEM para assinar bearer tokens. Se não especificado, a chave privada de TLS no servidor de API será utilizada
• --service-account-lookup Se habilitado, tokens deletados do servidor de API serão revogados.

Contas de serviço são normalmente criadas automaticamente pelo servidor de API e associada a pods rodando no cluster através do controlador de admissão Admission Controller de ServiceAccount. Os tokens de contas de serviços são montados nos Pods, em localizações já pré definidas e conhecidas e permitem processos dentro do cluster a se comunicarem com o servidor de API. Contas podem ser explicitamente associadas com pods utilizando o campo serviceAccountName na especificação do pod (PodSpec):

apiVersion: apps/v1 
kind: Deployment
metadata:
 name: nginx-deployment
 namespace: default
spec:
 replicas: 3
 template:
   metadata:
   # ...
   spec:
     serviceAccountName: bob-the-bot
     containers:
     - name: nginx
       image: nginx:1.14.2

Os tokens de contas de serviço são perfeitamente válidos para ser usados fora do cluster e podem ser utilizados para criar identidades para processos de longa duração que desejem comunicar-se com a API do Kubernetes. Para criar manualmente uma conta de serviço, utilize-se simplesmente o comando kubectl create serviceaccount (NOME). Isso cria uma conta de serviço e um segredo associado a ela no namespace atual.

kubectl create serviceaccount jenkins

serviceaccount "jenkins" created

Verificando um segredo associado:

kubectl get serviceaccounts jenkins -o yaml

apiVersion: v1
kind: ServiceAccount
metadata:
 # ...
secrets:
- name: jenkins-token-1yvwg

O segredo criado irá armazenar a autoridade de certificado do servidor de API e um JSON Web Token (JWT) digitalmente assinado.

kubectl get secret jenkins-token-1yvwg -o yaml

apiVersion: v1
data:
 ca.crt: (APISERVER'S CA BASE64 ENCODED)
 namespace: ZGVmYXVsdA==
 token: (BEARER TOKEN BASE64 ENCODED)
kind: Secret
metadata:
 # ...
type: kubernetes.io/service-account-token

O JWT assinado pode ser usado como um bearer token para autenticar-se como a conta de serviço. Veja acima como o token pode ser incluído em uma requisição. Normalmente esses segredos são montados no pod para um acesso interno ao cluster ao servidor de API, porém pode ser utilizado fora do cluster também.

Contas de serviço são autenticadas com o nome de usuário system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT) e são atribuídas aos grupos system:serviceaccounts e system:serviceaccounts:(NAMESPACE).

AVISO: porque os tokens das contas de serviço são armazenados em segredos, qualquer usuário com acesso de leitura a esses segredos podem autenticar-se como a conta de serviço. Tome cuidado quando conceder permissões a contas de serviços e capacidade de leitura de segredos.

Tokens OpenID Connect

OpenID Connect é uma variação do framework de autorização OAuth2 que suporta provedores como Azure Active Directory, Salesforce, e Google. A principal extensão do OAuth2 é um campo adicional de token de acesso chamado ID Token. Este token é um tipo de JSON Web Token (JWT) com campos bem definidos, como usuário, e-mail e é assinado pelo servidor de autorização.

Para identificar o usuário, o autenticador usa o id_token (e não access_token) do bearer token da resposta de autorização do OAuth2 token response. Veja acima como incluir um token em uma requisição.

1. Login no seu provedor de identidade.
2. Seu provedor de identidade ira fornecer um access_token, id_token e um refresh_token.
3. Quando utilizando kubectl, utilize do seu id_token com a opção --token ou adicione o token diretamente no seu arquivo de configuração kubeconfig.
4. kubectl envia o seu id_token em um cabeçalho HTTP chamado Authorization para o servidor de API.
5. O servidor de API irá garantir que a assinatura do token JWT é válida, verificando-o em relação ao certificado mencionado na configuração.
6. Verificação para garantir que oid_token não esteja expirado.
7. Garantir que o usuário é autorizado.
8. Uma vez autorizado o servidor de API retorna a resposta para o kubectl.
9. kubectl fornece retorno ao usuário.

Uma vez que todos os dados necessários para determinar sua identidade encontram-se no id_token, Kubernetes não precisa realizar outra chamada para o provedor de identidade. Em um modelo onde cada requisição não possui estado, isso fornece uma solução escalável para autenticação. Isso, porem, apresenta alguns desafios:

1. Kubernetes não possui uma "interface web" para disparar o processo de autenticação. Não há browser ou interface para coletar credenciais que são necessárias para autenticar-se primeiro no seu provedor de identidade.
2. O id_token não pode ser revogado, funcionando como um certificado, portanto deve possuir curta validade (somente alguns minutos) o que pode tornar a experiência um pouco desconfortável, fazendo com que se requisite um novo token toda vez em um curto intervalo (poucos minutos de validade do token)
3. Para autenticar-se ao dashboard Kubernetes, você deve executar o comando kubectl proxy ou um proxy reverso que consiga injetar o id_token.

Configurando o Servidor de API

Para habilitar o plugin de autorização, configure as seguintes opções no servidor de API:

É importante ressaltar que o servidor de API não é um cliente Oauth2, ao contrário, ele só pode ser configurado para confiar em um emissor. Isso permite o uso de emissores públicos, como Google, sem confiar em credenciais emitidas por terceiros. Administradores que desejam utilizar-se de múltiplos clientes OAuth2 devem explorar provedores os quais suportam atributos azp (parte autorizada), que é um mecanismo para permitir um cliente a emitir tokens em nome de outro.

Kubernetes não oferece um provedor de identidade OpenID Connect. Pode-se utilizar provedores públicos existentes como Google ou outros. Ou, pode-se rodar o próprio provedor de identidade no cluster, como dex, Keycloak, CloudFoundry UAA, ou Tremolo Security's OpenUnison.

Para um provedor de identidades funcionar no Kubernetes, ele deve:

1. Suportar o framework OpenID connect discovery; Nem todos suportam.
2. Executar TLS com cifras criptográficas não obsoletos.
3. Possuir certificados assinados por uma Autoridade certificadora (mesmo que o CA não seja comercial ou seja auto-assinado)

Uma nota sobre o requisito #3 acima. Se você instalar o seu próprio provedor de identidades (ao invés de utilizar um provedor como Google ou Microsoft) você DEVE ter o certificado web do seu provedor de identidades assinado por um certificado contendo a opção CA configurada para TRUE, mesmo que seja um certificado auto assinado. Isso deve-se a implementação do cliente TLS em Golang que é bastante restrito quanto aos padrões em torno da validação de certificados. Se você não possui um CA em fácil alcance, você pode usar este script criado pelo time Dex para criar um simples CA, um par de chaves e certificado assinados. Ou você pode usar este script similar o qual gera certificados SHA256 com uma vida mais longa e tamanho maior de chave.

Instruções de configuração para sistemas específicos podem ser encontrados em:

• UAA
• Dex
• OpenUnison

Utilizando kubectl

Opção 1 - Autenticador OIDC

A primeira opção é utilizar-se do autenticador oidc do kubectl, o qual define o valor do id_token como um bearer token para todas as requisições e irá atualizar o token quando o mesmo expirar. Após você efetuar o login no seu provedor, utilize o kubectl para adicionar os seus id_token, refresh_token, client_id, e client_secret para configurar o plugin.

Provedores os quais não retornem um id_token como parte da sua resposta de refresh token não são suportados por este plugin e devem utilizar a opção 2 abaixo.

kubectl config set-credentials USER_NAME \
  --auth-provider=oidc \
  --auth-provider-arg=idp-issuer-url=( issuer url ) \
  --auth-provider-arg=client-id=( your client id ) \
  --auth-provider-arg=client-secret=( your client secret ) \
  --auth-provider-arg=refresh-token=( your refresh token ) \
  --auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
  --auth-provider-arg=id-token=( your id_token )

Um exemplo, executando o comando abaixo após autenticar-se no seu provedor de identidades:

kubectl config set-credentials mmosley  \
       --auth-provider=oidc  \
       --auth-provider-arg=idp-issuer-url=https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP  \
       --auth-provider-arg=client-id=kubernetes  \
       --auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5  \
       --auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \
       --auth-provider-arg=idp-certificate-authority=/root/ca.pem \
       --auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw

O qual irá produzir a configuração abaixo:

users:
- name: mmosley
 user:
   auth-provider:
     config:
       client-id: kubernetes
       client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5
       id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
       idp-certificate-authority: /root/ca.pem
       idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP
       refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq
     name: oidc

Uma vez que seu id_token expire, kubectl irá tentar atualizar o seu id_token utilizando-se do seu refresh_token e client_secret armazenando os novos valores para refresh_token e id_token no seu arquivo de configuração .kube/config.

Opção 2 - Utilize a opção --token

O comando kubectl o permite passar o valor de um token utilizando a opção --token. Copie e cole o valor do seu id_token nesta opção:

kubectl --token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes

Token de autenticação via Webhook

Webhook de autenticação é usado para verificar bearer tokens

• --authentication-token-webhook-config-file arquivo de configuração descrevendo como acessar o serviço remoto de webhook.
• --authentication-token-webhook-cache-ttl por quanto tempo guardar em cache decisões de autenticação. Configuração padrão definida para dois minutos.
• --authentication-token-webhook-version determina quando usar o apiVersion authentication.k8s.io/v1beta1 ou authentication.k8s.io/v1 para objetos TokenReview quando enviar/receber informações do webhook. Valor padrão v1beta1.

O arquivo de configuração usa o formato de arquivo do kubeconfig. Dentro do arquivo, clusters refere-se ao serviço remoto e users refere-se ao servidor de API do webhook. Um exemplo seria:

# versão da API do Kubernetes
apiVersion: v1
# tipo do objeto da API
kind: Config
# clusters refere-se ao serviço remoto
clusters:
 - name: name-of-remote-authn-service
   cluster:
     certificate-authority: /path/to/ca.pem         # CA para verificar o serviço remoto
     server: https://authn.example.com/authenticate # URL para procurar o serviço remoto. Deve utilizar 'https'.
 
# users refere-se a configuração do webhook do servidor de  API
users:
 - name: name-of-api-server
   user:
     client-certificate: /path/to/cert.pem # certificado para ser utilizado pelo plugin de webhook
     client-key: /path/to/key.pem          # chave referente ao certificado
 
# arquivos kubeconfig requerem um contexto. Especifique um para o servidor de API.
current-context: webhook
contexts:
- context:
   cluster: name-of-remote-authn-service
   user: name-of-api-server
 name: webhook

Quando um cliente tenta autenticar-se com o servidor de API utilizando um bearer token como discutido acima, o webhook de autenticação envia um objeto JSON serializado do tipo TokenReview contendo o valor do token para o serviço remoto.

Note que objetos de API do tipo webhook estão sujeitos às mesmas regras de compatibilidade de versão como outros objetos de API Kubernetes. Implementadores devem verificar o campo de versão da API (apiVersion) da requisição para garantir a correta deserialização e devem responder com um objeto do tipo TokenReview da mesma versão da requisição.

• authentication.k8s.io/v1
• authentication.k8s.io/v1beta1

{
 "apiVersion": "authentication.k8s.io/v1",
 "kind": "TokenReview",
 "spec": {
   # Bearer token opaco enviado para o servidor de API
   "token": "014fbff9a07c...",
 
   # Lista opcional de identificadores de audiência para o servidor ao qual o token foi apresentado
   # Autenticadores de token  sensíveis a audiência (por exemplo, autenticadores de token OIDC)
   # deve-se verificar que o token foi direcionado a pelo menos um membro da lista de audiência
   # e retornar a interseção desta lista a audiência válida para o token no estado da resposta
   # Isto garante com que o token é válido para autenticar-se no servidor ao qual foi apresentado
   # Se nenhuma audiência for especificada, o token deve ser validado para autenticar-se ao servidor de API do Kubernetes
   "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
 }
}

{
 "apiVersion": "authentication.k8s.io/v1beta1",
 "kind": "TokenReview",
 "spec": {
   # Bearer token opaco enviado para o servidor de API
   "token": "014fbff9a07c...",
 
   # Lista opcional de identificadores de audiência para o servidor ao qual o token foi apresentado
   # Autenticadores de token  sensíveis a audiência (por exemplo, autenticadores de token OIDC)
   # deve-se verificar que o token foi direcionado a pelo menos um membro da lista de audiência
   # e retornar a interseção desta lista a audiência válida para o token no estado da resposta
   # Isto garante com que o token é válido para autenticar-se no servidor ao qual foi apresentado
   # Se nenhuma audiência for especificada, o token deve ser validado para autenticar-se ao servidor de API do Kubernetes
   "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
 }
}

É esperado que o serviço remoto preencha o campo status da requisição para indicar o sucesso do login. O campo spec do corpo de resposta é ignorado e pode ser omitido. O serviço remoto deverá retornar uma resposta usando a mesma versão de API do objeto TokenReview que foi recebido. Uma validação bem sucedida deveria retornar:

• authentication.k8s.io/v1
• authentication.k8s.io/v1beta1

{
 "apiVersion": "authentication.k8s.io/v1",
 "kind": "TokenReview",
 "status": {
   "authenticated": true,
   "user": {
     # Obrigatório
     "username": "janedoe@example.com",
     # Opcional
     "uid": "42",
     # Opcional: lista de grupos associados
     "groups": ["developers", "qa"],
     # Opcional: informação adicional  provida pelo autenticador.
     # Isto não deve conter dados confidenciais, pois pode ser registrados em logs ou em objetos de API e estarão disponíveis para webhooks de admissão
     "extra": {
       "extrafield1": [
         "extravalue1",
         "extravalue2"
       ]
     }
   },
   # Lista opcional de Autenticadores de token  sensíveis a audiência que podem ser retornados,
   # contendo as audiências da lista `spec.audiences` válido para o token apresentado.
   # Se este campo for omitido, o token é considerado válido para autenticar-se no servidor de API Kubernetes
   "audiences": ["https://myserver.example.com"]
 }
}

{
 "apiVersion": "authentication.k8s.io/v1beta1",
 "kind": "TokenReview",
 "status": {
   "authenticated": true,
   "user": {
     # Obrigatório
     "username": "janedoe@example.com",
     # Opcional
     "uid": "42",
     # Opcional: lista de grupos associados
     "groups": ["developers", "qa"],
     # Opcional: informação adicional  provida pelo autenticador.
     # Isto não deve conter dados confidenciais, pois pode ser registrados em logs ou em objetos de API e estarão disponíveis para webhooks de admissão
     "extra": {
       "extrafield1": [
         "extravalue1",
         "extravalue2"
       ]
     }
   },
   # Lista opcional de Autenticadores de token  sensíveis a audiência que podem ser retornados,
   # contendo as audiências da lista `spec.audiences` válido para o token apresentado.
   # Se este campo for omitido, o token é considerado válido para autenticar-se no servidor de API Kubernetes
   "audiences": ["https://myserver.example.com"]
 }
}

Uma requisição mal sucedida retornaria:

• authentication.k8s.io/v1
• authentication.k8s.io/v1beta1

{
 "apiVersion": "authentication.k8s.io/v1",
 "kind": "TokenReview",
 "status": {
   "authenticated": false,
   # Opcionalmente inclui detalhes sobre o porque a autenticação falhou
   # Se nenhum erro é fornecido, a API irá retornar uma mensagem genérica de "Não autorizado"
   # O campo de erro é ignorado quando authenticated=true.
   "error": "Credenciais expiradas"
 }
}

{
 "apiVersion": "authentication.k8s.io/v1beta1",
 "kind": "TokenReview",
 "status": {
   "authenticated": false,
   # Opcionalmente inclui detalhes sobre o porque a autenticação falhou
   # Se nenhum erro é fornecido, a API irá retornar uma mensagem genérica de "Não autorizado"
   # O campo de erro é ignorado quando authenticated=true.
   "error": "Credenciais expiradas"
 }
}

Autenticando com Proxy

O servidor de API pode ser configurado para identificar usuários através de valores de cabeçalho de requisição, como por exemplo X-Remote-User. Isto é projetado para o uso em combinação com um proxy de autenticação, o qual irá atribuir o valor do cabeçalho da requisição.

• --requestheader-username-headers Obrigatório, não faz distinção entre caracteres maiúsculos/minúsculos. Nomes de cabeçalhos a serem verificados, em ordem, para a identidade do usuário. O primeiro cabeçalho contendo um valor será usado para o nome do usuário.

• --requestheader-group-headers 1.6+. Opcional, não faz distinção entre caracteres maiúsculos/minúsculos. "X-Remote-Group" é recomendado. Nomes de cabeçalhos a serem verificados, em ordem, para os grupos do usuário. Todos os valores especificados em todos os cabeçalhos serão utilizados como nome dos grupos do usuário.

• --requestheader-extra-headers-prefix 1.6+. Opcional, não faz distinção entre caracteres maiúsculos/minúsculos. "X-Remote-Extra-" é recomendado. Prefixos de cabeçalhos para serem utilizados para definir informações extras sobre o usuário (normalmente utilizado por um plugin de autorização). Todos os cabeçalhos que começam com qualquer um dos prefixos especificados têm o prefixo removido. O restante do nome do cabeçalho é transformado em letra minúscula, decodificado percent-decoded e torna-se uma chave extra, e o valor do cabeçalho torna-se um valor extra.

Por exemplo, com esta configuração:

--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-

e esta requisição:

GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile

resultaria nesta informação de usuário:

name: fido
groups:
- dogs
- dachshunds
extra:
 acme.com/project:
 - some-project
 scopes:
 - openid
 - profile

Para prevenir falsificação de cabeçalhos, o proxy de autenticação deverá apresentar um certificado de cliente válido para o servidor de API para que possa ser validado com a autoridade de certificados (CA) antes que os cabeçalhos de requisições sejam verificados. AVISO: não re-utilize uma autoridade de certificados (CA) que esteja sendo utilizado em um contexto diferente ao menos que você entenda os riscos e os mecanismos de proteção da utilização de uma autoridade de certificados.

• --requestheader-client-ca-file Obrigatório. Pacote de certificados no formato PEM. Um certificado válido deve ser apresentado e validado com a autoridade de certificados no arquivo especificado antes da verificação de cabeçalhos de requisição para os nomes do usuário.

• --requestheader-allowed-names Opcional. Lista de valores de nomes comuns (CNs). Se especificado, um certificado de cliente válido contendo uma lista de nomes comuns denominados deve ser apresentado na verificação de cabeçalhos de requisição para os nomes do usuário. Se vazio, qualquer valor de nomes comuns será permitido.

Requisições anônimas

Quando habilitado, requisições que não são rejeitadas por outros métodos de autenticação configurados são tratadas como requisições anônimas e são dadas o nome de usuário system:anonymous e filiação ao grupo system:unauthenticated.

Por exemplo, uma requisição especificando um bearer token invalido chega a um servidor com token de autenticação configurado e acesso anônimo habilitado e receberia um erro de acesso não autorizado 401 Unauthorized. Já uma requisição não especificando nenhum bearer token seria tratada como uma requisição anônima.

Nas versões 1.5.1-1.5.x, acesso anônimo é desabilitado por padrão e pode ser habilitado passando a opção --anonymous-auth=true durante a inicialização do servidor de API.

Na versão 1.6 e acima, acesso anônimo é habilitado por padrão se um modo de autorização diferente de AlwaysAllow é utilizado e pode ser desabilitado passando a opção --anonymous-auth=false durante a inicialização do servidor de API. Começando na versão 1.6, os autorizadores ABAC (Controle de Acesso Baseado em Atributos) e RBAC (Controle de Acesso Baseado em Função) requerem autorização explícita do usuário system:anonymous e do grupo system:unauthenticated, portanto, regras de políticas legadas que permitam acesso a usuário * e grupo * nao incluíram usuários anônimos.

Personificação de usuário

Um usuário pode agir como outro através de cabeçalhos de personificação. Os mesmos permitem que requisições manualmente sobrescrevam as informações ao quais o usuário irá se autenticar como. Por exemplo, um administrador pode utilizar-se desta funcionalidade para investigar um problema com uma política de autorização e assim, temporariamente, personificar um outro usuário e ver se/como sua requisição está sendo negada.

Requisições de personificação primeiramente são autenticadas como o usuário requerente, então trocando para os detalhes de informação do usuário personificado.

O fluxo é:

• Um usuário faz uma chamada de API com suas credenciais e cabeçalhos de personificação.
• O servidor de API autentica o usuário.
• O servidor de API garante que o usuário autenticado possui permissão de personificação.
• Detalhes de informação do usuário da requisição tem seus valores substituídos com os detalhes de personificação.
• A requisição é avaliada e a autorização é feita sobre os detalhes do usuário personificado.

Os seguintes cabeçalhos HTTP podem ser usados para realizar uma requisição de personificação:

• Impersonate-User: O nome do usuário para se executar ações em seu nome.
• Impersonate-Group: Um nome de grupo para se executar ações em seu nome. Pode ser especificado múltiplas vezes para fornecer múltiplos grupos. Opcional. Requer "Impersonate-User".
• Impersonate-Extra-( extra name ): Um cabeçalho dinâmico usado para associar campos extras do usuário. Opcional. Requer "Impersonate-User". Para que seja preservado consistentemente, ( extra name ) deve ser somente minúsculo, e qualquer caracter que não seja legal em rótulos de cabeçalhos HTTP DEVE ser utf8 e codificado.

Um exemplo de conjunto de cabeçalhos HTTP:

Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins
Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
Impersonate-Extra-acme.com%2Fproject: some-project
Impersonate-Extra-scopes: view
Impersonate-Extra-scopes: development

Quando utilizando-se o kubectl especifique a opção --as para determinar o cabeçalho Impersonate-User, especifique a opção --as-group para determinar o cabeçalho Impersonate-Group.

kubectl drain mynode

Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)

Especificando as opções --as e --as-group:

kubectl drain mynode --as=superman --as-group=system:masters

node/mynode cordoned
node/mynode drained

Para personificar um usuário, grupo ou especificar campos extras, o usuário efetuando a personificação deve possuir a permissão de executar o verbo "impersonate" no tipo de atributo sendo personificado ("user", "group", etc.). Para clusters com o plugin de autorização RBAC habilitados, a seguinte ClusterRole abrange as regras necessárias para definir os cabeçalhos de personificação de usuário e grupo:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: impersonator
rules:
- apiGroups: [""]
 resources: ["users", "groups", "serviceaccounts"]
 verbs: ["impersonate"]

Campos extras são avaliados como sub-recursos de um recurso denominado "userextras". Para permitir ao usuário que utilize os cabeçalhos de personificação para o campo extra "scopes", o usuário deve receber a seguinte permissão:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: scopes-impersonator
rules:
# Pode definir o cabeçalho "Impersonate-Extra-scopes".
- apiGroups: ["authentication.k8s.io"]
 resources: ["userextras/scopes"]
 verbs: ["impersonate"]

Os valores dos cabeçalhos de personificação podem também ser restringidos ao limitar o conjunto de nomes de recursos (resourceNames) que um recurso pode ter.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: limited-impersonator
rules:
# Pode personificar o usuário "jane.doe@example.com"
- apiGroups: [""]
 resources: ["users"]
 verbs: ["impersonate"]
 resourceNames: ["jane.doe@example.com"]
 
# Pode assumir os grupos "developers" and "admins"
- apiGroups: [""]
 resources: ["groups"]
 verbs: ["impersonate"]
 resourceNames: ["developers","admins"]
 
# Pode personificar os campos extras "scopes" com valores "view" e "development"
- apiGroups: ["authentication.k8s.io"]
 resources: ["userextras/scopes"]
 verbs: ["impersonate"]
 resourceNames: ["view", "development"]

Plugins de credenciais client-go

Ferramentas como kubectl e kubelet utilizando-se do k8s.io/client-go são capazes de executar um comando externo para receber credenciais de usuário.

Esta funcionalidade é direcionada à integração do lado cliente, com protocolos de autenticação não suportados nativamente pelo k8s.io/client-go como: LDAP, Kerberos, OAuth2, SAML, etc. O plugin implementa a lógica específica do protocolo e então retorna credenciais opacas para serem utilizadas. Quase todos os casos de usos de plugins de credenciais requerem um componente de lado do servidor com suporte para um autenticador de token webhook para interpretar o formato das credenciais produzidas pelo plugin cliente.

Exemplo de caso de uso

Num caso de uso hipotético, uma organização executaria um serviço externo que efetuaria a troca de credenciais LDAP por tokens assinados para um usuário específico. Este serviço seria também capaz de responder requisições do autenticador de token webhook para validar tokens. Usuários seriam obrigados a instalar um plugin de credencial em sua estação de trabalho.

Para autenticar na API:

• O usuário entra um comando kubectl.
• O plugin de credencial solicita ao usuário a entrada de credenciais LDAP e efetua troca das credenciais por um token via um serviço externo.
• O plugin de credenciais retorna um token para o client-go, o qual o utiliza como um bearer token no servidor de API.
• O servidor de API usa o autenticador de token webhook para submeter um objeto TokenReview para o serviço externo.
• O serviço externo verifica a assinatura do token e retorna o nome e grupos do usuário.

Configuração

plugins de credencial são configurados através de arquivos de configuração do kubectl como parte dos campos de usuário.

apiVersion: v1
kind: Config
users:
- name: my-user
 user:
   exec:
     # Comando a ser executado. Obrigatório.
     command: "example-client-go-exec-plugin"
 
     # Versão da API a ser utilizada quando decodificar o recurso  ExecCredentials. Obrigatório
     #
     # A versão da API retornada pelo plugin DEVE ser a mesma versão listada aqui.
     #
     # Para integrar com ferramentas que suportem múltiplas versões (tal como client.authentication.k8s.io/v1alpha1),
     # defina uma variável de ambiente ou passe um argumento para a ferramenta que indique qual versão o plugin de execução deve esperar.
     apiVersion: "client.authentication.k8s.io/v1beta1"
 
     # Variáveis de ambiente a serem configuradas ao executar o plugin. Opcional
     env:
     - name: "FOO"
       value: "bar"
 
     # Argumentos a serem passados ao executar o plugin. Opcional
     args:
     - "arg1"
     - "arg2"
 
     # Texto exibido para o usuário quando o executável não parece estar presente. Opcional
     installHint: |
       example-client-go-exec-plugin é necessário para autenticar no cluster atual. Pode ser instalado via:       
 
       Em macOS: brew install example-client-go-exec-plugin
 
       Em Ubuntu: apt-get install example-client-go-exec-plugin
 
       Em Fedora: dnf install example-client-go-exec-plugin
 
       ...
 
     # Deve-se ou não fornecer informações do cluster, que podem potencialmente conter grande quantidade de dados do CA,
     # para esse plugin de execução como parte da variável de ambiente KUBERNETES_EXEC_INFO
     provideClusterInfo: true
clusters:
- name: my-cluster
 cluster:
   server: "https://172.17.4.100:6443"
   certificate-authority: "/etc/kubernetes/ca.pem"
   extensions:
   - name: client.authentication.k8s.io/exec # nome de extensão reservado para configuração exclusiva do cluster
     extension:
       arbitrary: config
       this: pode ser fornecido através da variável de ambiente KUBERNETES_EXEC_INFO na configuração de provideClusterInfo
       you: ["coloque", "qualquer", "coisa", "aqui"]
contexts:
- name: my-cluster
 context:
   cluster: my-cluster
   user: my-user
current-context: my-cluster

Os caminhos relativos do comando são interpretados como relativo ao diretório do arquivo de configuração. Se KUBECONFIG está configurado para o caminho /home/jane/kubeconfig e o comando executado é ./bin/example-client-go-exec-plugin, o binario /home/jane/bin/example-client-go-exec-plugin será executado.

- name: my-user
 user:
   exec:
     # Caminho relativo para o diretorio do kubeconfig
     command: "./bin/example-client-go-exec-plugin"
     apiVersion: "client.authentication.k8s.io/v1beta1"

Formatos de entrada e saída

O comando executado imprime um objeto ExecCredential para o stdout. k8s.io/client-go autentica na API do Kubernetes utilizando as credenciais retornadas no status.

Quando executando uma sessão interativa, stdin é exposto diretamente para o plugin. plugins devem utilizar um TTY check para determinar se é apropriado solicitar um usuário interativamente.

Para usar credenciais do tipo bearer token, o plugin retorna um token no status do objeto ExecCredential.

{
 "apiVersion": "client.authentication.k8s.io/v1beta1",
 "kind": "ExecCredential",
 "status": {
   "token": "my-bearer-token"
 }
}

Alternativamente, um certificado de cliente e chave codificados em PEM podem ser retornados para serem utilizados em autenticação de cliente TLS. Se o plugin retornar um certificado e chave diferentes numa chamada subsequente, k8s.io/client-go Irá fechar conexões existentes com o servidor para forçar uma nova troca TLS.

Se especificado, clientKeyData e clientCertificateData devem ambos estar presentes.

clientCertificateData pode conter certificados intermediários adicionais a serem enviados para o servidor.

{
 "apiVersion": "client.authentication.k8s.io/v1beta1",
 "kind": "ExecCredential",
 "status": {
   "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
   "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
 }
}

Opcionalmente, a resposta pode incluir a validade da credencial em formato RFC3339 de data/hora. A presença ou ausência de validade pode ter o seguinte impacto:

• Se uma validade está incluída, o bearer token e as credenciais TLS são guardadas em cache até a o tempo de expiração é atingido ou se o servidor responder com um codigo de status HTTP 401 ou se o processo terminar.

• Se uma validate está ausente, o bearer token e as credenciais TLS são guardadas em cache até o servidor responder com um código de status HTTP 401 ou até o processo terminar.

{
 "apiVersion": "client.authentication.k8s.io/v1beta1",
 "kind": "ExecCredential",
 "status": {
   "token": "my-bearer-token",
   "expirationTimestamp": "2018-03-05T17:30:20-08:00"
 }
}

Para habilitar o plugin de execução para obter informações específicas do cluster, define provideClusterInfo no campo user.exec dentro do arquivo de configuração kubeconfig. O plugin irá então prover a variável de ambiente KUBERNETES_EXEC_INFO. As informações desta variável de ambiente podem ser utilizadas para executar lógicas de aquisição de credentiais específicas do cluster. O manifesto ExecCredential abaixo descreve um exemplo de informação de cluster.

{
 "apiVersion": "client.authentication.k8s.io/v1beta1",
 "kind": "ExecCredential",
 "spec": {
   "cluster": {
     "server": "https://172.17.4.100:6443",
     "certificate-authority-data": "LS0t...",
     "config": {
       "arbitrary": "config",
       "this": "pode ser fornecido por meio da variável de ambiente KUBERNETES_EXEC_INFO na configuração de provideClusterInfo",
       "you": ["coloque", "qualquer", "coisa", "aqui"]
     }
   }
 }
}

3 - Autenticando com Tokens de Inicialização

Os tokens de inicialização são um bearer token simples que devem ser utilizados ao criar novos clusters ou para quando novos nós são registrados a clusters existentes. Eles foram construídos para suportar a ferramenta kubeadm, mas podem ser utilizados em outros contextos para usuários que desejam inicializar clusters sem utilizar o kubeadm. Foram também construídos para funcionar, via políticas RBAC, com o sistema de Inicialização do Kubelet via TLS.

Visão geral dos tokens de inicialização

Os tokens de inicialização são definidos com um tipo especifico de secrets (bootstrap.kubernetes.io/token) que existem no namespace kube-system. Estes secrets são então lidos pelo autenticador de inicialização do servidor de API. Tokens expirados são removidos pelo controlador TokenCleaner no gerenciador de controle - kube-controller-manager. Os tokens também são utilizados para criar uma assinatura para um ConfigMap específico usado no processo de descoberta através de um controlador denominado BootstrapSigner.

Formato do Token

Tokens de inicialização tem o formato abcdef.0123456789abcdef. Mais formalmente, eles devem corresponder a expressão regular [a-z0-9]{6}\.[a-z0-9]{16}.

A primeira parte do token é um identificador ("Token ID") e é considerado informação pública. Ele é utilizado para se referir a um token sem vazar a parte secreta usada para autenticação. A segunda parte é o secret do token e somente deve ser compartilhado com partes confiáveis.

Habilitando autenticação com tokens de inicialização

O autenticador de tokens de inicialização pode ser habilitado utilizando a seguinte opção no servidor de API:

--enable-bootstrap-token-auth

Quando habilitado, tokens de inicialização podem ser utilizado como credenciais bearer token para autenticar requisições no servidor de API.

Authorization: Bearer 07401b.f395accd246ae52d

Tokens são autenticados como o usuário system:bootstrap:<token id> e são membros do grupo system:bootstrappers. Grupos adicionais podem ser especificados dentro do secret do token.

Tokens expirados podem ser removidos automaticamente ao habilitar o controlador tokencleaner do gerenciador de controle - kube-controller-manager.

--controllers=*,tokencleaner

Formato do secret dos tokens de inicialização

Cada token válido possui um secret no namespace kube-system. Você pode encontrar a documentação completa aqui.

Um secret de token se parece com o exemplo abaixo:

apiVersion: v1
kind: Secret
metadata:
 # Nome DEVE seguir o formato "bootstrap-token-<token id>"
 name: bootstrap-token-07401b
 namespace: kube-system
 
# Tipo DEVE ser 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
 # Descrição legível. Opcional.
 description: "The default bootstrap token generated by 'kubeadm init'."
 
 # identificador do token e _secret_. Obrigatório.
 token-id: 07401b
 token-secret: f395accd246ae52d
 
 # Validade. Opcional.
 expiration: 2017-03-10T03:22:11Z
 
 # Usos permitidos.
 usage-bootstrap-authentication: "true"
 usage-bootstrap-signing: "true"
 
 # Grupos adicionais para autenticar o token. Devem começar com "system:bootstrappers:"
 auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress

O tipo do secret deve ser bootstrap.kubernetes.io/token e o nome deve seguir o formato bootstrap-token-<token id>. Ele também tem que existir no namespace kube-system.

Os membros listados em usage-bootstrap-* indicam qual a intenção de uso deste secret. O valor true deve ser definido para que seja ativado.

• usage-bootstrap-authentication indica que o token pode ser utilizado para autenticar no servidor de API como um bearer token.
• usage-bootstrap-signing indica que o token pode ser utilizado para assinar o ConfigMap cluster-info como descrito abaixo.

O campo expiration controla a expiração do token. Tokens expirados são rejeitados quando usados para autenticação e ignorados durante assinatura de ConfigMaps. O valor de expiração é codificado como um tempo absoluto UTC utilizando a RFC3339. Para automaticamente remover tokens expirados basta habilitar o controlador tokencleaner.

Gerenciamento de tokens com kubeadm

Você pode usar a ferramenta kubeadm para gerenciar tokens em um cluster. Veja documentação de tokens kubeadm para mais detalhes.

Assinatura de ConfigMap

Além de autenticação, os tokens podem ser utilizados para assinar um ConfigMap. Isto pode ser utilizado em estágio inicial do processo de inicialização de um cluster, antes que o cliente confie no servidor de API. O Configmap assinado pode ser autenticado por um token compartilhado.

Habilite a assinatura de ConfigMap ao habilitar o controlador bootstrapsigner no gerenciador de controle - kube-controller-manager.

--controllers=*,bootstrapsigner

O ConfigMap assinado é o cluster-info no namespace kube-public. No fluxo típico, um cliente lê o ConfigMap enquanto ainda não autenticado e ignora os erros da camada de transporte seguro (TLS). Ele então valida o conteúdo do ConfigMap ao verificar a assinatura contida no ConfigMap.

O ConfigMap pode se parecer com o exemplo abaixo:

apiVersion: v1
kind: ConfigMap
metadata:
 name: cluster-info
 namespace: kube-public
data:
 jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
 kubeconfig: |
   apiVersion: v1
   clusters:
   - cluster:
       certificate-authority-data: <really long certificate data>
       server: https://10.138.0.2:6443
     name: ""
   contexts: []
   current-context: ""
   kind: Config
   preferences: {}
   users: []   

O membro kubeconfig do ConfigMap é um arquivo de configuração contendo somente as informações do cluster preenchidas. A informação chave sendo comunicada aqui está em certificate-authority-data. Isto poderá ser expandido no futuro.

A assinatura é feita utilizando-se assinatura JWS em modo "separado". Para validar a assinatura, o usuário deve codificar o conteúdo do kubeconfig de acordo com as regras do JWS (codificando em base64 e descartando qualquer = ao final). O conteúdo codificado e então usado para formar um JWS inteiro, inserindo-o entre os 2 pontos. Você pode verificar o JWS utilizando o esquema HS256 (HMAC-SHA256) com o token completo (por exemplo: 07401b.f395accd246ae52d) como o secret compartilhado. Usuários devem verificar que o algoritmo HS256 (que é um método de assinatura simétrica) está sendo utilizado.

Consulte a seção de detalhes de implementação do kubeadm para mais informações.

4 - Ferramentas de Configuração

4.1 - Kubeadm

O Kubeadm é uma ferramenta criada para fornecer o kubeadm init e o kubeadm join como "caminhos rápidos" de melhores práticas para criar clusters Kubernetes.

O kubeadm executa as ações necessárias para colocar um cluster minimamente viável em funcionamento, e foi projetado para se preocupar apenas com a inicialização e não com o provisionamento de máquinas. Da mesma forma, a instalação de vários complementos úteis, como o Kubernetes Dashboard, soluções de monitoramento e complementos específicos da nuvem, não está no escopo.

Em vez disso, esperamos que ferramentas de alto nível e mais personalizadas sejam construídas em cima do kubeadm e, idealmente, usando o kubeadm como base de todas as implantações torná mais fácil a criação de clusters em conformidade.

Como instalar

Para instalar o kubeadm, consulte o guia de instalação.

Próximos passos

• kubeadm init para inicializar um nó da camada de gerenciamento do Kubernetes
• kubeadm join para inicializar um nó worker do Kubernetes e associá-lo ao cluster
• kubeadm upgrade para atualizar um cluster Kubernetes para uma versão mais recente
• kubeadm config se você inicializou seu cluster usando o kubeadm v1.7.x ou inferior, para configurar seu cluster pelo kubeadm upgrade
• kubeadm token para gerenciar os tokens pelo kubeadm join
• kubeadm reset para reverter quaisquer alterações feitas, neste host, pelo kubeadm init ou kubeadm join
• kubeadm certs para gerenciar os certificados do Kubernetes
• kubeadm kubeconfig para gerenciar arquivos kubeconfig
• kubeadm version para exibir a versão do kubeadm
• kubeadm alpha para visualizar um conjunto de recursos disponibilizados para coletar feedback da comunidade

4.1.1 - kubeadm init

Este comando inicializa um nó da camada de gerenciamento do Kubernetes.

Rode este comando para configurar a camada de gerenciamento do Kubernetes

Sinopse

Rode este comando para configurar a camada de gerenciamento do Kubernetes

O comando "init" executa as fases abaixo:

preflight                    Efetua as verificações pré-execução
certs                        Geração de certificados
  /ca                          Gera a autoridade de certificação (CA) auto-assinada do Kubernetes para provisionamento de identidades para outros componentes do Kubernetes
  /apiserver                   Gera o certificado para o servidor da API do Kubernetes
  /apiserver-kubelet-client    Gera o certificado para o servidor da API se conectar ao Kubelet
  /front-proxy-ca              Gera a autoridade de certificação (CA) auto-assinada para provisionamento de identidades para o front proxy
  /front-proxy-client          Gera o certificado para o cliente do front proxy
  /etcd-ca                     Gera a autoridade de certificação (CA) auto-assinada para provisionamento de identidades para o etcd
  /etcd-server                 Gera o certificado para servir o etcd
  /etcd-peer                   Gera o certificado para comunicação entre nós do etcd
  /etcd-healthcheck-client     Gera o certificado para liveness probes fazerem a verificação de integridade do etcd
  /apiserver-etcd-client       Gera o certificado que o servidor da API utiliza para comunicar-se com o etcd
  /sa                          Gera uma chave privada para assinatura de tokens de conta de serviço, juntamente com sua chave pública
kubeconfig                   Gera todos os arquivos kubeconfig necessários para estabelecer a camada de gerenciamento e o arquivo kubeconfig de administração
  /admin                       Gera um arquivo kubeconfig para o administrador e o próprio kubeadm utilizarem
  /kubelet                     Gera um arquivo kubeconfig para o kubelet utilizar *somente* para fins de inicialização do cluster
  /controller-manager          Gera um arquivo kubeconfig para o gerenciador de controladores utilizar
  /scheduler                   Gera um arquivo kubeconfig para o escalonador do Kubernetes utilizar
kubelet-start                Escreve as configurações do kubelet e (re)inicializa o kubelet
control-plane                Gera todos os manifestos de Pods estáticos necessários para estabelecer a camada de gerenciamento
  /apiserver                   Gera o manifesto do Pod estático do kube-apiserver
  /controller-manager          Gera o manifesto do Pod estático do kube-controller-manager
  /scheduler                   Gera o manifesto do Pod estático do kube-scheduler
etcd                         Gera o manifesto do Pod estático para um etcd local
  /local                       Gera o manifesto do Pod estático para uma instância local e de nó único do etcd
upload-config                Sobe a configuração do kubeadm e do kubelet para um ConfigMap
  /kubeadm                     Sobe a configuração ClusterConfiguration do kubeadm para um ConfigMap
  /kubelet                     Sobe a configuração do kubelet para um ConfigMap
upload-certs                 Sobe os certificados para o kubeadm-certs
mark-control-plane           Marca um nó como parte da camada de gerenciamento
bootstrap-token              Gera tokens de autoinicialização utilizados para associar um nó a um cluster
kubelet-finalize             Atualiza configurações relevantes ao kubelet após a inicialização TLS
  /experimental-cert-rotation  Habilita rotação de certificados do cliente do kubelet
addon                        Instala os addons requeridos para passar nos testes de conformidade
  /coredns                     Instala o addon CoreDNS em um cluster Kubernetes
  /kube-proxy                  Instala o addon kube-proxy em um cluster Kubernetes

kubeadm init [flags]

Opções

Opções herdadas de comandos superiores

Fluxo do comando Init

O comando kubeadm init inicializa um nó da camada de gerenciamento do Kubernetes através da execução dos passos abaixo:

1. Roda uma série de verificações pré-execução para validar o estado do sistema antes de efetuar mudanças. Algumas verificações emitem apenas avisos, outras são consideradas erros e cancelam a execução do kubeadm até que o problema seja corrigido ou que o usuário especifique a opção --ignore-preflight-errors=<lista-de-erros-a-ignorar>.

2. Gera uma autoridade de certificação (CA) auto-assinada para criar identidades para cada um dos componentes do cluster. O usuário pode informar seu próprio certificado CA e/ou chave ao instalar estes arquivos no diretório de certificados configurado através da opção --cert-dir (por padrão, este diretório é /etc/kubernetes/pki). Os certificados do servidor da API terão entradas adicionais para nomes alternativos (subject alternative names, ou SANs) especificados através da opção --apiserver-cert-extra-sans. Estes argumentos serão modificados para caracteres minúsculos quando necessário.

3. Escreve arquivos kubeconfig adicionais no diretório /etc/kubernetes para o kubelet, para o gerenciador de controladores e para o escalonador utilizarem ao conectarem-se ao servidor da API, cada um com sua própria identidade, bem como um arquivo kubeconfig adicional para administração do cluster chamado admin.conf.

4. Gera manifestos de Pods estáticos para o servidor da API, para o gerenciador de controladores e para o escalonador. No caso de uma instância externa do etcd não ter sido providenciada, um manifesto de Pod estático adicional é gerado para o etcd.

   Manifestos de Pods estáticos são escritos no diretório /etc/kubernetes/manifests; o kubelet lê este diretório em busca de manifestos de Pods para criar na inicialização.

   Uma vez que os Pods da camada de gerenciamento estejam criados e rodando, a sequência de execução do comando kubeadm init pode continuar.

5. Aplica labels e taints ao nó da camada de gerenciamento de modo que cargas de trabalho adicionais não sejam escalonadas para executar neste nó.

6. Gera o token que nós adicionais podem utilizar para associarem-se a uma camada de gerenciamento no futuro. Opcionalmente, o usuário pode fornecer um token através da opção --token, conforme descrito na documentação do comando kubeadm token.

7. Prepara todas as configurações necessárias para permitir que nós se associem ao cluster utilizando os mecanismos de Tokens de Inicialização e Inicialização TLS:

   • Escreve um ConfigMap para disponibilizar toda a informação necessária para associar-se a um cluster e para configurar regras de controle de acesso baseada em funções (RBAC).

   • Permite o acesso dos tokens de inicialização à API de assinaturas CSR.

   • Configura a auto-aprovação de novas requisições CSR.

   Para mais informações, consulte kubeadm join.

8. Instala um servidor DNS (CoreDNS) e os componentes adicionais do kube-proxy através do servidor da API. A partir da versão 1.11 do Kubernetes, CoreDNS é o servidor DNS padrão. Mesmo que o servidor DNS seja instalado nessa etapa, o seu Pod não será escalonado até que um CNI seja instalado.

   Aviso:

   O uso do kube-dns com o kubeadm foi descontinuado na versão v1.18 e removido na versão v1.21 do Kubernetes.

Utilizando fases de inicialização com o kubeadm

O kubeadm permite que você crie um nó da camada de gerenciamento em fases utilizando o comando kubeadm init phase.

Para visualizar a lista ordenada de fases e subfases, você pode rodar o comando kubeadm init --help. A lista estará localizada no topo da ajuda e cada fase tem sua descrição listada juntamente com o comando. Perceba que ao rodar o comando kubeadm init todas as fases e subfases são executadas nesta ordem exata.

Algumas fases possuem flags específicas. Caso você deseje ver uma lista de todas as opções disponíveis, utilize a flag --help. Por exemplo:

sudo kubeadm init phase control-plane controller-manager --help

Você também pode utilizar a flag --help para ver uma lista de subfases de uma fase superior:

sudo kubeadm init phase control-plane --help

kubeadm init também expõe uma flag chamada --skip-phases que pode ser utilizada para pular a execução de certas fases. Esta flag aceita uma lista de nomes de fases. Os nomes de fases aceitos estão descritos na lista ordenada acima.

Um exemplo:

sudo kubeadm init phase control-plane all --config=configfile.yaml
sudo kubeadm init phase etcd local --config=configfile.yaml
# agora você pode modificar os manifestos da camada de gerenciamento e do etcd
sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml

O que este exemplo faz é escrever os manifestos da camada de gerenciamento e do etcd no diretório /etc/kubernetes/manifests, baseados na configuração descrita no arquivo configfile.yaml. Isto permite que você modifique os arquivos e então pule estas fases utilizando a opção --skip-phases. Ao chamar o último comando, você cria um nó da camada de gerenciamento com os manifestos personalizados.

Como alternativa, você pode também utilizar o campo skipPhases na configuração InitConfiguration.

Utilizando kubeadm init com um arquivo de configuração

É possível configurar o comando kubeadm init com um arquivo de configuração ao invés de argumentos de linha de comando, e algumas funcionalidades mais avançadas podem estar disponíveis apenas como opções do arquivo de configuração. Este arquivo é fornecido utilizando a opção --config e deve conter uma estrutura ClusterConfiguration e, opcionalmente, mais estruturas separadas por ---\n. Combinar a opção --config com outras opções de linha de comando pode não ser permitido em alguns casos.

A configuração padrão pode ser emitida utilizando o comando kubeadm config print.

Se a sua configuração não estiver utilizando a última versão, é recomendado que você migre utilizando o comando kubeadm config migrate.

Para mais informações sobre os campos e utilização da configuração, você pode consultar a página de referência da API.

Utilizando kubeadm init com feature gates

O kubeadm suporta um conjunto de feature gates que são exclusivos do kubeadm e podem ser utilizados somente durante a criação de um cluster com kubeadm init. Estas funcionalidades podem controlar o comportamento do cluster. Os feature gates são removidos assim que uma funcionalidade atinge a disponibilidade geral (general availability, ou GA).

Para informar um feature gate, você pode utilizar a opção --feature-gates do comando kubeadm init, ou pode adicioná-las no campo featureGates quando um arquivo de configuração é utilizado através da opção --config.

A utilização de feature gates dos componentes principais do Kubernetes com o kubeadm não é suportada. Ao invés disso, é possível enviá-los através da personalização de componentes com a API do kubeadm.

Lista dos feature gates:

Descrição dos feature gates:

PublicKeysECDSA

Pode ser utilizado para criar um cluster que utilize certificados ECDSA no lugar do algoritmo RSA padrão. A renovação dos certificados ECDSA existentes também é suportada utilizando o comando kubeadm certs renew, mas você não pode alternar entre os algoritmos RSA e ECDSA dinamicamente ou durante atualizações.

RootlessControlPlane

Quando habilitada esta opção, os componentes da camada de gerenciamento cuja instalação de Pods estáticos é controlada pelo kubeadm, como o kube-apiserver, kube-controller-manager, kube-scheduler e etcd, têm seus contêineres configurados para rodarem como usuários não-root. Se a opção não for habilitada, estes componentes são executados como root. Você pode alterar o valor deste feature gate antes de atualizar seu cluster para uma versão mais recente do Kubernetes.

UnversionedKubeletConfigMap

Esta opção controla o nome do ConfigMap onde o kubeadm armazena os dados de configuração do kubelet. Quando esta opção não for especificada ou estiver especificada com o valor true, o ConfigMap será nomeado kubelet-config. Caso esteja especificada com o valor false, o nome do ConfigMap incluirá as versões maior e menor do Kubernetes instalado (por exemplo, kubelet-config-1.35). O kubeadm garante que as regras de RBAC para leitura e escrita deste ConfigMap serão apropriadas para o valor escolhido. Quando o kubeadm cria este ConfigMap (durante a execução dos comandos kubeadm init ou kubeadm upgrade apply), o kubeadm irá respeitar o valor da opção UnversionedKubeletConfigMap. Quando tal ConfigMap for lido (durante a execução dos comandos kubeadm join, kubeadm reset, kubeadm upgrade...), o kubeadm tentará utilizar o nome do ConfigMap sem a versão primeiro. Se esta operação não for bem-sucedida, então o kubeadm irá utilizar o nome legado (versionado) para este ConfigMap.

Adicionando parâmetros do kube-proxy

Para informações sobre como utilizar parâmetros do kube-proxy na configuração do kubeadm, veja:

• referência do kube-proxy

Para informações sobre como habilitar o modo IPVS com o kubeadm, veja:

• IPVS

Informando opções personalizadas em componentes da camada de gerenciamento

Para informações sobre como passar as opções aos componentes da camada de gerenciamento, veja:

• opções da camada de gerenciamento

Executando o kubeadm sem uma conexão à internet

Para executar o kubeadm sem uma conexão à internet, você precisa baixar as imagens de contêiner requeridas pela camada de gerenciamento.

Você pode listar e baixar as imagens utilizando o subcomando kubeadm config images:

kubeadm config images list
kubeadm config images pull

Você pode passar a opção --config para os comandos acima através de um arquivo de configuração do kubeadm para controlar os campos kubernetesVersion e imageRepository.

Todas as imagens padrão hospedadas em registry.k8s.io que o kubeadm requer suportam múltiplas arquiteturas.

Utilizando imagens personalizadas

Por padrão, o kubeadm baixa imagens hospedadas no repositório de contêineres registry.k8s.io. Se a versão requisitada do Kubernetes é um rótulo de integração contínua (por exemplo, ci/latest), o repositório de contêineres gcr.io/k8s-staging-ci-images é utilizado.

Você pode sobrescrever este comportamento utilizando o kubeadm com um arquivo de configuração. Personalizações permitidas são:

• Fornecer um valor para o campo kubernetesVersion que afeta a versão das imagens.
• Fornecer um repositório de contêineres alternativo através do campo imageRepository para ser utilizado no lugar de registry.k8s.io.
• Fornecer um valor específico para os campos imageRepository e imageTag, correspondendo ao repositório de contêineres e tag a ser utilizada, para as imagens dos componentes etcd ou CoreDNS.

Caminhos de imagens do repositório de contêineres padrão registry.k8s.io podem diferir dos utilizados em repositórios de contêineres personalizados através do campo imageRepository devido a razões de retrocompatibilidade. Por exemplo, uma imagem pode ter um subcaminho em registry.k8s.io/subcaminho/imagem, mas quando utilizado um repositório de contêineres personalizado, o valor padrão será meu.repositoriopersonalizado.io/imagem.

Para garantir que você terá as imagens no seu repositório personalizado em caminhos que o kubeadm consiga consumir, você deve:

• Baixar as imagens dos caminhos padrão registry.k8s.io utilizando o comando kubeadm config images {list|pull}.
• Subir as imagens para os caminhos listados no resultado do comando kubeadm config images list --config=config.yaml, onde config.yaml contém o valor customizado do campo imageRepository, e/ou imageTag para os componentes etcd e CoreDNS.
• Utilizar o mesmo arquivo config.yaml quando executar o comando kubeadm init.

Imagens personalizadas para o sandbox (imagem pause)

Para configurar uma imagem personalizada para o sandbox, você precisará configurar o agente de execução de contêineres para utilizar a imagem. Verifique a documentação para o seu agente de execução de contêineres para mais informações sobre como modificar esta configuração; para alguns agentes de execução de contêiner você também encontrará informações no tópico Agentes de Execução de Contêineres.

Carregando certificados da camada de gerenciamento no cluster

Ao adicionar a opção --upload-certs ao comando kubeadm init você pode subir temporariamente certificados da camada de gerenciamento em um Secret no cluster. Este Secret expira automaticamente após 2 horas. Os certificados são encriptados utilizando uma chave de 32 bytes que pode ser especificada através da opção --certificate-key. A mesma chave pode ser utilizada para baixar certificados quando nós adicionais da camada de gerenciamento estão se associando ao cluster, utilizando as opções --control-plane e --certificate-key ao rodar kubeadm join.

O seguinte comando de fase pode ser usado para subir os certificados novamente após a sua expiração:

kubeadm init phase upload-certs --upload-certs --certificate-key=ALGUM_VALOR --config=ALGUM_ARQUIVO_YAML

Se a opção --certificate-key não for passada aos comandos kubeadm init e kubeadm init phase upload-certs, uma nova chave será gerada automaticamente.

O comando abaixo pode ser utilizado para gerar uma nova chave sob demanda:

kubeadm certs certificate-key

Gerenciamento de certificados com o kubeadm

Para informações detalhadas sobre gerenciamento de certificados com o kubeadm, consulte Gerenciamento de Certificados com o kubeadm. O documento inclui informações sobre a utilização de autoridades de certificação (CA) externas, certificados personalizados e renovação de certificados.

Gerenciando o arquivo drop-in do kubeadm para o kubelet

O pacote kubeadm é distribuído com um arquivo de configuração para rodar o kubelet utilizando systemd. Note que o kubeadm nunca altera este arquivo. Este arquivo drop-in é parte do pacote DEB/RPM do kubeadm.

Para mais informações, consulte Gerenciando o arquivo drop-in do kubeadm para o systemd.

Usando o kubeadm com agentes de execução CRI

Por padrão, o kubeadm tenta detectar seu agente de execução de contêineres. Para mais detalhes sobre esta detecção, consulte o guia de instalação CRI do kubeadm.

Configurando o nome do nó

Por padrão, o kubeadm gera um nome para o nó baseado no endereço da máquina. Você pode sobrescrever esta configuração utilizando a opção --node-name. Esta opção passa o valor apropriado para a opção --hostname-override do kubelet.

Note que sobrescrever o hostname de um nó pode interferir com provedores de nuvem.

Automatizando o kubeadm

Ao invés de copiar o token que você obteve do comando kubeadm init para cada nó, como descrito no tutorial básico do kubeadm, você pode paralelizar a distribuição do token para facilitar a automação. Para implementar esta automação, você precisa saber o endereço IP que o nó da camada de gerenciamento irá ter após a sua inicialização, ou utilizar um nome DNS ou um endereço de um balanceador de carga.

1. Gere um token. Este token deve ter a forma <string de 6 caracteres>.<string de 16 caracteres>. Mais especificamente, o token precisa ser compatível com a expressão regular: [a-z0-9]{6}\.[a-z0-9]{16}.

   O kubeadm pode gerar um token para você:

    kubeadm token generate
   

2. Inicialize o nó da camada de gerenciamento e os nós de carga de trabalho de forma concorrente com este token. Conforme os nós forem iniciando, eles deverão encontrar uns aos outros e formar o cluster. O mesmo argumento --token pode ser utilizado em ambos os comandos kubeadm init e kubeadm join.

3. O mesmo procedimento pode ser feito para a opção --certificate-key quando nós adicionais da camada de gerenciamento associarem-se ao cluster. A chave pode ser gerada utilizando:

   kubeadm certs certificate-key
   

Uma vez que o cluster esteja inicializado, você pode buscar as credenciais para a camada de gerenciamento no caminho /etc/kubernetes/admin.conf e utilizá-las para conectar-se ao cluster.

Note que este tipo de inicialização tem algumas garantias de segurança relaxadas pois ele não permite que o hash do CA raiz seja validado com a opção --discovery-token-ca-cert-hash (pois este hash não é gerado quando os nós são provisionados). Para detalhes, veja a documentação do comando kubeadm join.

Próximos passos

• kubeadm init phase para entender mais sobre as fases do comando kubeadm init
• kubeadm join para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster
• kubeadm upgrade para atualizar um cluster do Kubernetes para uma versão mais recente
• kubeadm reset para reverter quaisquer mudanças feitas neste host pelos comandos kubeadm init ou kubeadm join

4.1.2 - kubeadm join

Este comando inicializa um nó de processamento do Kubernetes e o associa ao cluster.

Rode este comando em qualquer máquina que você deseje adicionar a um cluster existente

Sinopse

Ao associar um novo nó a um cluster inicializado com kubeadm, temos que estabelecer a confiança bidirecional. Este processo é dividido entre a descoberta (em que o nó estabelece a confiança na camada de gerenciamento do Kubernetes) e a inicialização TLS (em que a camada de gerenciamento do Kubernetes estabelece a confiança no nó).

Existem duas principais formas de descoberta. A primeira delas é o uso de um token compartilhado, juntamente com o endereço IP do servidor da API. A segunda é o fornecimento de um arquivo - um subconjunto do arquivo kubeconfig padrão. O arquivo de descoberta/kubeconfig suporta autenticação por token, plugins de autenticação do client-go ("exec"), "tokenFile" e "authProvider". Este arquivo pode ser um arquivo local ou um arquivo baixado através de uma URL HTTPS. Os formatos são kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443, kubeadm join --discovery-file caminho/para/arquivo.conf, ou kubeadm join --discovery-file https://endereco/arquivo.conf. Somente um formato pode ser utilizado. Se os dados para a descoberta são carregados de uma URL, o protocolo HTTPS deve ser utilizado. Neste caso, o conjunto de CAs instalado no host é utilizado para verificar a conexão.

Se você utilizou um token compartilhado para descoberta, você deve também passar a opção --discovery-token-ca-cert-hash para validar a chave pública da autoridade de certificação raiz (CA) apresentada pela camada de gerenciamento do Kubernetes. O valor desta opção é especificado no formato "<tipo-de-hash>:<valor-codificado-em-hexadecimal>", onde o tipo de hash suportado é "sha256". O hash é calculado a partir dos bytes do objeto Subject Public Key Info (SPKI), como especificado pela RFC7469. Este valor fica disponível na saída do comando kubeadm init ou pode ser calculado utilizando ferramentas padronizadas. A opção --discovery-token-ca-cert-hash pode ser especificada múltiplas vezes para permitir informar mais que uma chave pública.

Se você não puder obter o hash da chave pública da autoridade de certificação de antemão, você pode passar a opção --discovery-token-unsafe-skip-ca-verification para desabilitar esta verificação. Esta opção enfraquece o modelo de segurança do kubeadm, já que outros nós podem potencialmente personificar a camada de gerenciamento do Kubernetes.

O mecanismo de inicialização TLS também é conduzido por um token compartilhado. Este token é utilizado para temporariamente autenticar-se com a camada de gerenciamento do Kubernetes para enviar uma requisição de assinatura de certificado (CSR) para um par de chaves criado localmente. Por padrão, o kubeadm irá configurar a camada de gerenciamento do Kubernetes para automaticamente aprovar estas requisições de assinatura. O token é enviado através da opção --tls-bootstrap-token abcdef.1234567890abcdef.

Frequentemente, o mesmo token é utilizado para ambas as partes. Neste caso, a opção --token pode ser utilizada ao invés de especificar cada token individualmente.

O comando join [api-server-endpoint] executa as seguintes fases:

preflight               Executa as verificações pré-execução
control-plane-prepare   Prepara a máquina para servir um nó da camada de gerenciamento
  /download-certs        [EXPERIMENTAL] Baixa certificados compartilhados entre nós da camada de gerenciamento do Secret kubeadm-certs
  /certs                 Gera os certificados para os novos componentes da camada de gerenciamento
  /kubeconfig            Gera o arquivo kubeconfig para os novos componentes da camada de gerenciamento
  /control-plane         Gera os manifestos para os novos componentes da camada de gerenciamento
kubelet-start          Escreve as configurações do kubelet, os certificados, e (re)inicia o kubelet
control-plane-join     Associa uma máquina como uma instância da camada de gerenciamento
  /etcd                  Adiciona como um novo membro do etcd local
  /update-status         Registra o novo nó da camada de gerenciamento no objeto ClusterStatus mantido no ConfigMap kubeadm-config (DESCONTINUADO)
  /mark-control-plane    Marca um nó como nó da camada de gerenciamento

kubeadm join [api-server-endpoint] [flags]

Opções

Opções herdadas dos comandos superiores

Fluxo do comando join

O comando kubeadm join inicializa um nó de processamento ou um nó da camada de gerenciamento e o adiciona ao cluster. Esta ação consiste nos seguintes passos para nós de processamento:

1. O kubeadm baixa as informações necessárias do cluster através servidor da API. Por padrão, o token de autoinicialização e o hash da chave da autoridade de certificação (CA) são utilizados para verificar a autenticidade dos dados baixados. O certificado raiz também pode ser descoberto diretamente através de um arquivo ou URL.

2. Uma vez que as informações do cluster são conhecidas, o kubelet pode começar o processo de inicialização TLS.

   A inicialização TLS utiliza o token compartilhado para autenticar temporariamente com o servidor da API do Kubernetes a fim de submeter uma requisição de assinatura de certificado (certificate signing request, ou CSR); por padrão, a camada de gerenciamento assina essa requisição CSR automaticamente.

3. Por fim, o kubeadm configura o kubelet local para conectar no servidor da API com a identidade definitiva atribuída ao nó.

Para nós da camada de gerenciamento, passos adicionais são executados:

1. O download de certificados compartilhados por todos os nós da camada de gerenciamento (quando explicitamente solicitado pelo usuário).

2. Geração de manifestos, certificados e arquivo kubeconfig para os componentes da camada de gerenciamento.

3. Adição de um novo membro local do etcd.

Utilizando fases de associação com o kubeadm

O kubeadm permite que você associe um nó a um cluster em fases utilizando kubeadm join phase.

Para visualizar a lista ordenada de fases e subfases disponíveis, você pode executar o comando kubeadm join --help. A lista estará localizada no topo da tela da ajuda e cada fase terá uma descrição ao lado. Note que ao chamar kubeadm join todas as fases e subfases serão executadas nesta ordem exata.

Algumas fases possuem opções únicas, portanto, se você desejar ver uma lista das opções disponíveis, adicione a flag --help. Por exemplo:

kubeadm join phase kubelet-start --help

De forma semelhante ao comando kubeadm init phase, kubeadm join phase permite que você ignore uma lista de fases utilizando a opção --skip-phases.

Por exemplo:

sudo kubeadm join --skip-phases=preflight --config=config.yaml

Alternativamente, você pode utilizar o campo skipPhases no manifesto JoinConfiguration.

Descobrindo em qual autoridade de certificação (CA) do cluster confiar

A descoberta do kubeadm tem diversas opções, cada uma com suas próprias contrapartidas de segurança. O método correto para o seu ambiente depende de como você aprovisiona seus nós e as expectativas de segurança que você tem a respeito da rede e ciclo de vida dos seus nós.

Descoberta baseada em token com fixação da autoridade de certificação (CA)

Este é o modo padrão do kubeadm. Neste modo, o kubeadm baixa a configuração do cluster (incluindo a CA raiz) e a valida, utilizando o token, além de verificar que a chave pública da CA raiz corresponda ao hash fornecido e que o certificado do servidor da API seja válido sob a CA raiz.

O hash da chave pública da CA tem o formato sha256:<hash_codificado_em_hexa>. Por padrão, o valor do hash é retornado no comando kubeadm join impresso ao final da execução de kubeadm init ou na saída do comando kubeadm token create --print-join-command. Este hash é gerado em um formato padronizado (veja a RFC7469) e pode também ser calculado com ferramentas de terceiros ou sistemas de provisionamento. Por exemplo, caso deseje utilizar a ferramenta de linha de comando do OpenSSL:

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

Exemplos de comandos kubeadm join:

Para nós de processamento:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443

Para nós da camada de gerenciamento:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef --control-plane 1.2.3.4:6443

Você também pode executar o comando join para um nó da camada de gerenciamento com a opção --certificate-key para copiar certificados para este nó, caso o comando kubeadm init tenha sido executado com a opção --upload-certs.

Vantagens:

• Permite à inicialização dos nós descobrir uma raiz de confiança para a camada de gerenciamento mesmo que outros nós de processamento ou a rede estejam comprometidos.

• É conveniente para ser executado manualmente pois toda a informação requerida cabe num único comando kubeadm join.

Desvantagens:

• O hash da autoridade de certificação normalmente não está disponível até que a camada de gerenciamento seja aprovisionada, o que pode tornar mais difícil a criação de ferramentas de aprovisionamento automatizadas que utilizem o kubeadm. Uma alternativa para evitar esta limitação é gerar sua autoridade de certificação de antemão.

Descoberta baseada em token sem fixação da autoridade de certificação (CA)

Este modo depende apenas do token simétrico para assinar (HMAC-SHA256) a informação de descoberta que estabelece a raiz de confiança para a camada de gerenciamento. Para utilizar este modo, os nós que estão se associando ao cluster devem ignorar a validação do hash da chave pública da autoridade de certificação, utilizando a opção --discovery-token-unsafe-skip-ca-verification. Você deve considerar o uso de um dos outros modos quando possível.

Exemplo de comando kubeadm join:

kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443

Vantagens:

• Ainda protege de muitos ataques a nível de rede.

• O token pode ser gerado de antemão e compartilhado com os nós da camada de gerenciamento e de processamento, que por sua vez podem inicializar-se em paralelo, sem coordenação. Isto permite que este modo seja utilizado em muitos cenários de aprovisionamento.

Desvantagens:

• Se um mau ator conseguir roubar um token de inicialização através de algum tipo de vulnerabilidade, este mau ator conseguirá utilizar o token (juntamente com acesso a nível de rede) para personificar um nó da camada de gerenciamento perante os outros nós de processamento. Esta contrapartida pode ou não ser aceitável no seu ambiente.

Descoberta baseada em arquivos ou HTTPS

Este modo fornece uma maneira alternativa de estabelecer uma raiz de confiança entre os nós da camada de gerenciamento e os nós de processamento. Considere utilizar este modo se você estiver construindo uma infraestrutura de aprovisionamento automático utilizando o kubeadm. O formato do arquivo de descoberta é um arquivo kubeconfig comum do Kubernetes.

Caso o arquivo de descoberta não contenha credenciais, o token de descoberta TLS será utilizado.

Exemplos de comandos kubeadm join:

• kubeadm join --discovery-file caminho/para/arquivo.conf (arquivo local)

• kubeadm join --discovery-file https://endereco/arquivo.conf (URL HTTPS remota)

Vantagens:

• Permite à inicialização dos nós descobrir uma raiz de confiança de forma segura para que a camada de gerenciamento utilize mesmo que a rede ou outros nós de processamento estejam comprometidos.

Desvantagens:

• Requer que você tenha uma forma de carregar a informação do nó da camada de gerenciamento para outros nós em inicialização. Se o arquivo de descoberta contém credenciais, você precisa mantê-lo secreto e transferi-lo através de um canal de comunicação seguro. Isto pode ser possível através do seu provedor de nuvem ou ferramenta de aprovisionamento.

Tornando sua instalação ainda mais segura

Os valores padrão de instalação do kubeadm podem não funcionar para todos os casos de uso. Esta seção documenta como tornar uma instalação mais segura, ao custo de usabilidade.

Desligando a auto-aprovação de certificados de cliente para nós

Por padrão, um auto-aprovador de requisições CSR está habilitado. Este auto-aprovador irá aprovar quaisquer requisições de certificado de cliente para um kubelet quando um token de autoinicialização for utilizado para autenticação. Se você não deseja que o cluster aprove automaticamente certificados de cliente para os kubelets, você pode desligar a auto-aprovação com o seguinte comando:

kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap

Após o desligamento da auto-aprovação, o comando kubeadm join irá aguardar até que o administrador do cluster aprove a requisição CSR:

1. Utilizando o comando kubeadm get csr, você verá que o CSR original está em estado pendente.

   kubectl get csr
   

   A saída é semelhante a:

   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   18s       system:bootstrap:878f07   Pending
   

2. O comando kubectl certificate approve permite ao administrador aprovar o CSR. Esta ação informa ao controlador de assinatura de certificados que este deve emitir um certificado para o requerente com os atributos requeridos no CSR.

   kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
   

   A saída é semelhante a:

   certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
   

3. Este comando muda o estado do objeto CSR para o estado ativo.

   kubectl get csr
   

   A saída é semelhante a:

   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   1m        system:bootstrap:878f07   Approved,Issued
   

Esta mudança força com que o fluxo do comando kubeadm join seja bem-sucedido somente quando o comando kubectl certificate approve for executado.

Desligando o acesso público ao ConfigMap cluster-info

Para que o fluxo de associação de um nó ao cluster seja possível utilizando somente um token como a única informação necessária para validação, um ConfigMap com alguns dados necessários para validação da identidade do nó da camada de gerenciamento é exposto publicamente por padrão. Embora nenhum dado deste ConfigMap seja privado, alguns usuários ainda podem preferir bloquear este acesso. Mudar este acesso bloqueia a habilidade de utilizar a opção --discovery-token do fluxo do comando kubeadm join. Para desabilitar este acesso:

• Obtenha o arquivo cluster-info do servidor da API:

kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.yaml

A saída é semelhante a:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: <ca-cert>
    server: https://<ip>:<port>
  name: ""
contexts: []
current-context: ""
preferences: {}
users: []

• Utilize o arquivo cluster-info.yaml como um argumento para o comando kubeadm join --discovery-file.

• Desligue o acesso público ao ConfigMap cluster-info:

kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo

Estes comandos devem ser executados após kubeadm init, mas antes de kubeadm join.

Utilizando kubeadm join com um arquivo de configuração

É possível configurar o comando kubeadm join apenas com um arquivo de configuração, em vez de utilizar opções de linha de comando, e algumas funcionalidades avançadas podem estar disponíveis somente como opções no arquivo de configuração. Este arquivo é passado através da opção --config e deve conter uma estrutura JoinConfiguration. A utilização da opção --config com outras opções da linha de comando pode não ser permitida em alguns casos.

A configuração padrão pode ser emitida utilizando o comando kubeadm config print.

Caso sua configuração não esteja utilizando a versão mais recente, é recomendado que você migre utilizando o comando kubeadm config migrate.

Para mais informações sobre os campos e utilização da configuração você pode consultar a referência da API.

Próximos passos

• kubeadm init para inicializar um nó da camada de gerenciamento do Kubernetes.
• kubeadm token para gerenciar tokens utilizados no comando kubeadm join.
• kubeadm reset para reverter quaisquer mudanças feitas nesta máquina pelos comandos kubeadm init ou kubeadm join.

4.1.3 - kubeadm upgrade

kubeadm upgrade é um comando amigável que envolve uma lógica de atualização complexa por trás de um comando, com suporte para planejar e executar de fato uma atualização.

Guia do kubeadm upgrade

As etapas para realizar uma atualização usando kubeadm estão descritas neste documento. Para versões mais antigas do kubeadm, consulte os conjuntos de documentação mais antigos do site Kubernetes.

Você pode usar kubeadm upgrade diff para ver as alterações que seriam aplicadas aos manifestos de Pod estático.

No Kubernetes v1.15.0 e posteriores, o kubeadm upgrade apply e kubeadm upgrade node também renovarão automaticamente os certificados gerenciados pelo kubeadm neste nó, incluindo aqueles armazenados nos arquivos do kubeconfig. É possível optar por não renovar usando a flag --certificate-renewal=false. Para mais detalhes sobre a renovação dos certificados, consulte a documentação de gerenciamento de certificados.

kubeadm upgrade plan

Verifique quais versões estão disponíveis para atualizar e verifique se o seu cluster atual é atualizável. Para pular a verificação da Internet, passe o parâmetro opcional [versão]

Sinopse

Verifique quais versões estão disponíveis para atualizar e verifique se o seu cluster atual é atualizável. Para pular a verificação da Internet, passe o parâmetro opcional [versão]

kubeadm upgrade plan [versão] [flags]

Opções

Opções herdadas de comandos superiores

kubeadm upgrade apply

Atualiza o cluster Kubernetes para uma versão específica

Sinopse

Atualiza o cluster Kubernetes para uma versão específica

kubeadm upgrade apply [versão]

Opções

Opções herdadas de comandos superiores

kubeadm upgrade diff

Mostra quais diferenças serão aplicadas aos manifestos dos Pods estáticos existentes. Veja também: kubeadm upgrade apply --dry-run

Sinopse

Mostra quais diferenças serão aplicadas aos manifestos dos Pods estáticos existentes. Veja também: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [versão] [flags]

Opções

Opções herdadas de comandos superiores

kubeadm upgrade node

Comando para atualização de um nó no cluster

Sinopse

Comando para atualização de um nó no cluster

O comando "node" executa as seguintes fases:

preflight       Executa as verificações de pré-atualização do nó
control-plane   Atualiza a instância da camada de gerenciamento implantada neste nó, se houver
kubelet-config  Atualiza a configuração do kubelet para este nó

kubeadm upgrade node [flags]

Opções

Opções herdadas de comandos superiores

Próximos passos

• kubeadm config se você inicializou seu cluster usando kubeadm v1.7.x ou inferior, para configurar seu cluster para kubeadm upgrade

4.1.4 - kubeadm config

Durante o kubeadm init, o kubeadm carrega o objeto ClusterConfiguration para o seu cluster em um ConfigMap chamado kubeadm-config no namespace do kube-system. Essa configuração é então lida durante kubeadm join, kubeadm reset e kubeadm upgrade.

Você pode usar o kubeadm config print para exibir a configuração estática padrão que o kubeadm usa para o kubeadm init e kubeadm join.

Para obter mais informações sobre init e join, navegue até Usando o kubeadm init com um arquivo de configuração ou Usando o kubeadm join com um arquivo de configuração.

Para obter mais informações sobre como usar a API de configuração do kubeadm, navegue até Personalizando componentes com a API do kubeadm..

Você pode usar o kubeadm config migrate para converter seus arquivos de configuração antigos que contêm uma versão obsoleta da API para uma versão mais recente e suportada da API.

kubeadm config images list e kubeadm config images pull podem ser usadas para listar e baixar as imagens que o kubeadm precisa.

kubeadm config print

Exibe configurações

Sinopse

Este comando exibe as configurações para subcomandos fornecidos. Para mais detalhes, consulte: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Opções

Opções herdadas do comando superior

kubeadm config print init-defaults

Exibe a configuração de inicialização padrão, que pode ser usada para 'kubeadm init'

Sinopse

Este comando exibe objetos, como a configuração de inicialização padrão que é usada para 'kubeadm init'.

Observe que os valores confidenciais, como os campos do Token Bootstrap, são substituídos por valores de exemplo como "abcdef.0123456789abcdef", a fim de passar na validação, mas não executar o cálculo real para criar um token.

kubeadm config print init-defaults [flags]

Opções

Opções herdadas do comando superior

kubeadm config print join-defaults

Exibe a configuração padrão do join, que pode ser usada para 'kubeadm join'

Sinopse

Este comando exibe objetos como a configuração padrão de join que é usada para 'kubeadm join'.

Observe que valores confidenciais, como os campos do Token Bootstrap, são substituídos por valores de exemplo como "abcdef.0123456789abcdef", a fim de passar na validação, mas não executar o cálculo real para criar um token.

kubeadm config print join-defaults [flags]

Opções

Opções herdadas do comando superior

kubeadm config migrate

Leia uma versão mais antiga dos tipos de API de configuração do kubeadm a partir de um arquivo e envie o objeto de configuração semelhante para a versão mais recente

Sinopse

Esse comando permite converter objetos de configuração de versões mais antigas para a versão mais recente suportada, localmente na ferramenta CLI sem nunca tocar em nada no cluster. Nesta versão do kubeadm, as seguintes versões da API são suportadas:

• Kubeadm.k8s.io/v1beta3

Além disso, o kubeadm só pode escrever a configuração da versão "kubeadm.k8s.io/v1beta3", mas pode ler os dois tipos. Portanto, independentemente da versão que você passar para o parâmetro --old-config , o objeto API será lido, desserializado, padronizado, convertido, validado e serializado novamente quando escrito no stdout ou --new-config, se especificado.

Em outras palavras, a saída deste comando é o que o kubeadm realmente leria internamente se você enviasse este arquivo para "kubeadm init"

kubeadm config migrate [flags]

Opções

Opções herdadas do comando superior

kubeadm config images list

Exibe uma lista de imagens que o kubeadm usará. O arquivo de configuração é usado caso quaisquer imagens ou repositórios de imagens sejam personalizados.

Sinopse

Exibe uma lista de imagens que o kubeadm usará. O arquivo de configuração é usado caso quaisquer imagens ou repositórios de imagens sejam personalizados.

kubeadm config images list [flags]

Opções

Opções herdadas do comando superior

kubeadm config images pull

Puxe imagens usadas pelo kubeadm

Sinopse

Baixa imagens usadas pelo kubeadm

kubeadm config images pull [flags]

Opções

Opções herdadas do comando superior

Próximos passos

• kubeadm upgrade para atualizar um cluster Kubernetes para uma versão mais recente

4.1.5 - kubeadm reset

Executa o melhor esforço para reverter as alterações feitas pelo kubeadm init ou kubeadm join.

Executa o melhor esforço para reverter as alterações feitas no host por 'kubeadm init' ou 'kubeadm join'

Sinopse

Executa o melhor esforço para reverter as alterações feitas no host por 'kubeadm init' ou 'kubeadm join'

O comando "reset" executa as seguintes fases:

preflight           Executa as verificações pré-execução do preflight.
remove-etcd-member  Remove um membro etcd local.
cleanup-node        Executa a limpeza do nó.

kubeadm reset [flags]

Opções

Opções herdadas do comando superior

Fluxo de execução do comando reset

O kubeadm reset é o responsável por limpar o sistema de arquivos local dos nós a partir dos arquivos que foram criados usando os comandos kubeadm init ou kubeadm join. O reset dos nós da camanda de gerenciamento também remove o etcd local do nó do cluster etcd.

O kubeadm reset phase pode ser usado para executar separadamente as fases do fluxo de trabalho acima. Para pular uma lista de fases você pode usar --skip-phases, que funciona de maneira semelhante aos executores de fases dos comandos kubeadm join e kubeadm init.

Limpeza do etcd externo

O kubeadm reset não excluirá nenhum dado do etcd se o etcd externo estiver em uso. Isso significa que, se você executar o kubeadm init novamente usando os mesmos etcd endpoints, verá o estado dos clusters anteriores.

Para limpar dados etcd, é recomendável que você use um cliente como etcdctl, tal como:

etcdctl del "" --prefix

Consulte a documentação do etcd para obter mais informações.

Próximos passos

• kubeadm init para inicializar um nó do plano de controle do Kubernetes
• kubeadm join para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster

4.1.6 - kubeadm token

Os Bootstrap tokens são usados para estabelecer uma relação de confiança bidirecional entre um nó que se junta ao cluster e um nó do plano de controle, conforme descrito na autenticação com tokens de inicialização.

O kubeadm init cria um token inicial com um TTL de 24 horas. Os comandos a seguir permitem que você gerencie esse token e também crie e gerencie os novos.

kubeadm token create

Crie tokens de inicialização no servidor

Sinopse

Este comando criará um token de inicialização. Você pode especificar os usos para este token, o "tempo de vida" e uma descrição amigável, que é opcional.

O [token] é o token real para gravar. Este deve ser um token aleatório gerado com segurança da forma "[a-z0-9]{6}.[a-z0-9]{16}". Se nenhum [token] for fornecido, o kubeadm gerará um token aleatório.

kubeadm token create [token]

Opções

Opções herdadas dos comandos superiores

kubeadm token delete

Excluir tokens de inicialização no servidor

Sinopse

Este comando excluirá uma lista de tokens de inicialização para você.

O [token-value] é um Token completo na forma "[a-z0-9]{6}.[a-z0-9]{16}" ou o ID do Token na forma "[a-z0-9]{6}" a ser excluído.

kubeadm token delete [token-value] ...

Opções

Opções herdadas dos comandos superiores

kubeadm token generate

Gere e exiba um token de inicialização, mas não o crie no servidor

Sinopse

Este comando exibirá um token de inicialização gerado aleatoriamente que pode ser usado com os comandos "init" e "join".

Você não precisa usar este comando para gerar um token. Você pode fazer isso sozinho, desde que esteja no formato "[a-z0-9]{6}.[a-z0-9]{16}". Este comando é fornecido por conveniência para gerar tokens no formato fornecido.

Você também pode usar "kubeadm init" sem especificar um token e ele gerará e exibirá um para você.

kubeadm token generate [flags]

Opções

Opções herdadas dos comandos superiores

kubeadm token list

Liste tokens de inicialização no servidor

Sinopse

Este comando listará todos os tokens de inicialização para você

kubeadm token list [flags]

Opções

Opções herdadas dos comandos superiores

Próximos passos

• kubeadm join para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster

4.1.7 - kubeadm version

Este comando exibe a versão do kubeadm.

Exibe a versão do kubeadm

Sinopse

Exibe a versão do kubeadm

kubeadm version [flags]

Opções

Opção herdada do comando superior

4.1.8 - kubeadm alpha

Atualmente, não há comandos experimentais sob o kubeadm alpha.

Próximos passos

• kubeadm init para inicializar um nó da camada de gerenciamento do Kubernetes
• kubeadm join para inicializar um nó worker do Kubernetes e associá-lo ao cluster
• kubeadm reset para reverter quaisquer alterações feitas neste host pelo kubeadm init ou kubeadm join

4.1.9 - kubeadm certs

O kubeadm certs fornece os utilitários para gerenciar os certificados. Para obter mais detalhes sobre como esses comandos podem ser usados, consulte Gerenciamento de Certificados com o kubeadm.

kubeadm certs

Um conjunto de utilitários para usar os certificados Kubernetes

• visão geral

kubeadm certs renew

Você pode renovar todos os certificados Kubernetes usando o subcomando all ou renová-los seletivamente. Para mais detalhes, consulte Manual de renovação do certificado.

• renew
• all
• admin.conf
• apiserver-etcd-client
• apiserver-kubelet-client
• apiserver
• controller-manager.conf
• etcd-healthcheck-client
• etcd-peer
• etcd-server
• front-proxy-client
• scheduler.conf

kubeadm certs renew [flags]

kubeadm certs renew all [flags]

kubeadm certs renew admin.conf [flags]

kubeadm certs renew apiserver-etcd-client [flags]

kubeadm certs renew apiserver-kubelet-client [flags]

kubeadm certs renew apiserver [flags]

kubeadm certs renew controller-manager.conf [flags]

kubeadm certs renew etcd-healthcheck-client [flags]

kubeadm certs renew etcd-peer [flags]

kubeadm certs renew etcd-server [flags]

kubeadm certs renew front-proxy-client [flags]

kubeadm certs renew scheduler.conf [flags]

kubeadm certs certificate-key

Este comando pode ser usado para gerar uma nova chave do certificado da camada de gerenciamento. A chave pode ser passada como --certificate-key to kubeadm init e kubeadm join para permitir uma cópia automática dos certificados ao unir nós adicionais a camada de gerenciamento.

• certificate-key

kubeadm certs certificate-key [flags]

kubeadm certs check-expiration

Este comando verifica a expiração dos certificados na PKI local gerenciada pelo kubeadm. Para mais detalhes, consulte Verificar a expiração do certificado.

• check-expiration

kubeadm certs check-expiration [flags]

kubeadm certs generate-csr

Este comando pode ser usado para gerar chaves e CSRs para todos os certificados da camada de gerenciamento e arquivos kubeconfig. O usuário pode então assinar os CSRs com uma autoridade de certificação de sua escolha.

• generate-csr

kubeadm certs generate-csr [flags]

  # O comando a seguir gera as chaves e CSRs para todos os certificados do plano de controle e arquivos kubeconfig: 
  kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

Próximos passos

• kubeadm init para inicializar um nó da camada de gerenciamento do Kubernetes
• kubeadm join para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster
• kubeadm reset para reverter quaisquer alterações feitas, neste host, pelo kubeadm init ou kubeadm join

4.1.10 - kubeadm kubeconfig

kubeadm kubeconfig fornece utilitários para gerenciar arquivos kubeconfig.

Para exemplos de uso do comando kubeadm kubeconfig user, consulte Gerando arquivos kubeconfig para usuários adicionais.

kubeadm kubeconfig

• visão geral

kubeadm kubeconfig user

Esse comando pode ser usado para gerar um arquivo kubeconfig para um usuário adicional.

• user

kubeadm kubeconfig user [flags]

  # Exibe um arquivo kubeconfig para um usuário adicional chamado foo usando um arquivo bar de configuração
  kubeadm kubeconfig user --client-name=foo --config=bar

4.1.11 - kubeadm upgrade phase

Na versão v1.15.0, o kubeadm introduziu suporte preliminar para as fases kubeadm upgrade node. Fases para outros subcomandos kubeadm upgrade, tal como apply, podem ser adicionadas nas seguintes versões.

kubeadm upgrade node phase

Usando essa fase, você pode optar por executar as etapas separadas da atualização de nós, sejam eles nós secundários da camada de gerenciamento ou nós de execução de cargas de trabalho. Observe que kubeadm upgrade apply ainda precisa ser chamado em um nó principal da camada de gerenciamento.

• phase
• preflight
• control-plane
• kubelet-config

kubeadm upgrade node phase preflight [flags]

kubeadm upgrade node phase control-plane [flags]

kubeadm upgrade node phase kubelet-config [flags]

Próximos passos

• kubeadm init para inicializar um nó da camada de gerenciamento do Kubernetes
• kubeadm join para inicializar um nó worker do Kubernetes e associá-lo ao cluster
• kubeadm reset para reverter quaisquer alterações feitas, neste host, pelo kubeadm init ou kubeadm join
• kubeadm upgrade para atualizar um cluster Kubernetes para uma versão mais recente
• kubeadm alpha para visualizar um conjunto de recursos disponibilizados para coletar feedback da comunidade

5 - Portas e protocolos

Quando o Kubernetes está sendo executado em um ambiente com uma rede mais restritiva, como por exemplo um data center on-premises com firewalls de rede físicos ou redes virtuais em nuvens públicas, é útil saber quais portas e protocolos são utilizados pelos componentes do Kubernetes.

Camada de gerenciamento

Embora as portas do etcd estejam inclusas na seção da Camada de gerenciamento, você também pode hospedar o seu próprio cluster etcd externamente ou em portas customizadas.

Nós de processamento

† Intervalo padrão de portas para os serviços NodePort.

Todas as portas padrão podem ser sobrescritas. Quando portas customizadas são utilizadas, essas portas precisam estar abertas, ao invés das mencionadas aqui.

Um exemplo comum é a porta do servidor da API, que as vezes é trocado para a porta 433. Com isso, a porta padrão é mantida e o servidor da API é colocado atrás de um balanceador de carga que escuta na porta 433 e faz o roteamento das requisições para o servidor da API na porta padrão.

6 - Visão Geral de Autorização

Aprenda mais sobre autorização no Kubernetes, incluindo detalhes sobre criação de políticas utilizando módulos de autorização suportados.

No Kubernetes, você deve estar autenticado (conectado) antes que sua requisição possa ser autorizada (permissão concedida para acesso). Para obter informações sobre autenticação, visite Controlando Acesso à API do Kubernetes.

O Kubernetes espera atributos que são comuns a requisições de APIs REST. Isto significa que autorização no Kubernetes funciona com sistemas de controle de acesso a nível de organizações ou de provedores de nuvem que possam lidar com outras APIs além das APIs do Kubernetes.

Determinar se uma requisição é permitida ou negada

O Kubernetes autoriza requisições de API utilizando o servidor de API. Ele avalia todos os atributos de uma requisição em relação a todas as políticas disponíveis e permite ou nega a requisição. Todas as partes de uma requisição de API deve ser permitidas por alguma política para que possa prosseguir. Isto significa que permissões são negadas por padrão.

(Embora o Kubernetes use o servidor de API, controles de acesso e políticas que dependem de campos específicos de tipos específicos de objetos são tratados pelos controladores de admissão.)

Quando múltiplos módulos de autorização são configurados, cada um será verificado em sequência. Se qualquer dos autorizadores aprovarem ou negarem uma requisição, a decisão é imediatamente retornada e nenhum outro autorizador é consultado. Se nenhum módulo de autorização tiver nenhuma opinião sobre requisição, então a requisição é negada. Uma negação retorna um código de status HTTP 403.

Revisão de atributos de sua requisição

O Kubernetes revisa somente os seguintes atributos de uma requisição de API:

• user - O string de user fornecido durante a autenticação.
• group - A lista de nomes de grupos aos quais o usuário autenticado pertence.
• extra - Um mapa de chaves de string arbitrárias para valores de string, fornecido pela camada de autenticação.
• API - Indica se a solicitação é para um recurso de API.
• Caminho da requisição - Caminho para diversos endpoints que não manipulam recursos, como /api ou /healthz.
• Verbo de requisição de API - Verbos da API como get, list, create, update, patch, watch, delete e deletecollection que são utilizados para solicitações de recursos. Para determinar o verbo de requisição para um endpoint de recurso de API , consulte Determine o verbo da requisição.
• Verbo de requisição HTTP - Métodos HTTP em letras minúsculas como get, post, put e delete que são utilizados para requisições que não são de recursos.
• Recurso - O identificador ou nome do recurso que está sendo acessado (somente para requisições de recursos) - para requisições de recursos usando os verbos get, update, patch e delete, deve-se fornecer o nome do recurso.
• Subrecurso - O sub-recurso que está sendo acessado (somente para solicitações de recursos).
• Namespace - O namespace do objeto que está sendo acessado (somente para solicitações de recursos com namespace).
• Grupo de API - O API Group sendo acessado (somente para requisições de recursos). Uma string vazia designa o Grupo de API core.

Determine o verbo da requisição

Requisições de não-recursos Requisições sem recursos de /api/v1/... ou /apis/<group>/<version>/... são considerados "requisições sem recursos" e usam o método HTTP em letras minúsculas da solicitação como o verbo. Por exemplo, uma solicitação GET para endpoints como /api ou /healthz usaria get como o verbo.

Requisições de recursos Para determinar o verbo de requisição para um endpoint de API de recurso, revise o verbo HTTP utilizado e se a requisição atua ou não em um recurso individual ou em uma coleção de recursos:

Às vezes, o Kubernetes verifica a autorização para permissões adicionais utilizando verbos especializados. Por exemplo:

• PodSecurityPolicy
  • Verbo use em recursos podsecuritypolicies no grupo policy de API.
• RBAC
  • Verbos bind e escalate em roles e recursos clusterroles no grupo rbac.authorization.k8s.io de API.
• Authentication
  • Verbo impersonate em users, groups, e serviceaccounts no grupo de API core, e o userextras no grupo authentication.k8s.io de API.

Modos de Autorização

O servidor da API Kubernetes pode autorizar uma solicitação usando um dos vários modos de autorização:

• Node - Um modo de autorização de finalidade especial que concede permissões a kubelets com base nos Pods que estão programados para execução. Para saber mais sobre como utilizar o modo de autorização do nó, consulte Node Authorization.
• ABAC - Attribute-based access control (ABAC), ou Controle de acesso baseado em atributos, define um paradigma de controle de acesso pelo qual os direitos de acesso são concedidos aos usuários por meio do uso de políticas que combinam atributos. As políticas podem usar qualquer tipo de atributo (atributos de usuário, atributos de recurso, objeto, atributos de ambiente, etc.). Para saber mais sobre como usar o modo ABAC, consulte ABAC Mode.
• RBAC - Role-based access control (RBAC), ou controle de acesso baseado em função, é um método de regular o acesso a recursos computacionais ou de rede com base nas funções de usuários individuais dentro de uma empresa. Nesse contexto, acesso é a capacidade de um usuário individual realizar uma tarefa específica, como visualizar, criar ou modificar um arquivo. Para saber mais sobre como usar o modo RBAC, consulte RBAC Mode
  • Quando especificado RBAC (Role-Based Access Control) usa o grupo de API rbac.authorization.k8s.io para orientar as decisões de autorização, permitindo que os administradores configurem dinamicamente as políticas de permissão por meio da API do Kubernetes.
  • Para habilitar o modo RBAC, inicie o servidor de API (apiserver) com a opção --authorization-mode=RBAC.
• Webhook - Um WebHook é um retorno de chamada HTTP: um HTTP POST que ocorre quando algo acontece; uma simples notificação de evento via HTTP POST. Um aplicativo da Web que implementa WebHooks postará uma mensagem em um URL quando um determinado evento ocorrer. Para saber mais sobre como usar o modo Webhook, consulte Webhook Mode.

Verificando acesso a API

kubectl fornece o subcomando auth can-i para consultar rapidamente a camada de autorização da API. O comando usa a API SelfSubjectAccessReview para determinar se o usuário atual pode executar uma determinada ação e funciona independentemente do modo de autorização utilizado.

# "can-i create" = "posso criar"
kubectl auth can-i create deployments --namespace dev

A saída é semelhante a esta:

yes

# "can-i create" = "posso criar"
kubectl auth can-i create deployments --namespace prod

A saída é semelhante a esta:

no

Os administradores podem combinar isso com personificação de usuário para determinar qual ação outros usuários podem executar.

# "can-i list" = "posso listar"

kubectl auth can-i list secrets --namespace dev --as dave

A saída é semelhante a esta:

no

Da mesma forma, para verificar se uma ServiceAccount chamada dev-sa no Namespace dev pode listar Pods no namespace target:

# "can-i list" = "posso listar"
kubectl auth can-i list pods \
	--namespace target \
	--as system:serviceaccount:dev:dev-sa

A saída é semelhante a esta:

yes

SelfSubjectAccessReview faz parte do grupo de API authorization.k8s.io, que expõe a autorização do servidor de API para serviços externos. Outros recursos neste grupo inclui:

• SubjectAccessReview - Revisão de acesso para qualquer usuário, não apenas o atual. Útil para delegar decisões de autorização para o servidor de API. Por exemplo, o kubelet e extensões de servidores de API utilizam disso para determinar o acesso do usuário às suas próprias APIs.

• LocalSubjectAccessReview - Similar a SubjectAccessReview, mas restrito a um namespace específico.

• SelfSubjectRulesReview - Uma revisão que retorna o conjunto de ações que um usuário pode executar em um namespace. Útil para usuários resumirem rapidamente seu próprio acesso ou para interfaces de usuário mostrarem ações.

Essas APIs podem ser consultadas criando recursos normais do Kubernetes, onde a resposta no campo status do objeto retornado é o resultado da consulta.

kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    verb: create
    namespace: dev
EOF

A SelfSubjectAccessReview gerada seria:

apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
  creationTimestamp: null
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    namespace: dev
    verb: create
status:
  allowed: true
  denied: false

Usando flags para seu módulo de autorização

Você deve incluir uma flag em sua política para indicar qual módulo de autorização suas políticas incluem:

As seguintes flags podem ser utilizadas:

• --authorization-mode=ABAC O modo de controle de acesso baseado em atributos (ABAC) permite configurar políticas usando arquivos locais.
• --authorization-mode=RBAC O modo de controle de acesso baseado em função (RBAC) permite que você crie e armazene políticas usando a API do Kubernetes.
• --authorization-mode=Webhook WebHook é um modo de retorno de chamada HTTP que permite gerenciar a autorização usando endpoint REST.
• --authorization-mode=Node A autorização de nó é um modo de autorização de propósito especial que autoriza especificamente requisições de API feitas por kubelets.
• --authorization-mode=AlwaysDeny Esta flag bloqueia todas as requisições. Utilize esta flag somente para testes.
• --authorization-mode=AlwaysAllow Esta flag permite todas as requisições. Utilize esta flag somente se não existam requisitos de autorização para as requisições de API.

Você pode escolher mais de um modulo de autorização. Módulos são verificados em ordem, então, um modulo anterior tem maior prioridade para permitir ou negar uma requisição.

Escalonamento de privilégios através da criação ou edição da cargas de trabalho

Usuários que podem criar ou editar pods em um namespace diretamente ou através de um controlador como, por exemplo, um operador, conseguiriam escalar seus próprios privilégios naquele namespace.

Caminhos para escalonamento

• Montagem de Secret arbitrários nesse namespace
  • Pode ser utilizado para acessar Secret destinados a outras cargas de trabalho
  • Pode ser utilizado para obter um token da conta de serviço com maior privilégio
• Uso de contas de serviço arbitrárias nesse namespace
  • Pode executar ações da API do Kubernetes como outra carga de trabalho (personificação)
  • Pode executar quaisquer ações privilegiadas que a conta de serviço tenha acesso
• Montagem de configmaps destinados a outras cargas de trabalho nesse namespace
  • Pode ser utilizado para obter informações destinadas a outras cargas de trabalho, como nomes de host de banco de dados.
• Montagem de volumes destinados a outras cargas de trabalho nesse namespace
  • Pode ser utilizado para obter informações destinadas a outras cargas de trabalho e alterá-las.

Próximos passos

• Para aprender mais sobre autenticação, visite Authentication in Controlando acesso a APIs do Kubernetes.
• Para aprender mais sobre Admission Control, visite Utilizando Admission Controllers.

7 - Problemas e Alertas de Segurança do Kubernetes

7.1 - Rastreador de Issue Kubernetes

Para reportar um problema de segurança, siga processo de divulgação de segurança do Kubernetes.

O trabalho no código do Kubernetes e os problemas de segurança podem ser encontrados usando issues do GitHub.

• Lista oficial de CVEs conhecidos (vulnerabilidades de segurança) que foram anunciados pelo comitê de resposta de segurança
• Questões relacionadas ao CVE

Anúncios relacionados à segurança são enviados para a lista de discussão kubernetes-security-announce@googlegroups.com.

7.2 - Feed Oficial de CVE

Esta é uma lista, mantida pela comunidade, de CVEs oficiais anunciadas pelo Comitê de Resposta de Segurança do Kubernetes. Veja Informações de Segurança e Divulgação do Kubernetes para mais detalhes.

O projeto Kubernetes publica um Feed JSON, que pode ser programaticamente acessado, de questões de segurança publicadas. Você pode acessá-lo executando o seguinte comando:

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json

Este feed é automaticamente atualizado, mas com um pequeno atraso perceptível (minutos a horas), desde o momento em que um CVE é anunciado até o momento em que é acessível neste feed.

A fonte deste feed é um conjunto de issues do GitHub, filtrado pelo rótulo controlado e restrito official-cve-feed. Os dados brutos são armazenados em um Google Cloud Bucket que é somente escrito por um pequeno número de membros confiáveis da Comunidade.

8 - Utilizando Autorização ABAC

O controle de acesso baseado em atributos (ABAC) define um paradigma de controle de acesso onde os direitos de acesso são concedidos aos usuários por meio do uso de políticas que combinam atributos.

Formato do arquivo de política

Especifique os parametros de inicialização --authorization-policy-file=NOME_DE_ALGUM_ARQUIVO e --authorization-mode=ABAC para habilitar o modo ABAC.

O formato do arquivo é de um objeto JSON por linha. Nele não deve haver lista ou mapa envolvente, apenas um mapa por linha.

Cada linha é um "objeto de política", onde cada objeto é um mapa com as seguintes propriedades:

• Propriedades de versionamento:
  • apiVersion, tipo string; os valores válidos são "abac.authorization.kubernetes.io/v1beta1". Permite controle de versão e conversão do formato da política.
  • kind, tipo string: os valores válidos são "Policy". Permite controle de versão e conversão do formato da política.
• spec definida para um mapa com as seguintes propriedades:
  • Propriedades de correspondência de sujeito:
    • user, tipo string; a string de usuário de --token-auth-file. Se você especificar user, ele deve corresponder ao nome do usuário autenticado.
    • group, tipo string; se você especificar group, ele deve corresponder a um dos grupos do usuário autenticado system:authenticated corresponde a todas as requisições autenticadas. system:unauthenticated corresponde a todas as requisições não autenticadas.
  • Propriedades de correspondência de recursos:
    • apiGroup, tipo string; um grupo de API.
      • Ex: apps, networking.k8s.io
      • Curinga: * corresponde a todos os grupos de API.
    • namespace, tipo string; um namespace.
      • Ex: kube-system
      • Curinga: * corresponde a todas as requisições de recursos.
    • resource, tipo string; um tipo de recurso
      • Ex: pods, deployments
      • Curinga: * corresponde a todas as requisições de recursos.
  • Propriedades sem correspondência de recursos:
    • nonResourcePath, tipo string; caminhos de solicitação sem recurso.
      • Ex: /version ou /apis
      • Curinga:
        • * corresponde a todas as requisições que não são de recursos.
        • /foo/* corresponde a todos os subcaminhos de /foo/.
  • readonly, tipo booleano. Quando verdadeiro, significa que a política de correspondência de recursos se aplica apenas às operações get, list e watch. Em caso de políticas sem correspondência de recursos se aplica apenas à operação get.

Algoritmo de Autorização

Uma requisição possui atributos que correspondem às propriedades de um objeto de política.

Quando uma requisição é recebida, os atributos são determinados. Atributos desconhecidos são definidos com o valor zero de seu tipo (por exemplo, string vazia, 0, falso).

Uma propriedade definida como "*" corresponderá a qualquer valor do atributo correspondente.

A tupla de atributos é verificada em relação a cada política do arquivo de política. Se pelo menos uma linha corresponder aos atributos da requisição, ela é então autorizada (mas pode falhar em validação posterior).

Para permitir que qualquer usuário autenticado faça algo, escreva uma política com a propriedade do grupo definida como "system:authenticated".

Para permitir que qualquer usuário não autenticado faça algo, escreva uma política com a propriedade do grupo definida como "system:unauthenticated".

Para permitir que um usuário faça qualquer coisa, escreva uma política com as propriedades apiGroup, namespace, resource e nonResourcePath definidas como "*".

Kubectl

O Kubectl usa os endpoints /api e /apis do servidor de API para descobrir os tipos de recursos servidos e valida objetos enviados para a API pelas operações criar/atualizar usando informações de esquema localizadas em /openapi/v2.

Ao utilizar a autorização ABAC, esses recursos especiais devem ser explicitamente expostos por meio da propriedade nonResourcePath em uma política (consulte exemplos abaixo):

• /api, /api/*, /apis e /apis/* para negociação de versão da API.
• /version para recuperar a versão do servidor via kubectl version.
• /swaggerapi/* para operações de criação/atualização.

Para inspecionar as chamadas HTTP envolvidas em uma operação kubectl específica, você pode aumentar a verbosidade:

kubectl --v=8 version

Exemplos

1. Alice pode fazer qualquer coisa em todos os recursos:

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
   

2. O Kubelet pode ler qualquer Pod:

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
   

3. O Kubelet pode ler e escrever eventos:

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
   

4. Bob pode ler Pods somente pertencentes ao namespace "projectCaribou":

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
   

5. Qualquer pessoa pode realizar requisições somente-leitura em todos os caminhos que não são de recursos:

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
   

Exemplo de arquivo completo

Uma rápida observação sobre contas de serviço

Cada conta de serviço tem um nome de usuário ABAC correspondente, e o nome de usuário dessa conta de serviço é gerado de acordo com a convenção de nomenclatura:

system:serviceaccount:<namespace>:<serviceaccountname>

A criação de um novo namespace leva à criação de uma nova conta de serviço no seguinte formato:

system:serviceaccount:<namespace>:default

Por exemplo, se você quiser conceder à conta de serviço padrão (no namespace kube-system) privilégio total à API usando ABAC, adicione esta linha ao seu arquivo de política:

{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}

O servidor de API precisará ser reiniciado para carregar as novas linhas da política.

9 - Ferramenta de linha de comando (kubectl)

Kubernetes fornece um ferramenta de linha de comando para se comunicar com a camada de gerenciamento de um cluster Kubernetes usando a API do Kubernetes.

Esta ferramenta é chamada kubectl.

Para configuração, kubectl procura por um arquivo chamado config no diretório $HOME/.kube. Você pode especificar outros arquivos kubeconfig definindo a variável de ambiente KUBECONFIG ou configurando a flag --kubeconfig.

Esta visão geral abrange a sintaxe do kubectl, descreve as operações de comando e fornece exemplos comuns. Para detalhes sobre cada comando, incluindo todas as opções e subcomandos suportados, consulte a documentação de referência do kubectl.

Para instruções de instalação, consulte Instalando kubectl; para um guia rápido, consulte a folha de dicas. Se você está acostumado a usar a ferramenta de linha de comando docker, kubectl para Usuários Docker explica alguns comandos equivalentes para Kubernetes.

Sintaxe

Use a seguinte sintaxe para executar comandos kubectl da janela do seu terminal:

kubectl [command] [TYPE] [NAME] [flags]

onde command, TYPE, NAME e flags são:

• command: Especifica a operação que você deseja executar em um ou mais recursos, por exemplo create, get, describe, delete.

• TYPE: Especifica o tipo de recurso. Tipos de recursos não diferenciam maiúsculas de minúsculas e você pode especificar as formas singular, plural ou abreviada. Por exemplo, os seguintes comandos produzem a mesma saída:

  kubectl get pod pod1
  kubectl get pods pod1
  kubectl get po pod1
  

• NAME: Especifica o nome do recurso. Nomes diferenciam maiúsculas de minúsculas. Se o nome for omitido, detalhes para todos os recursos são exibidos, por exemplo kubectl get pods.

  Ao realizar uma operação em vários recursos, você pode especificar cada recurso por tipo e nome ou especificar um ou mais arquivos:

  • Para especificar recursos por tipo e nome:

    • Para agrupar recursos se todos forem do mesmo tipo: TYPE1 name1 name2 name<#>.
      Exemplo: kubectl get pod example-pod1 example-pod2

    • Para especificar vários tipos de recursos individualmente: TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>.
      Exemplo: kubectl get pod/example-pod1 replicationcontroller/example-rc1

  • Para especificar recursos com um ou mais arquivos: -f file1 -f file2 -f file<#>

    • Use YAML em vez de JSON já que YAML tende a ser mais amigável ao usuário, especialmente para arquivos de configuração.
      Exemplo: kubectl get -f ./pod.yaml

• flags: Especifica flags opcionais. Por exemplo, você pode usar as flags -s ou --server para especificar o endereço e porta do servidor de API do Kubernetes.
  

Se você precisar de ajuda, execute kubectl help da janela do terminal.

Autenticação dentro do cluster e sobrescritas de namespace

Por padrão, kubectl primeiro determinará se está sendo executado dentro de um pod, ou seja, em um cluster. Ele começa verificando as variáveis de ambiente KUBERNETES_SERVICE_HOST e KUBERNETES_SERVICE_PORT e a existência de um arquivo de token de conta de serviço em /var/run/secrets/kubernetes.io/serviceaccount/token. Se todos os três forem encontrados, a autenticação dentro do cluster é assumida.

Para manter a retrocompatibilidade, se a variável de ambiente POD_NAMESPACE for definida durante a autenticação dentro do cluster, ela sobrescreverá o namespace padrão do token da conta de serviço. Quaisquer manifestos ou ferramentas que dependam do namespace padrão serão afetados por isso.

Variável de ambiente POD_NAMESPACE

Se a variável de ambiente POD_NAMESPACE for definida, operações de linha de comando em recursos com namespace usarão por padrão o valor da variável. Por exemplo, se a variável for definida como seattle, kubectl get pods retornaria pods no namespace seattle. Isso ocorre porque pods são um recurso com namespace, e nenhum namespace foi fornecido no comando. Revise a saída de kubectl api-resources para determinar se um recurso possui namespace.

O uso explícito de --namespace <value> sobrescreve este comportamento.

Como o kubectl lida com tokens de ServiceAccount

Se:

• há um arquivo de token de conta de serviço do Kubernetes montado em /var/run/secrets/kubernetes.io/serviceaccount/token, e
• a variável de ambiente KUBERNETES_SERVICE_HOST está definida, e
• a variável de ambiente KUBERNETES_SERVICE_PORT está definida, e
• você não especifica explicitamente um namespace na linha de comando do kubectl

então o kubectl assume que está sendo executado no seu cluster. A ferramenta kubectl procura o namespace daquela ServiceAccount (que é o mesmo namespace do Pod) e atua com esse namespace. Isso é diferente do que acontece fora de um cluster; quando o kubectl é executado fora de um cluster e você não especifica um namespace, o comando kubectl atua com o namespace definido para o contexto atual na sua configuração do cliente. Para alterar o namespace padrão para seu kubectl você pode usar o seguinte comando:

kubectl config set-context --current --namespace=<namespace-name>

Operações

A seguinte tabela inclui descrições curtas e a sintaxe geral para todas as operações do kubectl:

Para saber mais sobre operações de comando, consulte a documentação de referência do kubectl.

Tipos de recursos

A seguinte tabela inclui uma lista de todos os tipos de recursos suportados e seus pseudônimos (aliases) abreviados.

(Esta saída pode ser obtida de kubectl api-resources, e estava precisa a partir do Kubernetes 1.25.0)