Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Alterne a autoridade de certificação (CA) do cluster do EKS

Em uma infraestrutura de chave pública (PKI), uma autoridade de certificação (CA) é uma entidade confiável que emite e assina certificados digitais. Esses certificados estabelecem identidade e permitem a comunicação criptografada entre sistemas usando TLS (Transport Layer Security). Quando um cliente se conecta a um servidor, o servidor apresenta um certificado assinado por uma CA. O cliente verifica o certificado do servidor em relação às CAs em que confia antes de permitir que a conexão continue.

No Amazon Elastic Kubernetes Service (Amazon EKS), uma CA é criada para cada cluster do EKS no momento da criação do cluster. Isso segue o mesmo modelo do Kubernetes upstream: cada cluster do EKS tem sua própria CA que assina certificados para o servidor da API. É isso que permite que componentes do ambiente de gerenciamento, nós de processamento e clientes se autentiquem no servidor da API e estabeleçam conexões criptografadas com o cluster do EKS.

Essas autoridades de certificação (CAs) têm um período de validade definido. A rotação de CA é o processo de substituir a autoridade de certificação do cluster do EKS antes que ela expire, garantindo que seu cluster permaneça operacional e acessível. Temos proteções integradas que gerenciam automaticamente esse processo. Se você mesmo não iniciar a rotação de CA, anexaremos automaticamente uma CA sucessora e a ativaremos antes que a CA de saída expire, garantindo que seu cluster permança disponível.

Durante a rotação da CA, uma CA sucessora é anexada ao seu cluster do EKS. O EKS distribui a CA sucessora para todos os componentes da AWS gerenciados (ambiente de gerenciamento, instâncias do Modo Automático do EKS e nós do AWS Fargate) automaticamente. Você é responsável por atualizar os nós de processamento que você gerencia (não vinculados ao Modo Automático do EKS ou ao Fargate) e clientes externos (como arquivos kubeconfig e pipelines de CI/CD) para confiar na CA sucessora antes que ela seja ativada. Depois que a CA sucessora é ativada, o cluster do EKS passa a assinar certificados com a CA sucessora. A CA de saída é então desativada.

A rotação de CA é necessária para cada cluster do EKS porque as CAs têm um período de validade finito. O período de validade depende de quando a CA do cluster foi criada. Para obter mais detalhes, consulte a seção de perguntas frequentes. As proteções do EKS garantem que seu próprio cluster permaneça disponível durante todo o ciclo de vida da rotação, mas uma rotação bem-sucedida também depende da atualização dos nós de processamento que você gerencia e dos clientes externos para que eles mantenham a conectividade após a ativação da CA sucessora.

As APIs, a experiência do console, as notificações e as orientações passo a passo nas seções a seguir foram projetadas para ajudá-lo nesse processo. O escopo completo das responsabilidades é abordado na seção do modelo de responsabilidade compartilhada.

Como funciona a rotação de CA

A rotação de CA no Amazon EKS é um processo de vários estágios. Temos proteções automáticas para preservar a disponibilidade do cluster do EKS durante todo o ciclo de vida da rotação, independentemente de você agir ou não. Uma rotação bem-sucedida, na qual todos os componentes mantêm a conectividade, requer as etapas descritas nas seções a seguir.

Etapa 1: anexar uma CA sucessora

Uma CA sucessora é anexada ao cluster do EKS. A partir desse ponto, o cluster do EKS confia simultaneamente na CA de saída e na CA sucessora. Os certificados continuam sendo emitidos pela CA de saída. Nenhuma interrupção ocorre.

Você mesmo pode acrescentar uma CA sucessora a qualquer momento usando a AWS CLI, a API EKS, o console ou a infraestrutura como código (IaC), como o AWS CloudFormation, desde que seu cluster esteja em um estado ativo. Se você não fizer isso, anexaremos automaticamente uma em seu nome.

A CA sucessora só poderá ser ativada quando a AWS concluir a distribuição para os componentes da AWS gerenciados no EKS (Etapa 2). Esse é o momento certo para começar a identificar os nós de processamento e os clientes externos que precisam ser atualizados. Identificar todos os sistemas que se conectam ao servidor de API do seu cluster do EKS pode levar tempo, especialmente em ambientes com várias equipes, pipelines de CI/CD e ferramentas de monitoramento. Iniciar esse processo com antecedência oferece a maior flexibilidade para coordenar atualizações em seu próprio cronograma.

Etapa 2: distribuir a CA sucessora

Depois que a CA sucessora é anexada, a AWS atualiza os componentes gerenciados em seu cluster do EKS (o ambiente de gerenciamento, as instâncias do Modo Automático do EKS e os nós do AWS Fargate) para reconhecer e confiar em ambas as CAs. É possível acompanhar o andamento do processo por meio do status de distribuição da CA. A CA sucessora só poderá ser ativada quando a distribuição for concluída.

Depois de concluirmos a distribuição da CA para os componentes gerenciados, você é responsável por atualizar dois grupos: os nós de processamento que você gerencia (não vinculados ao Modo Automático do EKS ou ao Fargate) e os clientes externos para confiar na CA sucessora. Isso garante que eles continuarão se conectando ao servidor da API após a ativação da CA sucessora. Se algum componente não for atualizado antes da ativação da CA sucessora, a reversão da CA estará disponível para restaurar a conectividade enquanto você conclui as atualizações restantes.

Etapa 3: ativar a CA sucessora

Depois de concluirmos a distribuição da CA sucessora para todos os componentes da AWS gerenciados no EKS, a CA sucessora pode ser ativada. Recomendamos ativar a CA sucessora em seu próprio cronograma. Reserve tempo suficiente para descobrir e atualizar os nós de processamento que você gerencia e os clientes externos para confiar na CA sucessora. Depois que a CA sucessora é ativada, o cluster do EKS emite certificados assinados pela CA sucessora. A CA de saída permanece confiável, mas não é mais usada para assinatura. Uma janela de reversão está disponível por um período limitado após a ativação, permitindo que você reverta para a CA de saída, se necessário. A reversão será abordada em detalhes em uma seção posterior.

Você mesmo pode ativar a CA sucessora quando tiver certeza de que os nós de processamento que você gerencia e os clientes foram atualizados. Caso contrário, ativaremos a CA sucessora automaticamente à medida que o prazo de expiração se aproximar.

O período de dupla confiança

O tempo entre a anexação de uma CA sucessora (Etapa 1) e a desativação da CA de saída é chamado de período de confiança dupla. Durante esse período, o cluster do EKS confia nas duas CAs simultaneamente. É isso que torna a rotação ininterrupta: os componentes podem ser atualizados incrementalmente porque o cluster do EKS aceita certificados assinados por qualquer CA.

O período de confiança dupla oferece tempo para identificar e atualizar todos os nós de processamento que você gerencia e os clientes externos sem precisar coordenar todas as alterações simultaneamente.

É importante entender como a ativação da CA sucessora afeta a conectividade. Quando um cliente se conecta ao servidor da API, ele verifica a identidade do servidor checando se o certificado do servidor foi assinado por uma CA em que ele confia.

Depois que a CA sucessora é ativada, o servidor da API apresenta seu certificado assinado pela CA sucessora. Os clientes que atualizaram seu pacote de confiança para incluir a CA sucessora serão verificados com sucesso e se conectarão normalmente. Os clientes que não atualizaram seu pacote de confiança não reconhecerão o certificado do servidor e não conseguirão estabelecer uma conexão.

O diagrama a seguir mostra o fluxo da conexão TLS após a ativação da CA sucessora.

É por isso que é importante atualizar os nós de processamento e os clientes externos antes da ativação da CA sucessora: eles precisam da CA sucessora em seu pacote de confiança para verificar a identidade do servidor da API e se conectar. O período de confiança dupla e a reversão da CA fornecem tempo e uma rede de segurança para concluir esse processo.

Modelo de responsabilidade compartilhada

A rotação de CA no Amazon EKS segue o mesmo modelo de responsabilidade compartilhada que se aplica amplamente a toda a AWS. A AWS é responsável pela segurança e disponibilidade da infraestrutura de nuvem e você é responsável pela segurança e configuração de suas workloads dentro dela. Para obter mais informações sobre como a responsabilidade compartilhada se aplica ao Amazon EKS, consulte as melhores práticas de segurança do EKS.

No contexto da rotação de CA, isso significa:

A AWS é responsável por

Você é responsável por

Não podemos executar essas ações em seu nome. Existem clientes externos fora do limite operacional da AWS. Os nós de processamento que não são gerenciados pelo Modo Automático do EKS ou pelo Fargate têm sua configuração de confiança da CA definida no momento da inicialização ou por meio de processos de bootstrap que somente você controla. Isso é consistente com a forma como a confiança do TLS funciona: o cliente tem seu próprio repositório de confiança e somente o administrador do cliente pode atualizá-lo.

As seções a seguir detalham cada lado: o que a AWS faz por você e o que você precisa fazer, além de orientações passo a passo sobre como fazer isso.

O que a AWS faz por você

A AWS gerencia o seguinte em todo o ciclo de vida de rotação da CA para seu cluster do EKS:

Criação automática de CA

Se você não acrescentar uma CA sucessora em seu próprio cronograma, anexaremos uma automaticamente quando a CA de saída do seu cluster do EKS estiver prestes a expirar. Isso garante que o processo de rotação comece com tempo suficiente para você descobrir e atualizar seus clientes antes do prazo de expiração.

Atualizações do ambiente de gerenciamento

Atualizamos automaticamente o ambiente de gerenciamento do cluster do EKS para confiar na CA sucessora. Depois que a CA sucessora é ativada, o ambiente de gerenciamento emite certificados assinados pela CA sucessora. Não é necessária nenhuma ação sua para o ambiente de gerenciamento.

Atualizações do Modo Automático do EKS e do Fargate

Atualizamos automaticamente os nós do Modo Automático do EKS e os pods do Fargate para confiar na CA sucessora. Esses componentes são totalmente gerenciados por nós e não exigem nenhuma ação de sua parte durante a rotação da CA.

Atualizações das Capacidades do EKS

Atualizamos automaticamente as Capacidades do EKS (AWS Controllers for Kubernetes (ACK), Argo CD e kro (Kube Resource Orchestrator)) para confiar na CA sucessora. Esses recursos gerenciados se comunicam com o servidor de API do seu cluster e são atualizados como parte do processo de distribuição da CA. Não é necessária nenhuma ação sua para os recursos gerenciados nas Capacidades do EKS. Para obter mais informações, consulte Capacidades do EKS.

Acompanhamento do status da distribuição

À medida que atualizamos os componentes gerenciados em seu cluster do EKS, você pode monitorar o progresso por meio do status de distribuição da CA. Isso indica se concluímos nossa parte da rotação. A CA sucessora só poderá ser ativada quando a distribuição for concluída.

Proteções integradas

Temos proteções integradas para proteger seu cluster do EKS durante a rotação:

Essas proteções garantem que a disponibilidade do cluster do EKS seja preservada durante todo o ciclo de vida da rotação, independentemente de você agir ou não.

Notificações

Notificamos você em cada estágio do ciclo de vida de rotação da CA. As notificações são enviadas por meio do AWS Health, Cluster Insights e e-mail. Cada notificação informa o que aconteceu, qual ação (se houver) é exigida de você e onde seu cluster do EKS está na linha do tempo de rotação.

Você também pode configurar suas próprias notificações usando o Amazon EventBridge para integrar eventos de rotação da CA aos seus fluxos de trabalho de monitoramento e alerta existentes.

O que você precisa fazer (e por quê)

Uma rotação bem-sucedida de CA exige que você atualize os componentes que a AWS não consegue acessar em seu nome. Eles se encaixam em duas categorias:

Clientes externos

Qualquer sistema que se conecte ao servidor de API do seu cluster do EKS de fora do cluster. Isso inclui estações de trabalho para desenvolvedores, pipelines de CI/CD (Jenkins, GitHub Actions, GitLab, ArgoCD), ferramentas de monitoramento e observabilidade, scripts de automação e qualquer aplicativo que use um kubeconfig para se comunicar com o servidor da API.

Cada um desses sistemas mantém sua própria configuração de confiança. Depois que a CA sucessora é ativada, o servidor da API apresenta certificados assinados pela CA sucessora. Atualizar esses clientes para confiar na CA sucessora antes da ativação da CA sucessora garante que eles mantenham a conectividade. Se um cliente for perdido, a reversão da CA pode restaurar o acesso enquanto você conclui a atualização.

Nós de processamento (não vinculados ao Modo Automático do EKS ou ao Fargate)

Os nós de processamento que não são gerenciados pelo Modo Automático do EKS ou pelo Fargate têm sua configuração de confiança da CA definida no momento da inicialização ou por meio de processos de bootstrap do kubelet. Esses nós precisam ser atualizados para que confiem na CA sucessora. A ação necessária depende do tipo de nó de processamento:

Grupos de nós gerenciados

Execute uma atualização da versão do grupo de nós, que aciona uma substituição contínua dos nós. Novos nós são inicializados automaticamente com a configuração de confiança de CA atualizada.

Nós controlados pelo Karpenter

Se a detecção de desvio estiver ativada, o Karpenter alternará os nós dentro de sua janela de desvio configurada e os novos nós adotarão a CA sucessora sem ação manual. Se a detecção de desvio estiver desativada ou configurada para uma janela longa, trate esses nós da mesma forma que os nós autogerenciados.

Nós autogerenciados

Substitua os nós para que eles inicializem com a configuração de confiança de CA atualizada. Isso normalmente envolve atualizar o modelo de lançamento com os dados atualizados da CA e acionar uma substituição contínua por meio do seu grupo do Auto Scaling.

Nós híbridos

Atualize a configuração de confiança em cada nó híbrido para incluir a CA sucessora. O processo específico depende de como seus nós híbridos foram inicializados e de como sua configuração de confiança é gerenciada.

Você pode identificar quais tipos de nós de processamento estão sendo executados em seu cluster do EKS usando o Cluster Insights. Uma orientação detalhada passo a passo para atualizar cada tipo será fornecida em uma seção posterior.

Fornecemos a reversão da CA como uma rede de segurança caso algum nó de processamento seja perdido. No entanto, atualizar todos os nós de processamento antes da ativação da CA sucessora evita totalmente as interrupções de conectividade. Os nós não atualizados antes da ativação da CA sucessora perderão a conectividade com o servidor de API do cluster do EKS até serem substituídos ou a reversão da CA ser executada.

Por que só você pode fazer isso

Existem clientes externos fora do limite operacional da AWS. Um pipeline de CI/CD em execução em sua rede corporativa, um laptop de desenvolvedor, uma ferramenta de monitoramento hospedada on-premises: a AWS não tem nenhum mecanismo para acessar esses sistemas e atualizar sua configuração de confiança.

Os nós de processamento que não são gerenciados pelo Modo Automático do EKS têm sua configuração de confiança controlada por meio de modelos de inicialização, scripts de dados do usuário ou processos de bootstrap de sua propriedade. Atualizá-los requer a substituição dos nós ou a modificação de sua configuração, ambas as ações dentro de sua infraestrutura.

Essa é uma restrição do modelo de confiança TLS usado atualmente pelo Kubernetes. Não há um mecanismo em nível de protocolo para o servidor de API consultar se um cliente atualizou seu pacote de confiança. O servidor só pode apresentar seu certificado quando um cliente se conecta. Se o cliente confiar na CA que o assinou, a conexão será bem-sucedida. Caso contrário, ele falhará. Não há um caminho de verificação de pré-ativação que permita que a AWS confirme a disponibilidade de seus componentes em seu nome.

Quando começar

Comece a identificar seus clientes externos o quanto antes. Essa é a parte mais demorada da rotação da CA, especialmente em ambientes com várias equipes que implantam workloads de forma independente no cluster do EKS. Quanto mais cedo você começar a descobrir clientes, mais tempo terá para coordenar as atualizações entre as equipes sem pressão.

Orientações detalhadas sobre como atualizar cada tipo de cliente e nó de processamento são fornecidas nas seções a seguir.

Pré-requisitos

Antes de iniciar a rotação da CA, confirme o seguinte:

Nenhuma permissão adicional do IAM é necessária além das exigidas para gerenciar seu cluster do EKS. Se você puder chamar as APIs do EKS para seu cluster do EKS hoje, poderá realizar a rotação da CA.

Introdução

Você pode realizar a rotação de CA usando a AWS CLI ou o console do Amazon EKS. Verifique se você está executando a AWS CLI versão 2.x ou posterior (aws --version para verificar).

Usar a AWS CLI

O passo a passo a seguir aborda o processo de rotação de CA de ponta a ponta usando a AWS CLI e as APIs do EKS.

Etapa 1: verificar sua CA ativa

Visualize a autoridade de certificação ativa em seu cluster do EKS.

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Saída esperada:

{
    "certificateAuthorities": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-example11111",
            "createdAt": "2024-01-15T10:30:00-07:00",
            "createdBy": "EKS",
            "activatedAt": "2024-01-15T10:30:00-07:00",
            "activatedBy": "EKS",
            "signingStatus": "IN_USE",
            "distributionStatus": "COMPLETE"
        }
    ]
}

Isso mostra a CA que foi criada quando seu cluster do EKS foi criado. Atualmente, ela está em uso (assinatura de certificados) e a distribuição está completa (todos os componentes gerenciados da AWS no EKS confiam nela).

Etapa 2: visualizar detalhes e expiração da CA

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2

Saída esperada:

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example11111",
        "createdAt": "2024-01-15T10:30:00-07:00",
        "createdBy": "EKS",
        "activatedAt": "2024-01-15T10:30:00-07:00",
        "activatedBy": "EKS",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "validity": {
            "notBefore": "2024-01-15T10:30:00-07:00",
            "notAfter": "2029-01-14T10:30:00-07:00"
        },
        "rollbackAvailable": false
    }
}

O bloco validity mostra quando a CA foi criada (notBefore) e quando ela expira (notAfter). rollbackAvailable indica se você pode reverter para uma CA anterior após a ativação da CA sucessora. Para a CA inicial criada com seu cluster do EKS, isso será false porque não há CA anterior para a qual reverter.

Etapa 3: anexar uma CA sucessora

aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2

Essa etapa anexa uma CA sucessora ao cluster do EKS. A resposta inclui uma updateId que você pode usar para monitorar o progresso.

Etapa 4: acompanhar a atualização

aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2

Espere até que o status da atualização seja Successful.

Etapa 5: verificar status da distribuição

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Você agora deve ver duas CAs. A CA sucessora terá signingStatus: NOT_USED e o distributionStatus progredirá de IN_PROGRESS para COMPLETE depois que a AWS atualizar todos os componentes gerenciados em seu cluster do EKS.

Não prossiga até que o status de distribuição da CA sucessora seja COMPLETE.

Etapa 6: atualizar o kubeconfig

aws eks update-kubeconfig --name my-cluster --region us-west-2

Essa etapa atualiza seu kubeconfig local para confiar em ambas as CAs. Depois disso, seus comandos kubectl continuarão funcionando depois que a CA sucessora for ativada.

Etapa 7: atualizar os nós de processamento que você gerencia e os clientes externos

Os detalhes são abordados na próxima seção. Depois que todos os nós de processamento que você gerencia e os clientes externos tiverem sido atualizados para confiar na CA sucessora, prossiga com a ativação.

Etapa 8: ativar a CA sucessora

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <successor-ca-id> --region us-west-2

Depois que a CA sucessora é ativada, o cluster do EKS emite certificados assinados pela CA sucessora. Verifique a conectividade para confirmar se todos os componentes estão funcionando conforme o esperado.

Usar o console do Amazon EKS

O console do Amazon EKS fornece uma experiência guiada para rotação de CA. Você pode visualizar o status da CA, acrescentar uma CA sucessora, monitorar o progresso da distribuição e ativar a CA sucessora diretamente do console.

A imagem a seguir mostra a visualização dos detalhes da autoridade de certificação no console do Amazon EKS durante uma rotação ativa. A CA ativa e a CA sucessora são exibidas com seu status de assinatura, data de expiração e dias até a expiração.

A imagem a seguir mostra a visualização do progresso da rotação no console do Amazon EKS. Cada etapa do processo de rotação é exibida com seu estado atual, incluindo acréscimo, distribuição, atualização de nós de processamento e clientes externos, ativação e exclusão da CA de saída.

Atualização de seus clientes Kubernetes

Depois que a CA sucessora for anexada e a AWS concluir a distribuição aos componentes gerenciados em seu cluster do EKS (distributionStatus: COMPLETE), você precisará atualizar seus próprios componentes para confiar na CA sucessora. Um “cliente” nesse contexto é qualquer sistema que se conecta ao servidor de API do seu cluster do EKS. Isso inclui sua configuração kubectl local, pipelines de CI/CD, ferramentas de monitoramento, scripts de automação e seus nós de processamento.

Os dados atualizados da CA para seu cluster do EKS (que agora contém as CAs atuais e sucessoras) podem ser recuperados usando:

aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text

Use esse valor para atualizar a configuração de confiança de cada tipo de cliente nas subseções a seguir.

Kubeconfig (estações de trabalho para desenvolvedores, pipelines de CI/CD, automação)

Execute o seguinte para atualizar seu kubeconfig local:

aws eks update-kubeconfig --name my-cluster --region us-west-2

Essa operação recupera automaticamente os dados mais recentes da CA e atualiza seu kubeconfig. Qualquer sistema que use esse kubeconfig confiará nas duas CAs.

Para pipelines de CI/CD e automação que geram seu próprio kubeconfig (por exemplo, usando as APIs EKS diretamente ou armazenando kubeconfig como segredo), atualize o campo certificate-authority-data com o valor recuperado de describe-cluster.

Grupos de nós gerenciados

Execute uma atualização da versão do grupo de nós para acionar uma substituição contínua dos nós:

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2

Novos nós são inicializados automaticamente com os dados da CA atualizada. A substituição contínua garante que os nós sejam substituídos um por vez sem interromper as workloads em execução.

Se você gerencia seus grupos de nós por meio do Terraform ou do CloudFormation, a rotação da CA não cria um desvio em seu estado de IaC. O ciclo de vida da CA é gerenciado por meio de APIs EKS dedicadas, separadas da configuração dos recursos do cluster. Para obter mais detalhes sobre como a rotação da CA interage com a infraestrutura como código, consulte a seção Infraestrutura como código.

Modelo de execução personalizado com uma AMI personalizada

Se o grupo de nós for implantado com uma AMI personalizada, a AWS não mesclará os dados do usuário. Você é responsável por fornecer a configuração correta do bootstrap, incluindo o pacote de confiança de CA atualizado. A rotação de CA não atualiza seus dados de usuário para você, e um nó sem a CA sucessora não consegue se juntar ao cluster.

Verifique se os nós estão sendo executados no modelo de execução atualizado

Antes de prosseguir com a ativação, confirme se todos os nós em seu grupo de nós gerenciados estão sendo executados na versão mais recente do modelo de execução. Essa versão deve conter o pacote de confiança de CA atualizado.

Nós controlados pelo Karpenter

Se a detecção de desvio estiver ativada em seu Karpenter NodePool, o Karpenter detectará automaticamente que os nós estão sendo executados com dados desatualizados da CA e os alternará dentro da janela de interrupção configurada. Novos nós adotarão a CA sucessora sem ação manual.

Verifique se a detecção de desvios está ativada em sua configuração do NodePool:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

Se disruption estiver configurado com uma política de consolidação, a detecção de desvios estará ativa por padrão. O Karpenter substituirá os nós que saíram do estado desejado, o que inclui alterações nos dados da CA.

Se a detecção de desvios estiver ativada, verifique se seu orçamento de interrupção permite que todos os nós controlados pelo Karpenter sejam substituídos antes da data de ativação da CA sucessora. Se o orçamento for muito restritivo (por exemplo, uma janela de manutenção estreita com uma baixa porcentagem de substituição), nem todos os nós poderão ser substituídos a tempo.

Se a detecção de desvios estiver desativada ou seus orçamentos de interrupção restringirem as substituições a uma janela que exceda seu cronograma de rotação, você poderá acionar manualmente a substituição dos nós isolando e drenando os nós:

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

O Karpenter provisionará um nó substituto que será inicializado com os dados atualizados da CA.

Nós autogerenciados

Para nós autogerenciados, você precisa atualizar os dados da CA no modelo de execução ou no script de dados do usuário que seus nós usam durante o bootstrap:

Os novos nós serão inicializados com os dados atualizados da CA e confiarão nas CAs atuais e sucessoras.

Pods do AWS Fargate (tipo de execução do EKS Fargate)

Os pods do AWS Fargate em seu cluster do EKS funcionam de forma diferente de outros modos de execução do plano de dados do EKS (grupos de nós gerenciados, nós autogerenciados, nós controlados pelo Karpenter).

Quando um pod se conecta ao servidor da API, duas coisas acontecem: o pod se autentica usando o token da conta de serviço (provando sua identidade ao servidor da API) e verifica a identidade do servidor da API checando se o certificado do servidor foi assinado por uma CA em que confia. Os dados da CA armazenados no ambiente do pod são o que torna essa verificação possível. Se o servidor da API começar a apresentar certificados assinados por uma CA sucessora na qual o pod não confia, o pod rejeitará a conexão.

Em outros modos de execução do plano de dados do EKS (grupos de nós gerenciados, nós autogerenciados, nós controlados pelo Karpenter), os dados da CA residem no nó. Quando você substitui o nó, o novo nó é inicializado com os dados atualizados da CA. Os pods programados nesse novo nó recebem os dados atualizados da CA, permitindo que eles verifiquem o servidor da API, independentemente de qual CA assinou seu certificado.

No Fargate, cada pod é executado em seu próprio ambiente de computação dedicado com seu próprio processo kubelet. Esse kubelet é inicializado com os dados da CA no momento em que o pod é criado. Não há nenhum nó compartilhado por baixo e você não tem acesso direto à computação subjacente.

Nenhuma ação do cliente é necessária para os nós do AWS Fargate no EKS durante a rotação da CA. A AWS recicla naturalmente os pods nos nós do Fargate por meio de seu processo de correção. Depois que uma CA sucessora é anexada, os pods do Fargate preexistentes são reciclados como parte desse processo. Eles confiarão na CA sucessora sem nenhuma ação de sua parte. Como a AWS anexa a CA sucessora bem antes de qualquer cronograma de ativação da CA iniciada pela AWS no EKS, os pods do Fargate terão sido reciclados e confiarão na CA sucessora quando a AWS ativar a CA sucessora. Há uma proteção integrada que impede a ativação da CA sucessora até que os pods do Fargate terminem de ser reciclados.

Isso significa que as duas opções de plano de dados gerenciado (Modo Automático do EKS e Fargate) para um cluster do EKS têm a mesma experiência de usuário para rotação de CA: nenhuma ação do cliente é necessária para seus nós de processamento. Você ainda é responsável por atualizar todos os clientes externos que se conectam ao servidor da API.

Esse é um caso extremo. Dado o cronograma de rotação (CA sucessora anexada anos antes da expiração), o ciclo natural de correção será concluído bem antes da ativação da CA sucessora na grande maioria dos cenários. A salvaguarda existe como uma medida preventiva para o caso improvável de um cliente tentar a ativação antecipada.

Clientes externos (ferramentas de monitoramento, integrações de terceiros)

Qualquer aplicativo ou ferramenta que se conecte ao servidor de API do seu cluster do EKS usando uma configuração kubeconfig ou de confiança de certificado precisa ser atualizado com os dados atualizados da CA. Isso inclui:

Para cada um deles, substitua os dados armazenados da CA pelo valor atualizado de describe-cluster.

Como verificar se um cliente foi atualizado

Depois de atualizar um cliente, confirme se ele ainda pode se comunicar com o servidor da API:

kubectl get nodes

Em caso de comando bem-sucedido, o kubeconfig confiará nos dados ativos da CA. Após a ativação da CA sucessora, execute o mesmo comando para confirmar a continuidade da conectividade.

Infraestrutura como código

Você pode realizar a rotação de CA junto com sua infraestrutura como código (IaC) existente sem criar desvios ou exigir alterações nas configurações de IaC.

Por que a rotação de CA não afeta seu estado de IaC

O ciclo de vida da CA é gerenciado por meio de APIs EKS dedicadas (create-certificate-authority, activate-certificate-authority, delete-certificate-authority), totalmente separadas da configuração dos recursos do cluster do EKS. Se a rotação da CA é iniciada por você ou automaticamente pela AWS, nenhuma propriedade rastreada por suas ferramentas de IaC no recurso de cluster do EKS é modificada.

Isso significa que:

O campo certificateAuthority.data retornado por describe-cluster é uma saída somente leitura. Ele reflete o pacote de confiança combinado atual (ambas as CAs durante o período de confiança dupla), mas não é uma propriedade configurável. As ferramentas do IaC não o rastreiam como algo a ser reconciliado.

Os campos de atribuição (createdBy, activatedBy) em cada registro da CA permitem distinguir entre as operações iniciadas por você e as operações iniciadas automaticamente pela AWS, o que dá suporte aos fluxos de trabalho de auditoria e gerenciamento de mudanças.

Usando o CloudFormation com rotação de CA

A rotação da CA pode ser acionada por meio do CloudFormation usando uma propriedade WriteOnly no recurso AWS::EKS::Cluster. Essa propriedade aciona a ativação, mas não é armazenada no estado da pilha; portanto, as atualizações subsequentes da pilha sem ela não tentam reverter ou desativar.

# Phase 1: Add to existing stack that manages your cluster
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster

Essa primeira atualização da pilha anexa uma CA sucessora ao seu cluster. Aguarde até que o status de distribuição da CA sucessora chegue a COMPLETE antes de continuar.

# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    # Update your existing Cluster resource to activate
    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster
            ActiveCertificateAuthorityId: !GetAtt NewCA.Id

Essa segunda atualização de pilha aciona a ativação da CA sucessora. Por ser ActiveCertificateAuthorityId uma propriedade WriteOnly, ela não é retornada na leitura e o CloudFormation não detectará desvios se a CA ativa for alterada fora do CloudFormation (por exemplo, por meio da ativação automática pela AWS).

Importante: a integração do CloudFormation com a rotação de CA segue um padrão diferente dos recursos típicos do CloudFormation. Uma autoridade de certificação no EKS não é um recurso independente com seu próprio ARN. Ela existe como parte do ciclo de vida do certificado do cluster e é autorizada pelo próprio cluster, da mesma forma que uma política de perfil do IAM é autorizada por meio de sua função principal (AWS::IAM::RolePolicy) ou uma associação EIP é autorizada por meio de sua instância (AWS::EC2::EIPAssociation). Os clientes que gerenciam a rotação da CA por meio do CloudFormation devem estar cientes dessa distinção.

Grupos de nós gerenciados e IaC

Executar uma atualização da versão do grupo de nós para atualizar os nós com a configuração de confiança da CA atualizada é uma ação operacional. Os novos nós são inicializados automaticamente com os dados de confiança ativos da CA do cluster. Se seus modelos de IaC não codificarem dados de CA em modelos de execução ou dados do usuário, nenhuma alteração de modelo será necessária.

Reversão da CA

Depois de ativar uma CA sucessora, você pode reverter para a CA anterior se descobrir problemas de conectividade com os nós de processamento que você gerencia (não vinculados ao Modo Automático do EKS ou ao Fargate) ou clientes externos. A reversão reativa a CA anterior como autoridade de assinatura do seu cluster do EKS.

Quando a reversão da CA está disponível

A reversão da CA está disponível após a ativação da CA, desde que:

Você pode verificar se a reversão da CA está disponível a qualquer momento usando o campo rollbackAvailable retornado por describe-certificate-authority:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example22222",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "rollbackAvailable": true
    }
}

Quando a reversão da CA não está disponível

A reversão da CA não está disponível após a ativação automática final. Se a AWS ativar a CA sucessora pela última vez (45 dias antes da expiração da CA), a rotação deverá prosseguir. A ativação automática final só ocorre se a primeira ativação automática tiver sido revertida anteriormente. Ela existe como uma proteção de último recurso para garantir que o cluster do EKS não atinja a expiração da CA sem uma CA válida em vigor.

Como reverter

Para reverter, reative a CA anterior:

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <previous-ca-id> --region us-west-2

O que acontece durante a reversão da CA

Quando considerar a reversão da CA

A reversão da CA é um mecanismo de segurança para situações em que a ativação da CA sucessora revela um problema de conectividade que você não detectou antes:

Depois de reverter, você retém todo o período de confiança dupla para identificar e corrigir o problema antes de reativar a CA sucessora.

Recuperação sem reversão da CA

Se você ativar a CA sucessora antes de atualizar seus grupos de nós gerenciados e a janela de reversão da CA não estiver mais disponível (por exemplo, após o prazo final de ativação automática), você poderá recuperá-la executando uma atualização contínua nos grupos de nós afetados. No entanto, a tentativa inicial de atualização contínua falhará porque os nós desconectados não podem receber comandos de remoção de pod do servidor da API.

Etapas de recuperação

Considerações e limitações

Disponibilidade regional

A rotação de CA está disponível em todas as regiões comerciais da AWS nas quais o Amazon EKS é compatível.

Máximo de duas CAs

Um cluster do EKS pode ter no máximo duas CAs a qualquer momento: a CA ativa e uma sucessora. Você não pode acrescentar uma segunda CA sucessora até que a rotação anterior seja concluída.

Sem revogação de certificados

A rotação de CA não oferece suporte à revogação de certificados individuais. Isso é consistente com o Kubernetes upstream, que não implementa a revogação de certificados (CRL ou OCSP). A rotação substitui toda a CA, o que naturalmente invalida todos os certificados assinados pela CA de saída depois que ela é removida do pacote confiável.

CAs anexadas pela AWS não podem ser excluídas

Se a AWS anexar automaticamente uma CA sucessora, você não poderá excluí-la. Essa proteção garante que o processo de rotação não seja interrompido por exclusão acidental. As CAs anexadas pelo cliente podem ser excluídas, desde que não sejam a CA de assinatura ativa.

Período de validade da CA

A CA original criada com seu cluster tem um período de validade de 10 anos. As CAs sucessoras criadas por meio do processo de rotação têm períodos de validade de 5 anos. Todas as futuras CAs do seu cluster seguirão o período de validade de 5 anos. Verifique a expiração da sua CA usando describe-certificate-authority.

Tamanho dos dados do usuário do EC2 durante a confiança dupla

Durante o período de confiança dupla, o pacote de confiança do seu cluster aumenta de tamanho devido à presença de dois certificados CA (aproximadamente 2,8 KB combinados ou aproximadamente 1,9 KB com compactação gzip). Para nós de processamento em que dados personalizados do usuário são fornecidos nos modelos de execução do EC2, verifique se o tamanho total dos dados do usuário não excede o limite de dados do usuário do EC2 de 16 KB. Se seus dados de usuário existentes estiverem próximos desse limite, a adição de uma segunda CA pode causar falha na criação do modelo de execução e impedir que novos nós sejam provisionados. Considere compactar o conteúdo dos dados do usuário usando o gzip para reduzir o tamanho.

Upgrades de versão durante a rotação da CA

Os upgrades da versão do cluster do EKS e a rotação da CA são operações independentes. No entanto, não é possível executar as duas ao mesmo tempo. Se uma operação de rotação de CA estiver em andamento, um upgrade de versão será rejeitado até que a operação de CA seja concluída e vice-versa.

Bring Your Own CA (BYOCA)

Atualmente, não há suporte para usar sua própria CA privada da AWS para respaldar os certificados do cluster do EKS.

Perguntas frequentes

Como começo a usar a rotação da CA?

Para começar, execute aws eks list-certificate-authorities --cluster-name my-cluster para ver sua CA ativa e sua expiração. Se você estiver pronto para começar a rotação, execute aws eks create-certificate-authority --cluster-name my-cluster para acrescentar uma CA sucessora. O processo completo passo a passo é abordado na seção Introdução. Você pode realizar a rotação de CA usando o console do Amazon EKS.

Há algum custo associado à rotação da CA?

Não. A rotação de CA está disponível sem custo adicional para todos os clusters do EKS.

O que acontecerá se eu não realizar a rotação da minha CA antes que ela expire?

Temos proteções automáticas que evitam que seu cluster do EKS atinja a expiração da CA sem uma CA válida em vigor. Se você mesmo não iniciar a rotação de CA, anexaremos automaticamente uma CA sucessora e a ativaremos antes que a CA de saída expire, garantindo que seu cluster permança disponível.

No entanto, uma rotação bem-sucedida também exige que você atualize os nós de processamento que você gerencia (não vinculados ao Modo Automático do EKS ou ao Fargate) e clientes externos para que eles confiem na CA sucessora. Se esses componentes não forem atualizados antes da ativação da CA sucessora, eles perderão a conectividade com o servidor da API.

No Kubernetes, se uma CA não for rotacionada antes de expirar, todos os certificados assinados por essa CA se tornarão inválidos. O servidor da API não pode mais ser acessado por nenhum cliente e o cluster fica indisponível.

Quanto tempo eu tenho para concluir a rotação da CA?

O tempo total para concluir a rotação da CA depende das proteções automatizadas da AWS e do seu próprio processo de atualização.

A AWS fornece cronogramas definitivos para o que ela gerencia. Uma CA sucessora é anexada aproximadamente 2 anos antes da expiração da CA de saída. Se você mesmo não ativar a CA sucessora, nós a ativaremos automaticamente aproximadamente 6 meses antes da expiração. Se você reverter após a ativação automática, realizaremos uma ativação automática final 45 dias antes da expiração. Essas proteções garantem que seu cluster do EKS permaneça disponível, independentemente de você agir ou não.

No entanto, uma rotação bem-sucedida da CA também exige que você atualize os nós de processamento que você gerencia (não vinculados ao Modo Automático do EKS ou ao Fargate) e clientes externos para que eles confiem na CA sucessora antes de sua ativação. O tempo necessário para isso depende da configuração do nó de processamento do seu plano de dados, do espaço ocupado pelo cliente externo e do tempo necessário para você realizar a descoberta e as atualizações desses componentes.

A rotação da CA causa tempo de inatividade no meu cluster?

Não. Seu cluster do EKS permanece disponível durante todo o ciclo de vida de rotação da CA. O ambiente de gerenciamento continua atendendo às solicitações em todas as etapas. Durante o período de confiança dupla, tanto as CAs de saída quanto as sucessoras são confiáveis simultaneamente, permitindo que os componentes sejam atualizados incrementalmente sem interromper as operações do cluster. Se você reverteu para a CA anterior devido à descoberta de problemas do lado do cliente, a AWS, como forma de salvaguarda, executa uma atualização final aproximadamente 45 dias antes da expiração da CA de saída.

É importante distinguir entre o cluster do EKS (ambiente de gerenciamento) e os componentes do plano de dados. O ambiente de gerenciamento é totalmente gerenciado pela AWS e permanece disponível durante toda a rotação.

Para o Modo Automático do EKS e o Fargate, a AWS atualiza os nós de processamento automaticamente. Não há risco de perda de conectividade para seus nós de processamento nesses modos de execução do plano de dados. Você ainda é responsável por atualizar todos os clientes externos que se conectam ao servidor da API.

Para grupos de nós gerenciados, nós autogerenciados, instâncias controladas pelo Karpenter (sem a detecção de desvio ativada) e nós híbridos, você é responsável por substituir ou atualizar esses nós antes da ativação da CA sucessora. Se não forem substituídos, esses nós perderão a conectividade com o ambiente de gerenciamento após a ativação da CA sucessora, mesmo que o próprio plano de controle permaneça totalmente operacional.

Minhas workloads serão interrompidas durante a rotação da CA?

As workloads em execução (pods) não são interrompidas pela rotação da CA propriamente dita. Os pods se comunicam entre si por meio da rede de cluster, que não é afetada por uma alteração de CA. A CA é usada para comunicação entre componentes e o servidor da API, não para tráfego de pod a pod.

Se seus nós de processamento precisarem ser substituídos como parte da atualização para confiar na CA sucessora (por exemplo, grupos de nós gerenciados realizando uma atualização contínua ou Karpenter substituindo nós desviados), os pods desses nós serão reprogramados como parte do processo normal de substituição de nós. Esse é o comportamento padrão do Kubernetes durante a substituição do nó, não um efeito colateral da rotação da CA. Certifique-se de ter orçamentos de interrupção de pods (PDBs) configurados para workloads críticas para controlar como os pods são removidos durante a substituição dos nós.

Quando a CA do meu cluster expirará?

Você pode verificar quando a CA do seu cluster expira usando a AWS CLI, as APIs do EKS ou o console do Amazon EKS. Por exemplo, é possível executar o seguinte:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2 --query 'certificateAuthority.validity.notAfter'

Você pode encontrar o ID da sua CA executando aws eks list-certificate-authorities --cluster-name my-cluster.

Qual é o período de validade da CA do meu cluster?

A CA original criada com seu cluster tem um período de validade de 10 anos. As CAs sucessoras criadas por meio do processo de rotação têm períodos de validade de 5 anos. Todas as futuras CAs do seu cluster seguirão o período de validade de 5 anos. Verifique a expiração da sua CA usando describe-certificate-authority.

Posso iniciar uma rotação de CA sozinho antes que a AWS a faça automaticamente?

Sim. Você pode acrescentar uma CA sucessora a qualquer momento usando aws eks create-certificate-authority --cluster-name my-cluster. Você não precisa esperar que a AWS inicie a rotação. Começar cedo dá a você mais tempo para identificar e atualizar seus nós de processamento e clientes externos de acordo com sua própria programação.

Posso reverter depois de ativar uma CA sucessora?

Sim. A reversão da CA está disponível após a ativação da CA sucessora, desde que a janela de reversão não tenha expirado. A reversão da CA reativa a CA anterior como autoridade de assinatura. Ela não está disponível após a ativação automática final (45 dias antes da expiração da CA). Você pode verificar o campo rollbackAvailable em sua CA usando describe-certificate-authority. Para obter detalhes, consulte a seção Reversão de CA.

Como posso saber quando é seguro ativar a CA sucessora?

É seguro ativar a CA sucessora quando todos os nós de processamento que você gerencia (não vinculados ao Modo Automático do EKS ou ao Fargate) e clientes externos tiverem sido atualizados para confiar na CA sucessora. Você pode verificar isso confirmando que cada cliente pode se comunicar com sucesso com o servidor da API usando a configuração de confiança atualizada. A AWS não fornece um único indicador de que todos os clientes estão prontos, pois não consegue ver seus sistemas externos. Inicie o processo de descoberta com antecedência para ter tempo de identificar todos os clientes.

Como faço para monitorar o progresso da rotação da CA em vários clusters?

Você pode fazer isso programaticamente usando a AWS CLI ou a API EKS. Use aws eks list-certificate-authorities para cada cluster. Os campos a seguir fornecem consciência situacional para o monitoramento em nível de frota:

O exemplo de script a seguir verifica o status de rotação da CA em uma lista de clusters:

#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"

for CLUSTER in "${CLUSTERS[@]}"; do
  echo "--- $CLUSTER ---"
  aws eks list-certificate-authorities \
    --cluster-name "$CLUSTER" \
    --region "$REGION" \
    --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
    --output table
done

Você pode estender isso de modo a abranger várias regiões e contas e filtrar por clusters que tenham uma CA sucessora anexada, estejam aguardando sua ação ou estejam se aproximando dos prazos de ativação automática.

As notificações também são entregues por cluster por meio do AWS Health e e-mail em cada estágio do ciclo de vida de rotação.

O que acontece se eu ativar a CA sucessora antes de atualizar todos os meus clientes?

Qualquer cliente que não tenha sido atualizado para confiar na CA sucessora perderá a conectividade com o cluster do EKS. Depois que a CA sucessora é ativada, o servidor da API apresenta certificados assinados pela CA sucessora. Os clientes que não confiarem nela falharão na verificação do TLS e não conseguirão se conectar. Se isso acontecer, você poderá reverter para a CA anterior (se a janela de reversão ainda estiver disponível) para restaurar a conectividade enquanto conserta os clientes restantes.

O que acontece se eu perder o prazo de expiração da CA?

A AWS impede que isso aconteça. Temos proteções automáticas que garantem que seu cluster do EKS não atinja a expiração da CA sem uma CA válida em vigor. Se você ainda não tiver feito isso, anexaremos uma CA sucessora e a ativaremos automaticamente aproximadamente 6 meses antes da expiração. Se você reverter após a primeira ativação automática, a AWS executará um avanço final 45 dias antes da expiração. Seu cluster permanecerá disponível.

No entanto, se os nós de processamento que você gerencia (não vinculados ao Modo Automático do EKS ou ao Fargate) e os clientes externos não tiverem sido atualizados para confiar na CA sucessora no momento em que a ativação automática ocorrer, esses componentes perderão a conectividade com o servidor da API.

Posso perder o acesso ao meu cluster durante a rotação da CA?

Seu cluster do EKS (ambiente de gerenciamento) permanece disponível durante todo o ciclo de vida de rotação da CA. As proteções da AWS garantem que o cluster em si não fique indisponível.

No entanto, clientes individuais que você gerencia podem perder o acesso se não forem atualizados para confiar na CA sucessora antes da ativação da CA sucessora. Por exemplo, se seu kubeconfig, pipeline de CI/CD ou ferramenta de monitoramento ainda fizer referência somente à CA de saída, esses clientes não conseguirão se conectar depois que a CA sucessora for ativada. Se um cliente for perdido, a reversão da CA pode restaurar o acesso enquanto você conclui a atualização dos clientes afetados.

Preciso reiniciar meus pods?

Os pods de workload em execução não são diretamente afetados pela rotação da CA. O kubelet em cada nó gerencia a comunicação com o servidor da API; portanto, os pods de workload continuarão sendo executados sem interrupção, desde que seus nós sejam atualizados. No entanto, os controladores e operadores no cluster que usam o client-go para se comunicar com o servidor da API talvez precisem ser reiniciados após a ativação da CA sucessora, pois o client-go não relê dinamicamente o pacote de confiança da CA. Especificamente para os nós do AWS Fargate, a AWS processa a atualização automaticamente por meio do processo natural de reciclagem de pods.

Meu pacote de confiança mudará durante a rotação?

Sim. Durante a rotação da CA, o pacote de confiança do seu cluster conterá duas autoridades de certificação simultaneamente: a CA de saída e a CA sucessora. Esse é o comportamento esperado durante o período de confiança dupla e é como o processo de rotação mantém a conectividade de todos os componentes.

Aplicativos e clientes devem ser configurados para confiar em um pacote de CA em vez de se fixar em um único certificado CA. A fixação de CA (validação estrita em relação a uma única CA) não é recomendada, pois causará falhas quando o pacote de confiança for atualizado. Isso se aplica a qualquer configuração TLS do lado do cliente que se conecta ao servidor de API do seu cluster do EKS.

Por que meu cronograma de notificação é diferente do descrito nesta documentação?

Se seu cluster foi criado em 2018-2019, ele receberá notificações automatizadas em um cronograma ajustado. Sua primeira notificação incluirá as datas relevantes e as próximas etapas específicas do seu cluster. Os marcos de notificação padrão são calculados em relação à data de expiração da CA do seu cluster. Para clusters nesse intervalo, essas datas calculadas precedem a disponibilidade desse recurso; portanto, uma programação ajustada é aplicada.