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á.

Segurança de rede

A segurança da rede tem várias facetas. A primeira envolve a aplicação de regras que restringem o fluxo de tráfego de rede entre os serviços. A segunda envolve a criptografia do tráfego enquanto ele está em trânsito. Os mecanismos para implementar essas medidas de segurança no EKS são variados, mas geralmente incluem os seguintes itens:

Controle de tráfego

Criptografia de rede

Política de rede

Em um cluster Kubernetes, toda comunicação de pod a pod é permitida por padrão. Embora essa flexibilidade possa ajudar a promover a experimentação, ela não é considerada segura. As políticas de rede do Kubernetes oferecem um mecanismo para restringir o tráfego de rede entre pods (geralmente chamado de East/West tráfego), bem como entre pods e serviços externos. As políticas de rede do Kubernetes operam nas camadas 3 e 4 do modelo OSI. As políticas de rede usam seletores de pod, namespace e rótulos para identificar os pods de origem e destino, mas também podem incluir endereços IP, números de porta, protocolos ou uma combinação deles. As políticas de rede podem ser aplicadas às conexões de entrada e saída do pod, geralmente chamadas de regras de entrada e saída.

Com o suporte nativo à política de rede do Amazon VPC CNI Plugin, você pode implementar políticas de rede para proteger o tráfego de rede em clusters kubernetes. Isso se integra à API upstream Kubernetes Network Policy, garantindo compatibilidade e aderência aos padrões do Kubernetes. Você pode definir políticas usando identificadores diferentes suportados pela API upstream. Por padrão, todo o tráfego de entrada e saída é permitido em um pod. Quando uma política de rede com um PolicyType Ingress é especificada, somente as conexões permitidas no pod são aquelas do node do pod e aquelas permitidas pelas regras de entrada. O mesmo se aplica às regras de saída. Se várias regras forem definidas, a união de todas as regras será levada em consideração ao tomar a decisão. Assim, a ordem de avaliação não afeta o resultado da política.

Recomendações

Introdução às políticas de rede - siga o princípio do menor privilégio

Crie uma política de negação padrão

Assim como acontece com as políticas do RBAC, é recomendável seguir os princípios de acesso menos privilegiado com as políticas de rede. Comece criando uma política de negação de tudo que restringe todo o tráfego de entrada e saída em um namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

negação padrão

Crie uma regra para permitir consultas de DNS

Depois de definir a regra padrão de negar tudo, você pode começar a criar camadas de regras adicionais, como uma regra que permite que os pods consultem o CoreDNS para resolução de nomes.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-access
  namespace: default
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

permitir acesso ao DNS

Adicione regras de forma incremental para permitir seletivamente o fluxo de tráfego entre namespaces/pods

Entenda os requisitos do aplicativo e crie regras de entrada e saída refinadas conforme necessário. O exemplo abaixo mostra como restringir o tráfego de entrada na porta 80 para app-one fromclient-one. Isso ajuda a minimizar a superfície de ataque e reduz o risco de acesso não autorizado.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-app-one
  namespace: default
spec:
  podSelector:
    matchLabels:
      k8s-app: app-one
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          k8s-app: client-one
    ports:
    - protocol: TCP
      port: 80

allow-ingress-app-one

Monitorando a aplicação da política de rede

package kubernetes.admission
import data.kubernetes.networkpolicies

deny[msg] {
    input.request.kind.kind == "Pod"
    pod_label_value := {v["k8s-app"] | v := input.request.object.metadata.labels}
    contains_label(pod_label_value, "sample-app")
    np_label_value := {v["k8s-app"] | v := networkpolicies[_].spec.podSelector.matchLabels}
    not contains_label(np_label_value, "sample-app")
    msg:= sprintf("The Pod %v could not be created because it is missing an associated Network Policy.", [input.request.object.metadata.name])
}
contains_label(arr, val) {
    arr[_] == val
}

Solução de problemas

Monitore os registros do controlador de política de rede vpc-network-policy e do node-agent

Ative os registros do gerenciador do controlador do plano de controle EKS para diagnosticar a funcionalidade da política de rede. Você pode transmitir os registros do plano de controle para um grupo de CloudWatch registros e usar o CloudWatch Log Insights para realizar consultas avançadas. Nos registros, você pode ver quais objetos de endpoint do pod são resolvidos para uma política de rede, o status de reconciliação das políticas e depurar se a política está funcionando conforme o esperado.

Além disso, o Amazon VPC CNI permite que você habilite a coleta e exportação de registros de aplicação de políticas para o Amazon Cloudwatch a partir dos nós de trabalho do EKS. Depois de ativado, você pode aproveitar o CloudWatch Container Insights para fornecer informações sobre seu uso relacionado às políticas de rede.

O Amazon VPC CNI também fornece um SDK que fornece uma interface para interagir com programas eBPF no nó. O SDK é instalado quando o aws-node é implantado nos nós. Você pode encontrar o binário do SDK instalado no /opt/cni/bin diretório do nó. No lançamento, o SDK fornece suporte para funcionalidades fundamentais, como a inspeção de programas e mapas do eBPF.

sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Registrar metadados de tráfego de rede

O AWS VPC Flow Logs captura metadados sobre o tráfego que flui por meio de uma VPC, como endereço IP e porta de origem e destino junto com pacotes. accepted/dropped Essas informações podem ser analisadas para procurar atividades suspeitas ou incomuns entre recursos dentro da VPC, incluindo pods. No entanto, como os endereços IP dos pods mudam frequentemente à medida que são substituídos, os registros de fluxo podem não ser suficientes por si só. O Calico Enterprise estende os registros de fluxo com rótulos de pods e outros metadados, facilitando a decifração dos fluxos de tráfego entre os pods.

Grupos de segurança

O EKS usa grupos de segurança (SGs) do AWS VPC para controlar o tráfego entre o plano de controle do Kubernetes e os nós de trabalho do cluster. Os grupos de segurança também são usados para controlar o tráfego entre os nós de trabalho, outros recursos da VPC e endereços IP externos. Quando você provisiona um cluster EKS (com Kubernetes versão 1.14-eks.3 ou superior), um grupo de segurança de cluster é criado automaticamente para você. Esse grupo de segurança permite a comunicação irrestrita entre o plano de controle do EKS e os nós dos grupos de nós gerenciados. Para simplificar, é recomendável adicionar o cluster SG a todos os grupos de nós, incluindo grupos de nós não gerenciados.

Antes da versão 1.14 do Kubernetes e da versão eks.3 do EKS, havia grupos de segurança separados configurados para o plano de controle e grupos de nós do EKS. As regras mínimas e sugeridas para os grupos de segurança do plano de controle e do grupo de nós podem ser encontradas em https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html. As regras mínimas para o grupo de segurança do plano de controle permitem a entrada da porta 443 do nó de trabalho SG. Essa regra é o que permite que os kubelets se comuniquem com o servidor da API Kubernetes. Também inclui a porta 10250 para tráfego de saída para o node de trabalho SG; 10250 é a porta na qual os kubelets escutam. Da mesma forma, as regras mínimas do grupo de nós permitem a entrada da porta 10250 do plano de controle SG e 443 de saída para o plano de controle SG. Finalmente, há uma regra que permite a comunicação irrestrita entre nós dentro de um grupo de nós.

Se você precisar controlar a comunicação entre os serviços que são executados dentro do cluster e os serviços executados fora do cluster, como um banco de dados RDS, considere grupos de segurança para pods. Com grupos de segurança para pods, você pode atribuir um grupo de segurança existente a uma coleção de pods.

Você pode controlar quais pods são atribuídos a um grupo de segurança criando um SecurityGroupPolicy objeto e especificando um PodSelector ou a. ServiceAccountSelector Definir os seletores para {} atribuirá os SGs referenciados em a todos os pods em um namespace ou SecurityGroupPolicy a todas as contas de serviço em um namespace. Certifique-se de se familiarizar com todas as considerações antes de implementar grupos de segurança para pods.

Embora os grupos de segurança para pods ofereçam uma AWS-native maneira de controlar o tráfego de rede dentro e fora do cluster sem a sobrecarga de um daemon de política, outras opções estão disponíveis. Por exemplo, o mecanismo de política Cilium permite que você faça referência a um nome DNS em uma política de rede. O Calico Enterprise inclui uma opção para mapear políticas de rede para grupos de segurança da AWS. Se você implementou uma malha de serviços como o Istio, pode usar um gateway de saída para restringir a saída da rede a domínios ou endereços IP específicos e totalmente qualificados. Para obter mais informações sobre essa opção, leia a série de três partes sobre controle de tráfego de saída no Istio.

Quando usar a Política de Rede versus o Grupo de Segurança para pods?

Quando usar a política de rede do Kubernetes

Quando usar grupos de segurança da AWS para pods (SGP)

Práticas recomendadas usando grupos de segurança para pods e política de rede

Quando se trata de segurança de rede, uma abordagem em camadas geralmente é a solução mais eficaz. Usar a política de rede kubernetes e o SGP em combinação pode fornecer uma estratégia robusta de defesa aprofundada para seus aplicativos executados no EKS.

Aplicação da política de Service Mesh ou política de rede Kubernetes

service meshA é uma camada de infraestrutura dedicada que você pode adicionar aos seus aplicativos. Ele permite que você adicione de forma transparente recursos como observabilidade, gerenciamento de tráfego e segurança, sem adicioná-los ao seu próprio código.

O service mesh impõe políticas na camada 7 (aplicação) do modelo OSI, enquanto as políticas de rede kubernetes operam na camada 3 (rede) e na camada 4 (transporte). Há muitas ofertas nesse espaço, como AWSAppMesh, Istio, Linkerd etc.,

Quando usar o Service Mesh para aplicação de políticas

Escolha a política de rede do Kubernetes para casos de uso mais simples

ThirdParty Mecanismos de política de rede

Considere um mecanismo de política de rede de terceiros quando você tiver requisitos de política avançados, como políticas globais de rede, suporte para regras baseadas em nomes de host DNS, regras de camada 7, regras ServiceAccount baseadas e deny/log ações explícitas, etc., o Calico é um mecanismo de políticas de código aberto da Tigera que funciona bem com o EKS. Além de implementar o conjunto completo de recursos de política de rede do Kubernetes, o Calico oferece suporte a políticas de rede estendidas com um conjunto mais rico de recursos, incluindo suporte para regras de camada 7, por exemplo, HTTP, quando integrado ao Istio. As políticas do Calico podem ter como escopo namespaces, pods, contas de serviço ou globalmente. Quando as políticas têm como escopo uma conta de serviço, ela associa um conjunto de ingress/egress regras a essa conta de serviço. Com as regras adequadas do RBAC em vigor, você pode evitar que as equipes ignorem essas regras, permitindo que os profissionais de segurança de TI deleguem com segurança a administração de namespaces. A Isovalent, mantenedora do Cilium, também estendeu as políticas de rede para incluir suporte parcial às regras da camada 7, por exemplo, HTTP. O Cilium também tem suporte para nomes de host DNS, o que pode ser útil para restringir o tráfego entre o Kubernetes Services/Pods e os recursos que são executados dentro ou fora da sua VPC. Por outro lado, o Calico Enterprise inclui um recurso que permite mapear uma política de rede do Kubernetes para um grupo de segurança da AWS, bem como nomes de host DNS.

Você pode encontrar uma lista de políticas de rede comuns do Kubernetes em https://github.com/ahmetb/kubernetes-network-policy-recipes. Um conjunto similar de regras para o Calico está disponível em https://docs.projectcalico.org/security/calico-network-policy.

Migração para o mecanismo de política de rede CNI da Amazon VPC

Para manter a consistência e evitar um comportamento inesperado de comunicação do pod, é recomendável implantar somente um mecanismo de política de rede em seu cluster. Se você quiser migrar do 3P para o VPC CNI Network Policy Engine, recomendamos converter seus NetworkPolicy CRDs 3P existentes nos recursos do NetworkPolicy Kubernetes antes de ativar o suporte à política de rede VPC CNI. Além disso, teste as políticas migradas em um cluster de teste separado antes de aplicá-las em seu ambiente de produção. Isso permite que você identifique e resolva possíveis problemas ou inconsistências no comportamento de comunicação do pod.

Ferramenta de migração

Para ajudar no processo de migração, desenvolvemos uma ferramenta chamada K8s Network Policy Migrator que converte seus CRDs de política de Calico/Cilium rede existentes em políticas de rede nativas do Kubernetes. Após a conversão, você pode testar diretamente as políticas de rede convertidas em seus novos clusters executando o controlador de política de rede VPC CNI. A ferramenta foi projetada para ajudar você a simplificar o processo de migração e garantir uma transição tranquila.

Observe que a ferramenta de migração atualmente não é suportada pela equipe de engenharia de políticas de rede CNI da AWS VPC. Ela é disponibilizada aos clientes da melhor maneira possível. Recomendamos que você utilize essa ferramenta para facilitar seu processo de migração. Caso você encontre algum problema ou bug com a ferramenta, pedimos que você crie um GitHub problema. Seu feedback é inestimável para nós e ajudará na melhoria contínua de nossos serviços.

Recursos adicionais

Criptografia em trânsito

Os aplicativos que precisam estar em conformidade com PCI, HIPAA ou outros regulamentos podem precisar criptografar dados enquanto eles estão em trânsito. Atualmente, o TLS é a escolha de fato para criptografar o tráfego na rede. O TLS, assim como seu antecessor, o SSL, fornece comunicações seguras em uma rede usando protocolos criptográficos. O TLS usa criptografia simétrica, na qual as chaves para criptografar os dados são geradas com base em um segredo compartilhado que é negociado no início da sessão. Veja a seguir algumas maneiras de criptografar dados em um ambiente Kubernetes.

Instâncias Nitro

O tráfego trocado entre os seguintes tipos de instância Nitro, por exemplo, C5n, G4, I3en, M5dn, M5n, P3dn, R5dn e R5n, é criptografado automaticamente por padrão. Quando há um salto intermediário, como um gateway de trânsito ou um balanceador de carga, o tráfego não é criptografado. Consulte Criptografia em trânsito para obter mais detalhes sobre criptografia em trânsito, bem como a lista completa dos tipos de instâncias que oferecem suporte à criptografia de rede por padrão.

Malha de serviços

A criptografia em trânsito também pode ser implementada com uma malha de serviços como App Mesh, Linkerd v2 e Istio. AppMesh suporta mTLS com X.509 certificados ou o Envoy's Secret Discovery Service (SDS). Tanto o Linkerd quanto o Istio têm suporte para mTLS.

O GitHub repositório aws-app-mesh-examples fornece orientações para configurar mTLS usando certificados e SPIRE como provedor de SDS com seu contêiner Envoy: X.509

O App Mesh também oferece suporte à criptografia TLS com um certificado privado emitido pelo AWS Certificate Manager (ACM) ou um certificado armazenado no sistema de arquivos local do nó virtual.

O GitHub repositório aws-app-mesh-examples fornece orientações para configurar o TLS usando certificados emitidos pelo ACM e certificados fornecidos com seu contêiner Envoy:

Controladores de entrada e balanceadores de carga

Os controladores de entrada são uma forma inteligente de rotear o HTTP/S tráfego que emana de fora do cluster para os serviços executados dentro do cluster. Muitas vezes, essas entradas são lideradas por um balanceador de carga de camada 4, como o Classic Load Balancer ou o Network Load Balancer (NLB). O tráfego criptografado pode ser encerrado em diferentes locais da rede, por exemplo, no balanceador de carga, no recurso de entrada ou no pod. Como e onde você encerra sua conexão SSL, em última análise, será determinado pela política de segurança de rede da sua organização. Por exemplo, se você tiver uma política que exija criptografia de ponta a ponta, precisará descriptografar o tráfego no pod. Isso sobrecarregará ainda mais seu Pod, pois ele precisará passar ciclos estabelecendo o aperto de mão inicial. O SSL/TLS processamento geral consome muito da CPU. Consequentemente, se você tiver flexibilidade, tente realizar o descarregamento SSL no Ingress ou no balanceador de carga.

Use criptografia com os balanceadores de carga do AWS Elastic

Tanto o AWS Application Load Balancer (ALB) quanto o Network Load Balancer (NLB) têm suporte para criptografia de transporte (SSL e TLS). A alb.ingress.kubernetes.io/certificate-arn anotação para o ALB permite que você especifique quais certificados adicionar ao ALB. Se você omitir a anotação, o controlador tentará adicionar certificados aos ouvintes que a exijam, combinando os certificados do AWS Certificate Manager (ACM) disponíveis usando o campo host. Começando com o EKS v1.15, você pode usar a service.beta.kubernetes.io/aws-load-balancer-ssl-cert anotação com o NLB, conforme mostrado no exemplo abaixo.

apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: default
  labels:
    app: demo-app
  annotations:
     service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<certificate ARN>"
     service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec:
  type: LoadBalancer
  ports:
  - port: 443
    targetPort: 80
    protocol: TCP
  selector:
    app: demo-app
//---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
  namespace: default
  labels:
    app: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 443
              protocol: TCP
            - containerPort: 80
              protocol: TCP

Veja a seguir exemplos adicionais de SSL/TLS rescisão.

CA privada do ACM com gerenciador de certificados

Você pode ativar o TLS e o mTLS para proteger suas cargas de trabalho do aplicativo EKS na entrada, no pod e entre os pods usando a ACM Private Certificate Authority (CA) e o cert-manager, um complemento popular do Kubernetes para distribuir, renovar e revogar certificados. A CA privada do ACM é uma CA gerenciada, segura e altamente disponível, sem os custos iniciais e de manutenção de gerenciar sua própria CA. Se você estiver usando a autoridade de certificação padrão do Kubernetes, há uma oportunidade de melhorar sua segurança e atender aos requisitos de conformidade com a CA privada do ACM. A CA privada do ACM protege as chaves privadas nos módulos de segurança de hardware FIPS 140-2 de nível 3 (muito seguros), em comparação com a CA padrão que armazena chaves codificadas na memória (menos segura). Uma CA centralizada também oferece mais controle e melhor auditabilidade para certificados privados dentro e fora de um ambiente Kubernetes.

Short-Lived Modo CA para TLS mútuo entre cargas de trabalho

Ao usar a CA privada do ACM para mTLS no EKS, é recomendável usar certificados de curta duração com o modo CA de curta duração. Embora seja possível emitir certificados de curta duração no modo CA de uso geral, usar o modo CA de curta duração é mais econômico (~ 75% mais barato do que o modo geral) para casos de uso em que novos certificados precisam ser emitidos com frequência. Além disso, você deve tentar alinhar o período de validade dos certificados privados com a vida útil dos pods em seu cluster EKS. Saiba mais sobre a CA privada do ACM e seus benefícios aqui.

Instruções de configuração do ACM

Comece criando uma CA privada seguindo os procedimentos fornecidos nos documentos técnicos da CA privada do ACM. Depois de ter uma CA privada, instale o cert-manager usando as instruções de instalação regulares. Depois de instalar o cert-manager, instale o plug-in Private CA Kubernetes cert-manager seguindo as instruções de configuração em. GitHub O plug-in permite que o cert-manager solicite certificados privados da CA privada do ACM.

Agora que você tem uma CA privada e um cluster EKS com o cert-manager e o plug-in instalados, é hora de definir as permissões e criar o emissor. Atualize as permissões do IAM da função do nó EKS para permitir o acesso à CA privada do ACM. <CA_ARN>Substitua o pelo valor da sua CA privada:

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:acm-pca:us-west-2:123456789012:certificate-authority/12345678-1234-1234-1234-123456789012"
        }
    ]
}

As funções de serviço para contas do IAM ou IRSA também podem ser usadas. Consulte a seção Recursos adicionais abaixo para obter exemplos completos.

Crie um emissor no Amazon EKS criando um arquivo de definição de recurso personalizado chamado cluster-issuer.yaml com o seguinte texto nele, substituindo as informações com sua CA privada. <CA_ARN> <Region>

apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
          name: demo-test-root-ca
spec:
          arn: <CA_ARN>
          region: <Region>

Implante o emissor que você criou.

kubectl apply -f cluster-issuer.yaml

Seu cluster EKS está configurado para solicitar certificados da CA privada. Agora você pode usar o Certificate recurso do cert-manager para emitir certificados alterando os valores do issuerRef campo para o emissor de CA privado que você criou acima. Para obter mais detalhes sobre como especificar e solicitar recursos de certificados, consulte o guia de recursos de certificados do cert-manager. Veja exemplos aqui.

CA privada do ACM com Istio e gerenciador de certificados

Se você estiver executando o Istio em seu cluster EKS, poderá desativar o plano de controle do Istio (especificamenteistiod) de funcionar como autoridade de certificação (CA) raiz e configurar a CA privada do ACM como a CA raiz para mTLS entre cargas de trabalho. Se você optar por essa abordagem, considere usar o modo CA de curta duração na CA privada do ACM. Consulte a seção anterior e esta postagem do blog para obter mais detalhes.

Como funciona a assinatura de certificados no Istio (padrão)

As cargas de trabalho no Kubernetes são identificadas usando contas de serviço. Se você não especificar uma conta de serviço, o Kubernetes atribuirá automaticamente uma à sua carga de trabalho. Além disso, as contas de serviço montam automaticamente um token associado. Esse token é usado pela conta de serviço para que as cargas de trabalho sejam autenticadas na API Kubernetes. A conta de serviço pode ser suficiente como identidade para o Kubernetes, mas o Istio tem seu próprio sistema de gerenciamento de identidade e CA. Quando uma carga de trabalho é iniciada com seu proxy auxiliar de envio, ela precisa de uma identidade atribuída pelo Istio para ser considerada confiável e ter permissão para se comunicar com outros serviços na malha.

Para obter essa identidade do Istio, istio-agent ele envia uma solicitação conhecida como solicitação de assinatura de certificado (ou CSR) para o plano de controle do Istio. Essa CSR contém o token da conta de serviço para que a identidade da carga de trabalho possa ser verificada antes de ser processada. Esse processo de verificação é realizado poristiod, que atua como Autoridade de Registro (ou RA) e CA. O RA serve como um guardião que garante que somente a CSR verificada chegue à CA. Depois que a CSR for verificada, ela será encaminhada para a CA, que emitirá um certificado contendo uma identidade SPIFFE com a conta de serviço. Esse certificado é chamado de documento de identidade verificável SPIFFE (ou SVID). O SVID é atribuído ao serviço solicitante para fins de identificação e para criptografar o tráfego em trânsito entre os serviços de comunicação.

Fluxo padrão para solicitações de assinatura de certificados do Istio:

Como funciona a assinatura de certificados no Istio com a CA privada do ACM

Você pode usar um complemento do cert-manager chamado agente de solicitação de assinatura de certificado do Istio (istio-csr) para integrar o Istio à CA privada do ACM. Esse agente permite que as cargas de trabalho e os componentes do plano de controle do Istio sejam protegidos com os emissores do gerenciador de certificados, neste caso, a CA privada do ACM. O agente istio-csr expõe o mesmo serviço que o istiod serve na configuração padrão de validação de CSRs recebidos. Exceto que, após a verificação, ele converterá as solicitações em recursos compatíveis com o cert manager (ou seja, integrações com emissores externos da CA).

Sempre que houver uma CSR de uma carga de trabalho, ela será encaminhada para istio-csr, que solicitará certificados da CA privada do ACM. Essa comunicação entre istio-csr e a CA privada do ACM é habilitada pelo plug-in emissor de CA privada da AWS. O Cert Manager usa esse plug-in para solicitar certificados TLS da CA privada do ACM. O plug-in do emissor se comunicará com o serviço ACM Private CA para solicitar um certificado assinado para a carga de trabalho. Depois que o certificado for assinado, ele será devolvido ao istio-csr, que lerá a solicitação assinada e a retornará à carga de trabalho que iniciou a CSR.

Fluxo para solicitações de assinatura de certificados do Istio com istio-csr

image: :istio-csr-with-acm-private-ca.png [Fluxo para solicitações de assinatura de certificados Istio com istio-csr]

Instruções de configuração do Istio com CA privada

Solicitações de assinatura de certificados Istio

image: :istio-csr-requests.png [Solicitações de assinatura do certificado Istio]

Ferramentas e recursos