Doctor AI · Documentação

Análise de postura OKD/OCP governada em cada etapa.

O Doctor AI conecta-se a clusters OpenShift e OKD via acesso read-only à API, escaneia a postura de workloads contra policy packs e encaminha cada finding pelo modelo de governança. Nenhuma mutação sem registro de aprovação. Nenhuma recomendação sem trilha de auditoria.

Princípios Operacionais
Acesso Somente-Leitura
Todas as operações de cluster usam a API REST do Kubernetes/OpenShift com um token de service account com escopo mínimo. Nenhuma escrita no cluster.
Findings Integrados à Governança
Findings críticos bloqueam automaticamente o governance gate para o ativo vinculado até que sejam resolvidos ou uma exceção seja aprovada.
Credenciais Criptografadas
Tokens de service account e kubeconfigs são criptografados em repouso usando a chave da aplicação. Nunca são expostos após o cadastro.
Trilha de Auditoria Completa
Cada scan, finding, exceção e aprovação de remediação é registrado com timestamp, usuário e contexto de organização.
Registro de Cluster

Um registro de cluster é a âncora para todas as operações do Doctor AI. Cadastre uma vez, teste a conectividade, configure o escopo de namespace e inicie os scans.

Campos obrigatórios

  • Nome do Cluster — identificador único dentro do tenant.
  • Plataforma — OCP (Red Hat OpenShift) ou OKD (comunidade).
  • URL da API Kubernetes — ex: https://api.cluster.example.com:6443
  • Modo de Conexão — service-account-token, kubeconfig ou in-cluster.
  • Bearer Token ou Kubeconfig — credencial da service account somente-leitura.

Opcional mas recomendado

  • URL do Web Console — habilita links diretos nos findings e relatórios.
  • Certificado CA Customizado — necessário para certificados TLS auto-assinados.
  • Escopo de Namespace — limita avaliação de governança a namespaces específicos.
  • Agenda de Sync — expressão cron para coleta automática de postura.
  • Environment — development, staging, production ou DR.
Modos de Conexão
Service Account Token
Recomendado
Mais granular e auditável. A service account é criada no cluster com permissões mínimas de leitura.

Setup

  1. Crie a service account no cluster
  2. oc create sa tainux-doctor -n tainux-system
  3. Atribua cluster-reader role
  4. oc adm policy add-cluster-role-to-user cluster-reader -z tainux-doctor -n tainux-system
  5. Extraia o token e cole no campo Bearer Token
Kubeconfig
Flexível
Útil quando a autenticação do cluster já está configurada no kubeconfig — ideal para múltiplos clusters com autenticação OIDC.

Setup

  1. Obtenha o kubeconfig do cluster
  2. oc config view --minify --flatten > cluster.kubeconfig
  3. Cole o conteúdo YAML no campo Kubeconfig
  4. Defina o contexto correto se o arquivo contiver múltiplos clusters
In-Cluster
Self-hosted
Quando o TAINUX está rodando dentro do próprio cluster. Usa a service account do Pod automaticamente, sem precisar de credenciais externas.

Setup

  1. Deploy o TAINUX no cluster alvo
  2. Atribua cluster-reader à service account do Pod
  3. Selecione "In-Cluster" no modo de conexão
  4. Nenhuma credencial adicional necessária
Pipeline de Scan
1 Conectividade

Testa o endpoint da API, valida TLS e detecta a versão Kubernetes/OpenShift. Mede latência e registra o resultado.

2 Coleta

Lê /api/v1/nodes, /api/v1/namespaces, /api/v1/pods e recursos adicionais com filtro por namespace configurado. Tudo somente-leitura.

3 Análise

O Claude AI avalia os dados coletados contra os policy packs ativos. Classifica findings por severidade (critical, high, medium, low, info).

4 Publicação

Findings são gravados com timestamp e vinculados ao ativo de governança. Findings críticos atualizam o governance gate automaticamente.

Policy Pack Themes
Segurança de Workload
  • Containers sem root
  • Resource limits definidos
  • Security contexts configurados
  • Probes de liveness e readiness
  • ImagePullPolicy Always
Configuração de Rede
  • Network policies presentes
  • Serviços sem exposição desnecessária
  • Ingress com TLS
  • Pods sem hostNetwork
  • Namespaces isolados
Conformidade de Recursos
  • Namespaces com LimitRange
  • ResourceQuota configurada
  • Labels obrigatórias presentes
  • Annotations de contato
  • Anotações de custos
Postura de RBAC
  • ClusterRoles sem wildcard
  • ServiceAccounts com escopo mínimo
  • Bindings auditadas
  • Sem cluster-admin desnecessário
  • Default SA sem permissões extras
TLS e Rede
Certificados CA Auto-Assinados
A maioria dos clusters OKD/OCP on-premise usa CA auto-assinada ou interna. Forneça o certificado CA em PEM no campo Certificado CA Customizado.
oc get secret -n openshift-ingress router-certs-default -o jsonpath='{.data.tls\.crt}' | base64 -d > ca.pem
Ambientes com Proxy
Quando o servidor TAINUX não consegue alcançar a API do cluster diretamente, forneça a URL completa do proxy (ex: http://proxy.internal:3128) no campo Proxy URL.
A opção Skip TLS Verify está disponível apenas para ambientes de desenvolvimento e teste — nunca habilite em clusters de produção.
Para registrar um cluster, acesse Doctor AI → Clusters → Registrar Cluster dentro da plataforma. Para suporte, acesse tainux.io ou envie e-mail para suporte@tainux.io.