Conceitos - Autoridade de Certificação Privada da AWS

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Conceitos

O diagrama a seguir mostra algumas das opções disponíveis para usar o TLS em um cluster do Amazon EKS. O cluster de exemplo fica atrás de um balanceador de carga. Os números identificam possíveis endpoints para comunicações protegidas por TLS.

Um diagrama mostrando os possíveis endpoints para criptografia TLS. Cada endpoint tem um número que corresponde à lista a seguir.
  1. Terminação no balanceador de carga

    O Elastic Load Balancing (ELB) está integrado ao serviço. AWS Certificate Manager Você não precisa instalar cert-manager no balanceador de carga. Você pode provisionar o ACM com uma CA privada, assinar um certificado com a CA privada e instalar o certificado usando o console do ELB. CA Privada da AWS os certificados são renovados automaticamente.

    Como alternativa, você pode fornecer um certificado privado a um balanceador sem AWS carga para encerrar o TLS.

    Isso fornece comunicação criptografada entre um cliente remoto e o balanceador de carga. Os dados após o balanceador de carga serem passados sem criptografia para o cluster Amazon EKS.

  2. Rescisão no controlador de entrada do Kubernetes

    O controlador de entrada está dentro do cluster Amazon EKS e atua como um balanceador de carga e roteador. Para usar o controlador de entrada como o endpoint do cluster para comunicação externa, você deve:

    • Instale ambos cert-manager e aws-privateca-issuer

    • Provisione o controlador com um certificado privado TLS do CA Privada da AWS.

    As comunicações entre o balanceador de carga e o controlador de entrada são criptografadas, os dados passam sem criptografia para os recursos do cluster.

  3. Rescisão em um pod

    Cada pod é um grupo de um ou mais contêineres que compartilham recursos de rede e armazenamento. Se você instalar cert-manager aws-privateca-issuer e provisionar o cluster com uma CA privada, o Kubernetes poderá instalar um certificado privado TLS assinado nos pods, conforme necessário. Por padrão, uma conexão TLS terminada em um pod não está disponível para outros pods no cluster.

  4. Comunicações seguras entre pods.

    Você pode provisionar vários pods com certificados para permitir que eles se comuniquem entre si. Os cenários a seguir são possíveis:

    • O provisionamento com o Kubernetes gerou certificados autoassinados. Isso protege as comunicações entre os pods, mas os certificados autoassinados não atendem aos requisitos HIPAA ou FIPS.

    • Provisionamento com certificados assinados por. CA Privada da AWS Isso requer a instalação de ambos cert-manager aws-privateca-issuer e. O Kubernetes pode então instalar certificados mTLS assinados nos pods, conforme necessário.