O Oracle Cloud Infrastructure (OCI) anunciou uma mudança estratégica na forma como o Oracle Kubernetes Engine (OKE) gerencia a autorização de operações em seus Node Pools. A partir de 7 de agosto de 2026, as operações de ciclo de vida — como provisionamento, escalonamento e atualização — deixarão de utilizar o service principal como mecanismo de fallback, passando a exigir a autenticação exclusiva via node pool resource principal.
Para times de engenharia e arquitetos de nuvem, essa mudança não é apenas uma atualização de conformidade, mas uma evolução necessária para suportar modelos de segurança de least-privilege mais rigorosos. Na prática, a Oracle está removendo comportamentos implícitos de autorização, forçando que as permissões sejam declaradas de maneira explícita, o que aumenta a rastreabilidade e reduz a superfície de ataque em ambientes multi-tenancy ou arquiteturas distribuídas.
O que muda na prática
A alteração foca na exclusividade do resource principal. Até então, se o OKE não encontrasse uma autorização específica, o sistema recorria a um service principal mais amplo para concluir a tarefa. Com a atualização, a configuração de IAM torna-se mandatória e isolada. Vale destacar que essa mudança não afeta o runtime dos workloads ativos (ready-state), mas impacta diretamente a capacidade de gerenciar seus clusters em cenários onde você utiliza:
- Custom Images: Especialmente quando hospedadas em compartimentos ou tenancies diferentes.
- KMS Keys: Quando você gerencia suas próprias chaves para encriptação de boot volumes.
- Recursos Compartilhados: Arquiteturas centralizadas que dependem de autorização cruzada entre diferentes contas OCI.
Onde atuar?
Se sua operação depende de automação via runbooks para scaling ou upgrades automatizados, é hora de validar seu IAM. O primeiro passo é o mapeamento. Identifique quais Node Pools hoje dependem de imagens externas ou chaves gerenciadas pelo cliente e verifique se as policies atuais são capazes de autorizar essas ações através da identidade direta do resource principal.
O padrão de policy recomendado para casos de acesso cross-tenancy segue a estrutura de endorsing e admitting. Segue o exemplo técnico para referência:
Na tenancy que hospeda o Node Pool:
define tenancy image-tenancy as ocid1.tenancy.oc1..<image-tenancy-ocid>
endorse any-user to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} in tenancy image-tenancy where request.principal.type = ‘nodepool’
Na tenancy que hospeda a Imagem:
define tenancy nodepool-tenancy as ocid1.tenancy.oc1..<nodepool-tenancy-ocid>
admit any-user of tenancy nodepool-tenancy to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} where request.principal.type = ‘nodepool’
Para validar, a prática recomendada é realizar testes de scale-up em ambientes de não-produção antes de aplicar a mudança em escala nos clusters de produção. A falha no provisionamento após a data limite é um risco real para a disponibilidade do seu ambiente, caso essas policies não sejam atualizadas.
Artigo originalmente publicado em cloud-infrastructure.
