Author: Make.com Service User

Expansão Global do Pegasus 1.2 no Amazon Bedrock

A AWS anunciou uma expansão significativa na disponibilidade do modelo Pegasus 1.2, desenvolvido pela TwelveLabs, através do Amazon Bedrock. Com a introdução de inferência global entre regiões, o modelo agora está acessível em 23 novas regiões, complementando as sete regiões onde já estava disponível anteriormente. Além disso, o Bedrock passou a oferecer acesso ao modelo em todas as regiões da União Europeia utilizando inferência geográfica entre regiões.

Diferenças nas Estratégias de Inferência

A AWS disponibiliza duas estratégias distintas de processamento para esse modelo. A inferência geográfica entre regiões é ideal para cargas de trabalho que apresentam requisitos específicos de residência de dados ou conformidade regulatória dentro de limites geográficos definidos. Por outro lado, a inferência global entre regiões é recomendada para aplicações que priorizam disponibilidade e performance em múltiplas geografias, permitindo que o processamento aconteça onde houver melhor desempenho.

Capacidades do Modelo Pegasus 1.2

O Pegasus 1.2 é um modelo de linguagem orientado para processamento de vídeos que consegue gerar texto baseado no conteúdo visual, áudio e textual dentro de vídeos. Desenvolvido especificamente para vídeos de longa duração, o modelo se destaca na geração de texto a partir de vídeos e na compreensão temporal, permitindo análises sofisticadas de conteúdo videográfico.

Benefícios da Maior Disponibilidade Regional

Com a expansão do Pegasus 1.2 para essas regiões adicionais, desenvolvedores podem construir aplicações de inteligência em vídeo mais próximas aos seus dados e usuários finais. Essa proximidade reduz a latência das requisições e simplifica a arquitetura geral das soluções, permitindo processamento mais rápido e eficiente.

Próximos Passos

Para obter a lista completa de perfis de inferência suportados e regiões disponíveis para o Pegasus 1.2, consulte a documentação de inferência entre regiões. Para começar a trabalhar com o Pegasus 1.2, acesse o console do Amazon Bedrock. Mais detalhes técnicos e informações adicionais estão disponíveis na página do produto e na documentação do Amazon Bedrock.

Fonte

TwelveLabs’ Pegasus 1.2 model now in 23 new AWS regions via Global cross-region inference (https://aws.amazon.com/about-aws/whats-new/2025/12/twelvelabs-pegasus-available-with-global-cross-region-inference/)

Proteção aprimorada contra ataques DDoS na camada de aplicação

Nos primeiros meses deste ano, a AWS implementou novas camadas de proteção para aplicações, respondendo ao crescimento de ataques de negação de serviço distribuído (DDoS) de curta duração e alto volume na camada 7 (L7). Essas proteções são oferecidas através do grupo de regras gerenciadas Anti-DDoS AMR (Regras Gerenciadas Anti-DDoS da AWS). Embora a configuração padrão seja eficaz para a maioria dos cenários, você pode personalizar a resposta para se adequar à tolerância ao risco da sua aplicação.

Neste artigo, exploraremos como o Anti-DDoS AMR funciona internamente e como você pode ajustar seu comportamento utilizando rótulos e regras adicionais do AWS WAF. Você acompanhará três cenários práticos, cada um demonstrando uma técnica diferente de personalização.

Como o Anti-DDoS AMR funciona

Detecção de anomalias e aplicação de rótulos

O Anti-DDoS AMR estabelece uma linha de base do seu tráfego e a utiliza para detectar anomalias em questão de segundos. Quando um ataque DDoS é identificado, o serviço adiciona metadados às requisições — aquilo que o AWS WAF chama de rótulos. Especificamente, todas as requisições recebem o rótulo event-detected, enquanto as requisições suspeitas de contribuir para o ataque recebem o rótulo ddos-request.

Além disso, rótulos adicionais baseados em confiança são aplicados, como high-suspicion-ddos-request, quando existe alta suspeita de que a requisição faz parte do ataque. Em termos técnicos, um rótulo é um metadado adicionado a uma requisição por uma regra quando ela é correspondida. Após ser adicionado, o rótulo fica disponível para as regras subsequentes, que podem utilizá-lo para enriquecer sua lógica de avaliação.

Estratégias de mitigação padrão

As mitigações padrão combinam dois tipos de ação: bloqueio direto e desafio JavaScript. O desafio funciona apenas com clientes que esperam conteúdo HTML. Por esse motivo, você precisa excluir requisições que não podem ser desafiadas — como chamadas de API — nas configurações do Anti-DDoS AMR. O serviço aplica o rótulo challengeable-request às requisições que não correspondem às exclusões configuradas.

As regras de mitigação padrão são avaliadas na seguinte sequência:

• ChallengeAllDuringEvent: Equivalente à lógica: SE event-detected E challengeable-request, ENTÃO desafiar. Esta regra ativa desafios para todas as requisições elegíveis durante um evento detectado.
• ChallengeDDoSRequests: Equivalente à lógica: SE (high-suspicion-ddos-request OU medium-suspicion-ddos-request OU low-suspicion-ddos-request) E challengeable-request, ENTÃO desafiar. A sensibilidade pode ser ajustada para desafiar apenas requisições de média e alta suspeita.
• DDoSRequests: Equivalente à lógica: SE high-suspicion-ddos-request, ENTÃO bloquear. A sensibilidade pode ser aumentada para bloquear também requisições de média suspeita, por exemplo.

Personalizando sua resposta aos ataques DDoS

Duas abordagens de personalização

Existem dois caminhos principais para personalizar como você responde a ataques DDoS na camada 7. Na primeira abordagem, você configura o Anti-DDoS AMR para a ação desejada e, em seguida, adiciona regras subsequentes para enrijecer ainda mais sua resposta sob condições específicas. Na segunda abordagem, você converte algumas ou todas as regras do Anti-DDoS AMR para modo de contagem e cria regras adicionais que definem sua resposta personalizada.

Em ambas as abordagens, as regras subsequentes são configuradas utilizando condições que você define, combinadas com condições baseadas em rótulos aplicados pelo Anti-DDoS AMR. Para configurar regras com lógica complexa, você precisará usar o editor JSON do AWS WAF ou ferramentas de infraestrutura como código, como AWS CloudFormation ou Terraform.

Exemplo 1: Mitigação mais sensível fora de países principais

Suponha que sua operação ocorra principalmente em dois países: Emirados Árabes Unidos e Arábia Saudita. Você está satisfeito com o comportamento padrão do Anti-DDoS AMR nesses países, mas deseja bloquear mais agressivamente fora deles. Você pode implementar isso com as seguintes regras:

• Anti-DDoS AMR com configurações padrão
• Uma regra customizada que bloqueia se: a requisição vier de fora dos Emirados Árabes Unidos ou Arábia Saudita E a requisição tiver os rótulos high-suspicion-ddos-request ou medium-suspicion-ddos-request

Após adicionar o Anti-DDoS AMR com configuração padrão, crie uma regra customizada subsequente com a seguinte definição JSON:

{
  "Action": {
    "Block": {}
  },
  "Name": "more-sensitive-ddos-mitigation-outside-of-core-countries",
  "Priority": 1,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "NotStatement": {
            "Statement": {
              "GeoMatchStatement": {
                "CountryCodes": [
                  "AE",
                  "SA"
                ]
              }
            }
          }
        },
        {
          "OrStatement": {
            "Statements": [
              {
                "LabelMatchStatement": {
                  "Key": "awswaf:managed:aws:anti-ddos:medium-suspicion-ddos-request",
                  "Scope": "LABEL"
                }
              },
              {
                "LabelMatchStatement": {
                  "Key": "awswaf:managed:aws:anti-ddos:high-suspicion-ddos-request",
                  "Scope": "LABEL"
                }
              }
            ]
          }
        }
      ]
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "more-sensitive-ddos-mitigation-outside-of-core-countries",
    "SampledRequestsEnabled": true
  }
}

De forma similar, durante um ataque, você pode mitigar de forma mais agressiva requisições de fontes incomuns, como aquelas identificadas pelo grupo de regras gerenciadas de reputação de IP como provenientes de provedores de hospedagem e nuvem.

Exemplo 2: Redução de limites de taxa durante ataques DDoS

Imaginemos que sua aplicação possui URLs sensíveis que são computacionalmente intensivas. Para proteger a disponibilidade, você aplicou uma regra de limitação de taxa configurada com um limite de 100 requisições a cada 2 minutos. Você pode enrijecer essa resposta durante um ataque DDoS aplicando um limite mais agressivo. Você pode implementar isso com:

• Anti-DDoS AMR com configurações padrão
• Uma regra de limitação de taxa, restrita às URLs sensíveis, configurada com limite de 100 requisições em janela de 2 minutos
• Uma segunda regra de limitação de taxa, restrita às URLs sensíveis E ao rótulo event-detected, configurada com limite de 10 requisições em janela de 10 minutos

Após adicionar o Anti-DDoS AMR com configuração padrão e sua regra de limitação de taxa para URLs sensíveis, crie uma nova regra de limitação com a seguinte definição JSON:

{
  "Action": {
    "Block": {}
  },
  "Name": "ip-rate-limit-10-10mins-under-ddos",
  "Priority": 2,
  "Statement": {
    "RateBasedStatement": {
      "AggregateKeyType": "IP",
      "EvaluationWindowSec": 600,
      "Limit": 10,
      "ScopeDownStatement": {
        "AndStatement": {
          "Statements": [
            {
              "ByteMatchStatement": {
                "FieldToMatch": {
                  "UriPath": {}
                },
                "PositionalConstraint": "EXACTLY",
                "SearchString": "/sensitive-url",
                "TextTransformations": [
                  {
                    "Priority": 0,
                    "Type": "LOWERCASE"
                  }
                ]
              }
            },
            {
              "LabelMatchStatement": {
                "Key": "awswaf:managed:aws:anti-ddos:event-detected",
                "Scope": "LABEL"
              }
            }
          ]
        }
      }
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "ip-rate-limit-10-10mins-under-ddos",
    "SampledRequestsEnabled": true
  }
}

Exemplo 3: Resposta adaptativa conforme escalabilidade da aplicação

Considere uma aplicação legada que pode escalar com segurança até um certo limite de volume de tráfego, além do qual degrada. Se o volume total de tráfego, incluindo ataque DDoS, estiver abaixo desse limite, você decide não desafiar todas as requisições durante um ataque para evitar impactar a experiência do usuário. Neste cenário, você depende apenas da ação de bloqueio padrão para requisições de alta suspeita. Porém, se o volume total exceder o limite seguro, você ativa a mitigação equivalente a ChallengeDDoSRequests.

Você pode implementar isso com:

• Anti-DDoS AMR com as regras ChallengeAllDuringEvent e ChallengeDDoSRequests configuradas em modo de contagem
• Uma regra de limitação de taxa que conta seu tráfego, configurada com um limite correspondente à capacidade da sua aplicação, que aplica um rótulo customizado — como CapacityExceeded — quando o limite é atingido
• Uma regra que replica ChallengeDDoSRequests, mas apenas quando o rótulo CapacityExceeded está presente: desafiar se os rótulos ddos-request, CapacityExceeded e challengeable-request estão todos presentes

Primeiro, atualize seu Anti-DDoS AMR alterando as ações Challenge para Count.

Em seguida, crie a regra de detecção de capacidade excedida em modo de contagem, usando a seguinte definição JSON:

{
  "Action": {
    "Count": {}
  },
  "Name": "capacity-exceeded-detection",
  "Priority": 7,
  "RuleLabels": [
    {
      "Name": "mycompany:capacityexceeded"
    }
  ],
  "Statement": {
    "RateBasedStatement": {
      "AggregateKeyType": "IP",
      "EvaluationWindowSec": 120,
      "Limit": 10000
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "capacity-exceeded-detection",
    "SampledRequestsEnabled": true
  }
}

Finalmente, crie a regra de desafio usando a seguinte definição JSON:

{
  "Action": {
    "Challenge": {}
  },
  "Name": "challenge-if-ddos-and-capacity-exceeded",
  "Priority": 2,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "LabelMatchStatement": {
            "Key": "mycompany:capacityexceeded",
            "Scope": "LABEL"
          }
        },
        {
          "LabelMatchStatement": {
            "Key": "awswaf:managed:aws:anti-ddos:ddos-request",
            "Scope": "LABEL"
          }
        },
        {
          "LabelMatchStatement": {
            "Key": "awswaf:managed:aws:anti-ddos:challengeable-request",
            "Scope": "LABEL"
          }
        }
      ]
    }
  },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "challenge-if-ddos-and-capacity-exceeded",
    "SampledRequestsEnabled": true
  }
}

Conclusão

Ao combinar as proteções integradas do Anti-DDoS AMR com lógica customizada, você consegue adaptar suas defesas para corresponder ao seu perfil de risco único, padrões de tráfego e escalabilidade da aplicação. Os exemplos apresentados ilustram como você pode ajustar a sensibilidade, aplicar mitigações mais fortes sob condições específicas e até construir defesas adaptativas que respondem dinamicamente à capacidade do seu sistema.

O sistema dinâmico de rótulos no AWS WAF permite implementar essas personalizações de forma granular. Você pode também utilizar rótulos do AWS WAF para excluir o registro custoso de tráfego de ataque DDoS, otimizando sua observabilidade sem sacrificar a segurança.

Fonte

How to customize your response to layer 7 DDoS attacks using AWS WAF Anti-DDoS AMR (https://aws.amazon.com/blogs/security/how-to-customize-your-response-to-layer-7-ddos-attacks-using-aws-waf-anti-ddos-amr/)

O desafio da infraestrutura de chaves públicas em escala

A Infraestrutura de Chaves Públicas (PKI) é fundamental para garantir a segurança e estabelecer confiança nas comunicações digitais. À medida que as organizações expandem suas operações digitais, precisam emitir e revogar certificados continuamente. A revogação de certificados é especialmente importante quando funcionários se desligam, durante migrações para novas hierarquias de autoridades certificadoras, para atender requisitos de conformidade ou em resposta a incidentes de segurança.

Para rastrear certificados revogados, as organizações podem usar a Lista de Revogação de Certificados (CRL) ou o Protocolo de Status de Certificado Online (OCSP). A Autoridade Certificadora Privada da AWS (AWS Private CA) permite criar uma autoridade certificadora que publica informações de revogação através desses métodos, possibilitando que sistemas verifiquem a validade dos certificados.

Porém, empresas que enfrentam crescimento significativo encontram limitações ao usar CRLs completas para emitir e revogar mais de 1 milhão de certificados. Simplesmente aumentar o tamanho do arquivo CRL não é uma solução viável, pois muitas aplicações não conseguem processar arquivos CRL grandes — algumas exigem um máximo de 1 MB. Além disso, soluções alternativas como OCSP podem ser rejeitadas por grandes repositórios de confiança e fornecedores de navegadores devido a preocupações com privacidade e requisitos de conformidade. Essas restrições impactam significativamente a capacidade das organizações de escalar sua infraestrutura de PKI de forma eficiente, mantendo segurança e conformidade.

A solução: CRLs particionadas

A AWS Private CA agora oferece CRLs particionadas como resposta a esses desafios. Essa funcionalidade permite a emissão e revogação de até 100 milhões de certificados por CA, distribuindo as informações de revogação em múltiplas partições de CRL menores e gerenciáveis, cada uma mantendo um tamanho máximo de 1 MB para melhor compatibilidade com aplicações.

No momento da emissão, os certificados são automaticamente vinculados a partições CRL específicas através de uma extensão crítica de Ponto de Distribuição do Emissor (IDP), que contém uma URI única identificando a partição. A validação funciona comparando a URI de CRL na extensão de Ponto de Distribuição de CRL (CDP) do certificado contra a extensão IDP da CRL, proporcionando validação precisa.

Capacidades principais da nova funcionalidade

As CRLs particionadas oferecem diversos benefícios operacionais:

• Escalabilidade automática do limite de emissão de certificados: de 1 milhão para 100 milhões de certificados por CA
• Suporte tanto para novas quanto para autoridades certificadoras existentes
• Opções de configuração flexível para nomes e caminhos de CRL
• Compatibilidade reversa, preservando a funcionalidade completa de CRL existente enquanto oferece CRL particionada como recurso opcional
• Conformidade com padrões da indústria, como o RFC5280, mantendo eficiência operacional e segurança

Configurando CRLs particionadas na AWS Private CA

A configuração de CRLs particionadas em autoridades certificadoras existentes segue um processo estruturado através do console da AWS:

Passos de configuração

Para ativar CRLs particionadas, acesse sua autoridade certificadora privada no console da AWS Private CA. Primeiro, selecione a CA desejada e navegue até a aba de configuração de revogação. Se a distribuição de CRL estiver desabilitada, você precisará ativá-la nos próximos passos.

Ao editar as configurações, marque a opção para ativar distribuição de CRL e selecione um bucket do Amazon S3 existente para armazenar os arquivos de CRL. É importante verificar que o recurso de Bloqueio de Acesso Público está desabilitado para sua conta e para o bucket. Se necessário, você pode consultar a documentação sobre criar uma CA privada na AWS Private CA para obter instruções detalhadas sobre políticas de acesso. Para configurações de segurança mais específicas, consulte o guia sobre políticas de acesso para CRLs no Amazon S3 e aprenda como adicionar uma política de bucket usando o console do Amazon S3.

Na seção de configurações de CRL, marque a caixa para ativar o particionamento. Isso habilitará o uso de CRL particionada. Se você não ativar o particionamento, uma CRL completa será criada e sua CA ficará sujeita ao limite de 1 milhão de certificados emitidos ou revogados. Para informações sobre limites de capacidade, consulte as cotas da AWS Private CA.

Após salvar as alterações, a distribuição de CRL aparecerá como habilitada com CRLs particionadas, e o limite de 1 milhão será automaticamente atualizado para 100 milhões por CA.

Benefícios para segurança, operações e conformidade

As CRLs particionadas da AWS Private CA oferecem benefícios substanciais em múltiplas dimensões organizacionais.

Perspectiva de segurança

A funcionalidade mantém a validação de certificados enquanto suporta capacidades abrangentes de revogação para até 100 milhões de certificados por CA. Isso permite que as organizações respondam efetivamente a incidentes de segurança ou comprometimento de chaves.

Perspectiva operacional

Operacionalmente, o recurso reduz a necessidade de rotação de autoridades certificadoras, diminuindo a sobrecarga administrativa e simplificando o gerenciamento de PKI. Manter os tamanhos de partição de CRL em 1 MB oferece compatibilidade ampla com aplicações, enquanto suporta gerenciamento automático de partições.

Perspectiva de conformidade

Para conformidade regulatória, a solução permite que as organizações atendam a múltiplos requisitos da indústria:

• Suporte aos princípios e critérios de WebTrust
• Conformidade com os padrões ETSI TSP
• Compatibilidade com o RFC5280
• Alinhamento com requisitos de repositórios de confiança de navegadores para suporte tanto a CRL quanto a OCSP
• Flexibilidade para padrões emergentes, como Matter

Custo e disponibilidade

Um ponto importante é que você pode maximizar o valor de suas autoridades certificadoras de propósito geral ou vida curta ativando CRL particionada sem custos adicionais, além da AWS Private CA e do Amazon Simple Storage Service (Amazon S3). Todos os certificados continuam sendo revogáveis, proporcionando uma solução completa e econômica para gestão de PKI em escala.

Próximos passos

Organizações interessadas em começar podem criar sua autoridade certificadora através do console de gerenciamento da AWS Private CA. A nova funcionalidade está disponível para configuração imediata em autoridades certificadoras existentes ou novas.

Fonte

AWS Private Certificate Authority now supports partitioned CRLs (https://aws.amazon.com/blogs/security/aws-private-certificate-authority-now-supports-partitioned-crls/)

Uma nova forma de gerenciar secrets no Kubernetes

A AWS anunciou um novo provedor para o Secrets Store CSI Driver destinado ao Amazon EKS (Elastic Kubernetes Service), que funciona como um add-on gerenciado para a plataforma. Esse novo componente permite que as equipes de desenvolvimento recuperem secrets do AWS Secrets Manager e parâmetros do AWS Systems Manager Parameter Store, montando-os como arquivos nos pods do Kubernetes. A solução é clara em sua proposta: oferecer uma forma segura, confiável e gerenciada de acessar credenciais dentro de ambientes containerizados.

O novo add-on simplifica significativamente o processo de instalação e configuração, funciona tanto em instâncias de Amazon Elastic Compute Cloud (EC2) quanto em nós híbridos, e é mantido com as correções de segurança e atualizações mais recentes. Para equipes brasileiras que trabalham com Kubernetes em ambientes AWS, isso representa uma redução considerável no tempo necessário para implementar práticas seguras de gestão de credenciais.

Por que isso importa para a segurança

Historicamente, um dos maiores desafios em ambientes Kubernetes é evitar o uso de credenciais hardcoded no código-fonte das aplicações. O Secrets Manager já resolve essa questão no contexto geral da AWS, mas integrá-lo nativamente com Kubernetes exigia passos complexos de instalação e manutenção.

O novo provedor funciona como um DaemonSet do Kubernetes de código aberto, trabalhando em conjunto com o Secrets Store CSI Driver mantido pela comunidade Kubernetes. Essa arquitetura permite que o driver de armazenamento de secrets funcione de forma nativa no cluster, sem necessidade de integração customizada.

Benefícios do add-on gerenciado

Os add-ons do EKS da AWS proporcionam instalação e gerenciamento de um conjunto curado de componentes para clusters EKS. Em vez de depender de métodos legados como Helm ou kubectl, o novo add-on reduz significativamente o tempo de setup e aumenta a estabilidade geral dos clusters. Além disso, o gerenciamento centralizado pela AWS garante que patches de segurança e correções de bugs sejam aplicados de forma automática e consistente.

Considerações de segurança

Como em qualquer solução que envolve gestão de credenciais, a segurança é uma preocupação central. A AWS recomenda armazenar secrets em cache na memória quando possível, reduzindo a frequência de acesso ao Secrets Manager. Para equipes que preferem uma experiência totalmente nativa do Kubernetes, o AWS Secrets Manager Agent oferece uma alternativa complementar.

Do ponto de vista de controle de acesso, qualquer entidade IAM (Identity and Access Management) que precise acessar os secrets deve ter permissões explícitas no Secrets Manager. Se usar Parameter Store, também precisa de permissões específicas para ler parâmetros. As políticas de recurso funcionam como mecanismo adicional de controle de acesso, e é especialmente importante quando se acessa secrets de contas AWS diferentes.

O add-on inclui suporte a endpoints FIPS, alinhando-se com exigências de conformidade em ambientes altamente regulados. A AWS fornece uma política IAM gerenciada chamada AWSSecretsManagerClientReadOnlyAccess, que é a recomendação padrão para uso com esse add-on. Para implementar o princípio do menor privilégio, é possível criar políticas customizadas direcionadas apenas aos secrets específicos que cada aplicação precisa acessar.

Guia prático de implementação

Para equipes que desejam começar, a AWS disponibiliza um fluxo de trabalho completo desde a criação do cluster até a recuperação efetiva de um secret. Abaixo, apresentamos um resumo dos passos principais.

Pré-requisitos

Antes de iniciar, certifique-se de ter:

• Credenciais AWS configuradas no seu ambiente para permitir chamadas à API
• AWS CLI v2 ou superior
• A região preferida configurada no seu ambiente via comando: aws configure set default.region <regiao-preferida>
• As ferramentas de linha de comando kubectl e eksctl instaladas
• Um arquivo de deployment Kubernetes disponível no repositório do provedor

Criando o cluster EKS

Comece criando uma variável de shell com o nome do seu cluster:

CLUSTER_NAME="my-test-cluster"

Depois, crie o cluster:

eksctl create cluster $CLUSTER_NAME

O eksctl usará automaticamente uma versão recente do Kubernetes e criará todos os recursos necessários para o funcionamento do cluster. Esse comando geralmente leva cerca de 15 minutos.

Criando um secret de teste

Crie um secret chamado addon_secret no Secrets Manager:

aws secretsmanager create-secret \
--name addon_secret \
--secret-string "super secret!"

Instalando o add-on do Secrets Store CSI Driver

Use o eksctl para instalar o add-on:

eksctl create addon \
--cluster $CLUSTER_NAME \
--name aws-secrets-store-csi-driver-provider

Configurando autenticação com IAM e Pod Identity

Crie uma role IAM que o serviço de Pod Identity do EKS possa assumir (substitua <regiao> pela sua região AWS):

ROLE_ARN=$(aws --region <regiao> --query Role.Arn --output text iam create-role --role-name nginx-deployment-role --assume-role-policy-document '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}')

Anexe a política gerenciada à role que você acabou de criar:

aws iam attach-role-policy \
--role-name nginx-deployment-role \
--policy-arn arn:aws:iam::aws:policy/AWSSecretsManagerClientReadOnlyAccess

Instalando o EKS Pod Identity Agent

O add-on oferece dois métodos de autenticação: IAM roles para service accounts (IRSA) e EKS Pod Identity. Neste exemplo, usaremos Pod Identity. Instale o agent:

eksctl create addon \
--cluster $CLUSTER_NAME \
--name eks-pod-identity-agent

Depois, crie a associação de Pod Identity para o cluster (substituindo <regiao> pela sua região):

eksctl create podidentityassociation \
--cluster $CLUSTER_NAME \
--namespace default \
--region <regiao> \
--service-account-name nginx-pod-identity-deployment-sa \
--role-arn $ROLE_ARN \
--create-service-account true

Configurando a SecretProviderClass

A SecretProviderClass é um arquivo YAML que define quais secrets e parâmetros devem ser montados como arquivos no seu cluster. Crie um arquivo chamado spc.yaml com o seguinte conteúdo:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: nginx-pod-identity-deployment-aws-secrets
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "addon_secret"
        objectType: "secretsmanager"
        usePodIdentity: "true"

Aplique a configuração:

kubectl apply -f spc.yaml

Para detalhes adicionais sobre a SecretProviderClass, consulte a documentação no GitHub do provedor.

Implantando o pod no cluster

Use o arquivo de deployment disponível no repositório para implantar o pod:

kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleDeployment-PodIdentity.yaml

Isso montará o addon_secret no caminho /mnt/secrets-store dentro do seu cluster.

Recuperando e verificando o secret

Para confirmar que o secret foi montado com sucesso, execute:

kubectl exec -it $(kubectl get pods | awk '/nginx-pod-identity-deployment/{print $1}' | head -1) -- cat /mnt/secrets-store/addon_secret

Você deverá ver a saída:

super secret!

Parabéns! Você recuperou com sucesso um secret do Secrets Manager e o montou como arquivo no seu cluster Kubernetes usando o novo add-on da AWS.

Limpeza de recursos

Quando terminar a implementação de testes, limpe os recursos criados:

aws secretsmanager delete-secret \
--secret-id addon_secret \
--force-delete-without-recovery

aws iam delete-role --role-name nginx-deployment-role

eksctl delete cluster $CLUSTER_NAME

Alternativas de instalação

Embora o add-on gerenciado seja a forma recomendada, a AWS também oferece opções alternativas de instalação usando AWS CloudFormation, AWS Command Line Interface (AWS CLI), console de gerenciamento ou a própria API do EKS.

Conclusão

O novo add-on do Secrets Store CSI Driver para EKS representa um avanço significativo na forma como as equipes podem gerenciar credenciais em ambientes Kubernetes hospedados na AWS. Ao oferecer instalação simplificada, gerenciamento centralizado, atualizações de segurança automáticas e integração estreita com o EKS, a solução reduz tanto a complexidade operacional quanto o risco de segurança associado ao armazenamento inadequado de secrets.

Para organizações brasileiras que trabalham com Kubernetes em escala, esse add-on se posiciona como uma alternativa muito mais prática do que métodos legados de instalação, mantendo a flexibilidade e a conformidade com padrões de segurança internacionais. A documentação técnica completa está disponível para equipes que desejam explorar cenários mais avançados e configurações específicas.

Saiba mais

• Amazon EKS add-ons: configuração avançada
• Considerações adicionais de segurança no GitHub
• Documentação do AWS Secrets Manager
• AWS Security Blog

Fonte

How to use the Secrets Store CSI Driver provider Amazon EKS add-on with Secrets Manager (https://aws.amazon.com/blogs/security/how-to-use-the-secrets-store-csi-driver-provider-amazon-eks-add-on-with-secrets-manager/)