Infraestrutura de IA Agentiva: O que é Necessário para Fazer Isso com Segurança

Pipeline & Prompts | Guias concisos sobre DevOps, Nuvem e IA

⚡ Resumo Conciso

• Veja por que lançamos um servidor de diagnóstico MCP OpenShift como somente leitura por design, e a barreira RBAC que tornou o acesso de gravação mais difícil do que parece
• Faça uma análise de um teste de remediação falho onde um agente recomendou uma correção que parecia correta, mas foi construída com uma configuração obsoleta — e qual é realmente esse modo de falha
• Conheça a arquitetura de aprovação com maturidade que projetamos para acesso de gravação — e por que ainda está apenas no papel, não em produção

A História

Construímos mcp-sre-tools — um servidor MCP que expõe diagnósticos OpenShift e Kubernetes a um LLM, conectado ao Claude Desktop e n8n, cobrindo ARO, ROSA HCP, OSD-GCP e clusters genéricos. Nove ferramentas de diagnóstico: get_cluster_health, diagnose_crashloop, get_failing_pods, e outras dessa família. O READ_ONLY_MODE está ativado por padrão, e não há ferramentas de gravação no código. Essa parte foi lançada limpa.

A fricção começou quando definimos o que viria a seguir: um modo de remediação, onde o agente não apenas diagnosticaria uma implantação quebrada — ele a corrigiria.

Foi aí que a história deixou de ser uma história de construção e se tornou uma história organizacional.

O Problema

Engenheiros de plataforma e desenvolvedores rapidamente se posicionaram em lados opostos da mesma questão, e por razões que se mostraram mais substanciais do que o habitual reflexo de aversão ao risco.

Os desenvolvedores estavam confortáveis em confiar nas mudanças propostas pelo agente da mesma forma que confiariam em um pull request de um colega — ler a diferença, verificar a sanidade, mesclar. Os engenheiros de plataforma se opuseram fortemente, e sua objeção não foi reflexiva. Foi específica: um PR de um colega vem com uma razão inspecionável. Você pode perguntar a eles o porquê. Um patch proposto por um LLM não carrega essa mesma trilha — o "porquê" está enterrado em uma passagem para frente, não em um comentário de revisão de código.

Os stakeholders de negócios, por sua vez, estavam preocupados com algo mais simples e imediato: um agente autônomo quebrando uma aplicação crítica em produção.

Três preocupações legítimas, três vocabulários diferentes para a mesma questão subjacente — quanto confiamos em um sistema cuja razão não podemos inspecionar completamente, aplicado a uma infraestrutura que não podemos nos dar ao luxo de quebrar?

Por Que Abordagens Existentes Falham

A intuição é recorrer ao RBAC e chamá-lo de resolvido. Escopo a conta de serviço do agente para um namespace, dê a ele permissões de patch em Implantações e nada mais, e deixe-o operar dentro de uma cerca.

Essa cerca tem um buraco. Remediações significativas quase sempre precisam tocar em Secrets ou variáveis de ambiente — uma string de conexão de banco de dados mal configurada, uma referência de credencial expirada, uma variável de ambiente ausente causando um loop de falhas. No momento em que seu escopo de remediação inclui Secrets, "RBAC com escopo de namespace" deixa de ser um sandbox limpo e começa a ser uma superfície de confiança muito maior do que a frase implica.

Não tínhamos uma maneira de contornar isso apenas com RBAC. Então, voltamos a uma justificativa mais estreita e honesta para somente leitura: mesmo sem acesso de gravação, um agente de diagnóstico reduz o tempo médio de resolução humano. É uma proposta de valor menor do que a auto-cura completa, mas é uma proposta real — e é a que realmente poderíamos defender sem evasivas.

A Arquitetura

Diagrama 1 — como construído: a arquitetura MCP lançada, somente leitura.

Os controles que projetamos para o servidor funcionar — note que o repositório intencionalmente é enviado sem um rbac.yaml padrão, para permanecer adaptável a diferentes tipos de cluster e políticas organizacionais. Espera-se que as equipes de implantação escrevam seu próprio ClusterRole/RoleBinding adaptado ao seu modelo de acesso; o exemplo abaixo mostra a forma que recomendamos, não um padrão que é enviado:

• RBAC com escopo de namespace (recomendado, não enviado) — vincule a conta de serviço do servidor MCP aos recursos Role/RoleBinding com escopo por namespace, não um ClusterRole de cluster inteiro
• Acesso baseado em conta de serviço — sem kubeconfig estático ou credenciais pessoais no caminho de execução do agente
• Restrição de egress/ingress de NetworkPolicy — a rede do pod do servidor MCP é cercada apenas para a API do cluster e o endpoint LLM que precisa alcançar
• Registro e observabilidade como requisitos não funcionais — cada chamada de ferramenta é registrada, não adicionada depois do fato

# Forma recomendada, não um padrão enviado — as equipes de implantação escrevem as suas próprias
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: mcp-sre-tools-reader
  namespace: <target-namespace>
rules:
  - apiGroups: [""]
    resources: ["pods, "events]
    verbs: ["get, "list, "watch]
  - apiGroups: ["apps]
    resources: ["deployments, "replicasets]
    verbs: ["get, "list, "watch]

Diagrama 2 — proposto, nunca implementado: o fluxo de acesso de gravação com maturidade.

⚠️ Este é um artefato de design, não um sistema enviado. O interruptor de desligamento e a automação de rollback mostrados abaixo nunca foram construídos.