Credenciais necessárias para descoberta Kubernetes com o OneSDK

10 min

A integração do OneSDK com o Kubernetes oferece uma maneira poderosa e flexível de consultar e analisar dados do seu cluster usando SQL. Ao configurar um arquivo kubeconfig personalizado com as credenciais de um ServiceAccount e as informações do cluster, o OneSDK pode se conectar diretamente à API do Kubernetes, permitindo que você execute consultas complexas sobre pods, nós, namespaces, deployments e outros recursos, transformando a gestão e a auditoria do seu ambiente Kubernetes em uma experiência baseada em dados e familiar para quem já trabalha com bancos de dados.

O que você precisa preparar no Kubernetes

Você precisará criar três coisas:

Um ClusterRole com permissões de leitura
Um ServiceAccount
E um ClusterRoleBinding ligando os dois

Em seguida, precisa obter o token desse ServiceAccount e a URL do servidor de API do cluster.

1) Defina as permissões mínimas (RBAC)

Crie um ClusterRole que dê apenas get e list nos recursos que o Discovery lê. Abaixo fornecemos um YAML “amplo” por padrão (get/list em “tudo”), mas é recomendável restringir aos grupos/recursos necessários para o seu ambiente.

# k8s-onesdk-discovery-rbac.yaml  
apiVersion: rbac.authorization.k8s.io/v1  
kind: ClusterRole  
metadata:  
  name: onesdk-discovery-readonly  
rules:  
  # Core API group ("")  
  - apiGroups: [""]  
    resources:  
      - nodes  
      - pods  
      - namespaces  
      - services  
      - endpoints  
      - replicationcontrollers  
      - persistentvolumes  
      - persistentvolumeclaims  
      - configmaps  
      - secrets  
    verbs: ["get", "list", "watch"]  
  # Apps  
  - apiGroups: ["apps"]  
    resources:  
      - deployments  
      - daemonsets  
      - statefulsets  
      - replicasets  
    verbs: ["get", "list", "watch"]  
  # Batch  
  - apiGroups: ["batch"]  
    resources:  
      - jobs  
      - cronjobs  
    verbs: ["get", "list", "watch"]  
  # Networking  
  - apiGroups: ["networking.k8s.io"]  
    resources:  
      - ingresses  
      - networkpolicies  
    verbs: ["get", "list", "watch"]  
  # Storage  
  - apiGroups: ["storage.k8s.io"]  
    resources:  
      - storageclasses  
      - csinodes  
      - volumeattachments  
    verbs: ["get", "list", "watch"]  
  # Node metrics/metrics-server (se aplicável)  
  - apiGroups: ["metrics.k8s.io"]  
    resources:  
      - nodes  
      - pods  
    verbs: ["get", "list", "watch"]  
---  
apiVersion: v1  
kind: ServiceAccount  
metadata:  
  name: onesdk-discovery  
  namespace: default  
---  
apiVersion: rbac.authorization.k8s.io/v1  
kind: ClusterRoleBinding  
metadata:  
  name: onesdk-discovery-readonly-binding  
roleRef:  
  apiGroup: rbac.authorization.k8s.io  
  kind: ClusterRole  
  name: onesdk-discovery-readonly  
subjects:  
  - kind: ServiceAccount  
    name: onesdk-discovery  
    namespace: default

Ajuste a lista de recursos a partir do que você realmente quer expor. Se sua organização exigir, remova secrets do escopo, ou substitua por regras mais restritas. Se você usa um namespace padrão diferente para o ServiceAccount, mude o campo namespace em ServiceAccount e subjects.

Para aplicar, rode kubectl apply -f k8s-onesdk-discovery-rbac.yaml.

2) Obtenha o token do ServiceAccount

Em clusters modernos (Kubernetes 1.24+), os tokens não são mais secretos persistentes por padrão. Você pode criar um Secret de token legível para uso “fora do cluster”.

Para criar um Secret do tipo service-account-token:

apiVersion: v1  
kind: Secret  
metadata:  
  name: onesdk-discovery-token  
  namespace: default  
  annotations:  
    kubernetes.io/service-account.name: onesdk-discovery  
type: kubernetes.io/service-account-token

Aplicar e depois descrever para obter o token:

kubectl apply -f onesdk-discovery-token.yaml  
kubectl -n default describe secret onesdk-discovery-token

No output, copie o valor do campo token. Se precisar do CA do cluster para validação TLS, copie também o ca.crt.

Dica para EKS/GKE/AKS: em EKS e GKE, o create token funciona; em AKS, dependendo da versão, você pode preferir o Secret. Sempre verifique as políticas do seu provedor e versão do cluster.

3) Descubra a URL do servidor da API

Execute kubectl cluster-info e copie a URL “Kubernetes control plane is running at ...”, por exemplo:

kubectl cluster-info 
# Kubernetes control plane is running at https://ABCDEFG...eks.amazonaws.com

Essa URL é a que você configurará no OneSDK como endpoint do provedor de API. Se estiver atrás de um proxy corporativo ou se exigir whitelist de IPs/origens, assegure que o OneSDK tenha conectividade HTTPS direta até essa URL.

4) Monte a estrutura do kubeconfig

apiVersion: v1  
kind: Config  
clusters:  
- cluster:  
    certificate-authority-data: <BASE64_CA_CERT>  
    server: https://ABCDEFG...eks.amazonaws.com  
  name: onesdk-discovery-cluster  
contexts:  
- context:  
    cluster: onesdk-discovery-cluster  
    user: onesdk-discovery-user  
  name: onesdk-discovery-context  
current-context: onesdk-discovery-context  
users:  
- name: onesdk-discovery-user  
  user:  
    token: <SEU_TOKEN_JWT>

Como obter cada componente:

1) Server URL (já tem):

kubectl cluster-info
# Use a URL do "Kubernetes control plane is running at..."

2) Certificate Authority (CA):

# Se usando Secret do token:
kubectl -n default get secret onesdk-discovery-token -o jsonpath='{.data.ca\.crt}'
  
# Ou diretamente do kubeconfig atual:
kubectl config view --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}'

3) Token (já tem do passo anterior):

# Token temporário:
kubectl -n default create token onesdk-discovery

# Ou do Secret:
kubectl -n default get secret onesdk-discovery-token -o jsonpath='{.data.token}' | base64 -d

Script para gerar o kubeconfig automaticamente:

#!/bin/bash  
  
# Configurações  
NAMESPACE="default"  
SERVICE_ACCOUNT="onesdk-discovery"  
CLUSTER_NAME="onesdk-discovery-cluster"  
CONTEXT_NAME="onesdk-discovery-context"  
USER_NAME="onesdk-discovery-user"  
KUBECONFIG_FILE="./onesdk-kubeconfig.yaml"  
  
# Obter informações do cluster  
SERVER_URL=$(kubectl cluster-info | grep "Kubernetes control plane" | awk '{print $6}')  
CA_DATA=$(kubectl config view --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}')  
  
# Obter token (tenta método moderno primeiro)  
TOKEN=$(kubectl -n $NAMESPACE create token $SERVICE_ACCOUNT 2>/dev/null)  
if [ -z "$TOKEN" ]; then  
    echo "Método create token falhou, tentando via Secret..."  
    # Criar Secret se não existir  
    kubectl apply -f - <<EOF  
apiVersion: v1  
kind: Secret  
metadata:  
  name: ${SERVICE_ACCOUNT}-token  
  namespace: ${NAMESPACE}  
  annotations:  
    kubernetes.io/service-account.name: ${SERVICE_ACCOUNT}  
type: kubernetes.io/service-account-token  
EOF  
      
    # Aguardar o token ser criado  
    sleep 5  
    TOKEN=$(kubectl -n $NAMESPACE get secret ${SERVICE_ACCOUNT}-token -o jsonpath='{.data.token}' | base64 -d)  
fi  
  
# Gerar kubeconfig  
cat > $KUBECONFIG_FILE <<EOF  
apiVersion: v1  
kind: Config  
clusters:  
- cluster:  
    certificate-authority-data: ${CA_DATA}  
    server: ${SERVER_URL}  
  name: ${CLUSTER_NAME}  
contexts:  
- context:  
    cluster: ${CLUSTER_NAME}  
    user: ${USER_NAME}  
  name: ${CONTEXT_NAME}  
current-context: ${CONTEXT_NAME}  
users:  
- name: ${USER_NAME}  
  user:  
    token: ${TOKEN}  
EOF  
  
echo "Kubeconfig criado em: $KUBECONFIG_FILE"  
echo "Para testar: kubectl --kubeconfig=$KUBECONFIG_FILE get nodes"