Security Profiles Operator v1: APIs Estáveis, Auditoria de Segurança e Caminho para o Upstream do Kubernetes

O Linux oferece mecanismos de segurança poderosos no nível do kernel, como seccomp, SELinux e AppArmor, que restringem as capacidades de cargas de trabalho conteinerizadas. Em resumo: seccomp filtra chamadas de sistema de processos, enquanto SELinux e AppArmor impõem políticas de acesso mandatórias a arquivos, rede e capacidades. Cada um opera através de perfis que descrevem o comportamento permitido. No entanto, criar, distribuir e manter esses perfis manualmente é tedioso e propenso a erros.

O Security Profiles Operator (SPO) alivia essa dor, permitindo que os perfis de segurança sejam gerenciados como recursos customizados do Kubernetes (Custom Resource Definitions - CRDs). Ele possibilita a gravação de perfis a partir de cargas de trabalho em execução e a vinculação declarativa a Pods. Com o lançamento da versão v1.0.0, o SPO promove todas as suas oito APIs CRD para a versão v1. Este é o primeiro release estável do projeto, validado por uma auditoria de segurança externa, um ciclo completo de hardening e uma migração sem downtime de qualquer versão de API anterior.

A equipe do VK Cloud traduziu um artigo detalhando como o projeto Security Profiles Operator, ao longo de seis anos, evoluiu suas APIs para a versão v1, passou por uma auditoria de segurança externa e agora contribui para o desenvolvimento do próprio Kubernetes. Este conteúdo é valioso para profissionais de segurança de clusters, incluindo engenheiros DevOps e SRE, especialistas em segurança da informação e desenvolvedores que criam perfis seccomp, SELinux e AppArmor para contêineres.

Seis Anos de Evolução de API

O SPO surgiu em abril de 2020, inicialmente focado apenas em seccomp. Nos anos seguintes, o projeto expandiu seu escopo para incluir SELinux (final de 2020), AppArmor (final de 2021), gravação de perfis via logs de auditoria e eBPF, distribuição de perfis baseada em OCI e muito mais. Cada nova funcionalidade introduziu novos CRDs, que permaneceram em estágios alpha ou beta enquanto as APIs amadureciam em produção. Algumas dessas APIs já eram consideradas estáveis na prática há anos: SeccompProfile estava em v1beta1 há mais de quatro anos, e SPOD em v1alpha1 há mais de cinco anos. Consumidores downstream necessitavam de uma marcação de versão estável para garantir suporte a longo prazo. O SPO está disponível no OperatorHub desde 2022 e faz parte do Red Hat OpenShift a partir da versão 4.12. O período anterior ao lançamento v1 foi a última oportunidade para introduzir mudanças disruptivas, e a equipe a aproveitou.

Essa limpeza resultou em uma série de pull requests, incluindo:

• Mudanças Estruturais: Todos os CRDs agora utilizam um tipo de status comum baseado em conditions do Kubernetes upstream. A especificação do SPOD foi reorganizada de uma lista plana de mais de 30 campos para grupos lógicos (SELinux, Enricher, Webhook, Scheduling, Security). Tipos base comuns foram extraídos para evitar duplicação entre CRDs.
• Correções de Tipos: Vários tipos de campos foram atualizados para seguir as convenções de API do Kubernetes, como a substituição de inteiros sem sinal por inteiros com sinal. Tipos externos que criavam dependências de importação desnecessárias foram movidos internamente.
• Aderência às Convenções: Valores de enum foram convertidos para PascalCase (ex: logs para Logs, RUNNING para Running). Cada campo recebeu um marcador +optional ou +required. Marcadores de validação foram adicionados a todos os tipos. A única exceção intencional são as constantes seccomp SCMP_ACT_* e SCMP_CMP_*, que mantêm seus nomes em maiúsculas para corresponder exatamente às especificações do OCI runtime e aos cabeçalhos do kernel Linux.

Auditoria de Segurança e Hardening

Antes da transição para v1, o SPO passou por uma auditoria de segurança de código. A auditoria não encontrou nenhuma vulnerabilidade crítica e confirmou que os caminhos de arquivo gravados no host são derivados de metadados do objeto, não de campos spec controlados pelo usuário; os comandos são formados como arrays de argumentos, eliminando superfícies para shell injection; e as permissões RBAC padrão não concedem privilégios excessivos a usuários sem direitos de administrador.

No entanto, a auditoria identificou áreas para hardening, especialmente na fronteira onde o recurso de tenant do usuário é traduzido para o estado do LSM (Linux Security Module) no nível do kernel. O release v1.0.0 aborda essas descobertas:

• RawSelinuxProfile: Restrição e Validação: RawSelinuxProfile permite a escrita de políticas SELinux arbitrárias em CIL (Common Intermediate Language), que o operador instala no nó. A auditoria apontou esse caminho como o mais arriscado. Na v1.0.0, um novo campo enableRawSelinuxProfiles na configuração do SPOD permite que administradores de cluster desabilitem completamente o suporte a perfis SELinux brutos. O webhook de admissão de validação agora rejeita políticas brutas inválidas em vez de permitir que falhem na reconciliação.
• SelinuxProfile: Gerenciamento do Modo Permissive: O campo booleano permissive em SelinuxProfile foi substituído por um enum mode (Enforcing ou Permissive), eliminando o risco de ativar acidentalmente o modo permissive quando o campo não está definido.
• Sanitização de Entrada AppArmor: Perfis AppArmor aceitam dados de entrada шаблонados para nomes de perfil, caminhos de executáveis e capabilities. A auditoria observou que esses dados eram carregados sem validação de conteúdo. O SPO agora aplica validação regex rigorosa a cada um deles e impede a sobrescrita de perfis já carregados no kernel.
• Limites de Tamanho de Campo e Marcadores de Validação: O campo RawSelinuxProfile.spec.policy agora possui maxLength de 500 KB, limitando o tamanho da entrada antes que ela atinja o compilador SELinux CIL no nó. Marcadores de validação foram adicionados a todos os tipos de CRD.

Hardening Adicional Além da Auditoria

• Regex Backtracking: Operadores regex gananciosos em parsers de logs de seccomp, SELinux e AppArmor foram substituídos por padrões limitados para evitar que strings de log de auditoria especialmente criadas causem backtracking excessivo.
• Restrição de Caminhos: HostProcVolumePath agora é verificado apenas para /proc. seccomp-ListenerPath é restrito ao diretório do socket do operador.
• Limites de Recursos do Gravador eBPF: O gravador de perfis eBPF agora limita o número de arquivos gravados e o comprimento máximo do caminho, prevenindo OOM (Out Of Memory) em cargas de trabalho com alta atividade de sistema de arquivos.
• Precisão do Cache de Processos: O cache de processos agora usa uma chave composta de PID e tempo de início do processo, prevenindo acertos de cache desatualizados após a reutilização de PID.
• Tratamento de Anotações de Gravação: O webhook de gravação agora sobrescreve corretamente anotações existentes, em vez de pular silenciosamente Pods já anotados.
• Cardinalidade de Métricas: Rótulos ilimitados foram removidos dos contadores Prometheus para prevenir métricas de alta cardinalidade.

Migração Sem Downtime

A atualização para v1.0.0 não requer passos manuais de migração. Webhooks de conversão tratam transparentemente a translação entre as versões antigas e novas das APIs:

• Manuais Antigos Ainda Funcionam: Você pode continuar aplicando recursos através das versões de API v1alpha1, v1alpha2 ou v1beta1. O webhook de conversão os traduzirá para v1 antes de salvar.
• Versões Antigas de API Ainda São Servidas: kubectl get com uma versão de API antiga retornará recursos com valores enum no estilo antigo, mesmo que a versão de armazenamento seja v1.
• Valores Enum Mapeados Bidirecionalmente: A camada de conversão traduz entre os valores enum de estilo antigo (logs, RUNNING) e de estilo novo (Logs, Running) em ambas as direções.

Veja como ProfileRecording se parece antes e depois:

yaml
# Antes (v1alpha1)
apiversion: security-profiles-operator.x-k8s.io/v1alpha1
kind: ProfileRecording
metadata:
  name: my-recording
spec:
  kind: SeccompProfile
  recorder: logs
  mergeStrategy: none
  podSelector:
    matchLabels:
      app: my-app

yaml
# Depois (v1)
apiversion: security-profiles-operator.x-k8s.io/v1
kind: ProfileRecording
metadata:
  name: my-recording
spec:
  kind: SeccompProfile
  recorder: Logs
  mergeStrategy: None
  podSelector:
    matchLabels:
      app: my-app

Para CRDs sem mudanças de enum, apenas a string apiVersion muda. O guia de migração completo abrange atualizações para consumidores de API Go, mudanças em constantes enum e registro de esquema. As versões antigas da API permanecerão disponíveis para compatibilidade retroativa e serão removidas em um futuro release.

De Operador para Upstream Kubernetes

O SPO sempre esteve intimamente ligado ao trabalho upstream em perfis de segurança no Kubernetes. O projeto é construído sobre a superfície de API GA de seccomp (Kubernetes 1.19) e cresceu junto com propostas relacionadas, como perfis seccomp baseados em ConfigMap e perfis seccomp embutidos com modo de reclamação.

Um exemplo recente dessa conexão é o KEP 6061: distribuição de perfis de segurança baseada em artefatos OCI. Este KEP (Kubernetes Enhancement Proposal) foi proposto para um futuro release do Kubernetes em estágio alpha. O SPO foi pioneiro na distribuição de perfis baseada em OCI anos atrás: usuários podiam publicar perfis seccomp, SELinux e AppArmor em registros OCI e referenciá-los diretamente nas especificações de Pod. O KEP 6061 traz esse conceito nativamente para o kubelet, adicionando uma chamada à API CRI (Container Runtime Interface) PullSecurityProfileArtifact, permitindo que runtimes de contêiner busquem perfis sob demanda de registros OCI.

O KEP segue o mesmo modelo de confiança dos perfis localhost: uma lista de permissões com negação por padrão no nível do kubelet, com o Pod Security Admission tratando perfis OCI da mesma forma que perfis localhost. O SPO continuará a fornecer capacidades de alto nível que o kubelet não cobre: gravação de perfis a partir de cargas de trabalho em execução, escrita estruturada de políticas SELinux, vinculação de perfis a imagens de contêiner e enriquecimento de logs de auditoria.

Próximos Passos

Com o lançamento da v1, as prioridades do projeto são:

• Remoção das versões antigas da API, no mínimo, um ciclo de release após a v1.
• Continuação do hardening: restrição mais granular de RBAC e operações mais seguras com caminhos em componentes privilegiados.
• Integração com o KEP 6061: vinculação das capacidades de distribuição OCI do SPO com o suporte nativo no kubelet à medida que ele amadurece através dos estágios alpha e beta.

Experimente a v1.0.0, consulte o guia de migração e junte-se à discussão em #security-profiles-operator no Kubernetes Slack. O SPO foi construído por mais de 70 contribuidores de diversas organizações. Agradecemos a todos que contribuíram com código, abriram issues, testaram pré-releases e participaram da auditoria de segurança. A v1 é tanto de vocês quanto nossa.