HomePtNotíciaComo acessar a API do seu cluster Kubernetes de dentro de seus...

Como acessar a API do seu cluster Kubernetes de dentro de seus pods

- Advertisement -
- Advertisement -
- Advertisement -
- Advertisement -

[ad_1]

A API do Kubernetes é sua rota para inspecionar e gerenciar suas operações de cluster. Você pode consumir a API usando o Kubectl CLI, ferramentas como curlou as bibliotecas de integração oficiais para linguagens de programação populares.

A API também está disponível para aplicativos em seu cluster. Os pods do Kubernetes recebem acesso à API automaticamente e podem ser autenticados usando uma conta de serviço fornecida. Ele realiza interações consumindo as variáveis ​​de ambiente injetadas e arquivos de certificado para fazer conexões do cliente de sua escolha.

Por que acessar a API do Kubernetes dentro de pods?

Existem vários casos de uso para acesso à API no pod. Essa técnica permite que os aplicativos inspecionem dinamicamente seu ambiente, apliquem alterações do Kubernetes e coletem métricas do plano de controle que fornecem insights de desempenho.

Algumas organizações criam suas próprias ferramentas em torno do Kubernetes. Eles podem implementar um aplicativo especial no cluster que usa a API para expor funcionalidades adicionais. Operar de dentro do cluster pode ser mais seguro do que fazer chamadas de API de um script externo, pois você não precisa abrir seu ambiente ou compartilhar contas de serviço e tokens de autenticação.

Como usar as bibliotecas de cliente da API

O método mais fácil e recomendado de acessar a API do Kubernetes de um pod é usar uma biblioteca cliente. Opções totalmente suportadas estão disponíveis para C, .NET, Go, Haskell, Java, JavaScript, Perl, Python e Ruby. Existem soluções equivalentes mantidas pela comunidade para a maioria das outras linguagens de programação populares.

As bibliotecas de cliente têm suporte integrado para descobrir o ambiente de cluster no qual estão em execução. Cada implementação fornece uma função que você pode chamar que configurará a biblioteca para se conectar ao servidor de API correto.

Este é um exemplo de como listar os pods em seu cluster em um aplicativo Python:

from kubernetes import client, config
 
config.load_incluster_config()
 
api = client.CoreV1Api()
 
# Perform necessary API interactions
# pods = api.list_pod_for_all_namespaces()

Essa abordagem é fácil de trabalhar e não requer configuração manual. No entanto, às vezes você não poderá usar uma biblioteca cliente. Nesses casos, ainda é possível acessar manualmente a API usando a conta de serviço fornecida pelo Kubernetes.

Como realizar interações manuais de API

Para chamar a API, você precisa saber duas coisas: o nome do host no cluster ao qual você está exposto e o token da conta de serviço que autenticará seu pod.

O nome do host da API é sempre kubernetes.default.svc. O provedor de DNS do Kubernetes resolverá esse nome para o servidor da API do plano de controle. Alternativamente, você pode usar o $KUBERNETES_SERVICE_HOST variável de ambiente para descobrir o endereço IP do servidor de API:

$ echo $KUBERNETES_SERVICE_HOST
10.96.0.1

A API está disponível apenas por HTTPS. Você pode encontrar o arquivo de autoridade de certificação para seu cluster em /var/run/secrets/kubernetes.io/serviceaccount/ca.crt dentro do seu pod. O Kubernetes deposita isso no sistema de arquivos toda vez que um novo contêiner é criado.

Você precisará se autenticar para realizar qualquer coisa útil com a API. O Kubernetes cria uma nova conta de serviço para cada Pod e fornece seu token em /var/run/secrets/kubernetes.io/serviceaccount/token. Isso deve ser incluído em cada solicitação HTTP como um token de portador no Authorization cabeçalho.

Juntando tudo, aqui está um exemplo de como fazer uma solicitação básica de API do Kubernetes no Pod usando curl:

$ curl 
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
  https://kubernetes.default.svc/api
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.49.2:8443"
    }
  ]

O servidor Kubernetes respondeu com as versões de API disponíveis. Isso confirma que uma conexão bem-sucedida foi feita usando o kubernetes.default.svc nome do host e conta de serviço fornecidos.

Gerenciamento de RBAC

Mesmo se uma solicitação de API for bem-sucedida, a maioria das outras estará fora dos limites se o RBAC estiver habilitado para seu cluster. As contas de serviço recém-criadas não recebem funções automaticamente, portanto, seu pod não poderá solicitar endpoints de API protegidos.

Você pode resolver isso criando seus próprios objetos de função e vinculando-os à conta de serviço fornecida aos seus pods. Primeiro crie uma nova função:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: demo-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

Aplique-o ao seu cluster com Kubectl:

$ kubectl apply -f role.yaml

Em seguida, vincule o papel à conta de serviço:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: demo-role-binding
subjects:
  - kind: ServiceAccount
    name: default
    apiGroup: ""
roleRef:
  kind: Role
  name: demo-role
  apiGroup: ""

a default a conta de serviço é selecionada como o assunto da vinculação de função. Os pods são sempre provisionados com essa conta de serviço, com escopo para o namespace em que foram criados. Neste exemplo, o default o namespace é usado, mas isso precisa ser alterado nos objetos Role e RoleBinding se seu pod existir em um namespace diferente.

Adicione RoleBinding ao seu cluster:

$ kubectl apply -f role-binding.yaml

Seus Pods agora poderão obter e listar outros Itens de Pod no default namespaced Você pode verificar isso fazendo uma solicitação de API para o endpoint de pods com namespace:

$ curl 
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
  https://kubernetes.default.svc/api/v1/namespaces/default/pods
{
  "kind": "PodList",
  "apiVersion": "v1"
  ...
}

Os pods podem identificar seu próprio namespace lendo o /var/run/secrets/kubernetes.io/serviceaccount/namespace processos:

$ cat /var/run/secrets/kubernetes.io/serviceaccount/namespace
default

Isso fornece um método conveniente de interpolar o namespace ativo em URLs de endpoint:

$ curl 
  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
  https://kubernetes.default.svc/api/v1/namespaces/$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)/pods
{
  "kind": "PodList",
  "apiVersion": "v1"
  ...
}

Escolha uma conta de serviço diferente

O Kubernetes fornece automaticamente aos pods o default conta de serviço em seu namespace. Opcionalmente, você pode injetar uma conta de serviço diferente definindo o spec.serviceAccountName campo em seus pods:

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  serviceAccountName: demo-sa

Neste exemplo, o pod será autenticado como o demo-sa simbólico. Você pode criar essa conta de serviço manualmente e vinculá-la às funções necessárias.

$ kubernetes create serviceaccount demo-sa

A conta de serviço deve existir no mesmo namespace que o pod.

Cancelando a montagem da conta de serviço

A injeção automática de contas de serviço nem sempre é desejável. Pode ser um risco de segurança, pois um Pod comprometido bem-sucedido oferece acesso imediato à API do seu cluster Kubernetes. Você pode desabilitar montagens de token de conta de serviço com o spec.automountServiceAccountToken Campo de manifesto do pod:

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  automountServiceAccountToken: false

O Kubernetes não injetará o /var/run/secrets/kubernetes.io/serviceaccount/token processos. Isso impedirá que o pod seja autenticado na API do Kubernetes, a menos que você forneça as credenciais manualmente usando um método diferente. Esse campo também é compatível com objetos de conta de serviço, tornando-os inelegíveis para montagem automática em qualquer pod.

Se você usar a montagem de conta de serviço, configure as políticas RBAC apropriadas para restringir o token aos casos de uso pretendidos. Prevenir o acesso altamente privilegiado diminuirá o risco de danos caso um invasor obtenha acesso ao seu Pod.

Resumo

Acessar o servidor da API Kubernetes de dentro de seu cluster permite que aplicativos em execução inspecionem e modifiquem cargas de trabalho vizinhas. Você pode adicionar recursos adicionais sem abrir seu cluster para acesso externo à API.

As bibliotecas de cliente oficiais facilitam a instalação e a execução, se forem adequadas para o seu caso de uso. Em outras situações, você precisará fazer solicitações manualmente para https://kubernetes.default.svc, fornecendo o arquivo de autoridade de certificação e o token da conta de serviço que o Kubernetes injeta em seus contêineres de pod. Independentemente de qual abordagem você usa, a conta de serviço deve ser configurada corretamente com associações de função RBAC para que o pod tenha permissão para executar as ações pretendidas.

[ad_2]

- Advertisement -
- Advertisement -
Stay Connected
16,985FansLike
2,458FollowersFollow
61,453SubscribersSubscribe
Must Read
- Advertisement -
Related News
- Advertisement -