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. O primeiro 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 tráfego leste/oeste), 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 pod, seletores de namespace e rótulos para identificar pods de origem e destino, mas também podem incluir endereços IP, números de porta, protocolos ou uma combinação desses. 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 de políticas de rede do Kubernetes, garantindo compatibilidade e aderência aos padrões do Kubernetes. Você pode definir políticas usando identificadores diferentes compatíveis com a API upstream. Por padrão, todo o tráfego de entrada e saída é permitido para um pod. Quando uma política de rede com um PolicyType Ingress é especificada, somente as conexões permitidas no pod são aquelas do nó 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 nas políticas de RBAC, é recomendável seguir os princípios de acesso menos privilegiado com as políticas de rede. Comece criando uma política de negar 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 estabelecer a regra padrão de negar tudo, você pode começar a criar 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

allow-dns-access

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 declient-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 vpc-network-policy-controller registros 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 CloudWatchLog Insights para realizar consultas avançadas. Nos registros, você pode ver quais objetos de endpoint do pod estão resolvidos em 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 CloudWatchContainer Insights para fornecer informações sobre seu uso relacionado às políticas de rede.

O Amazon VPC CNI também envia um SDK que fornece uma interface para interagir com os programas eBPF no nó. O SDK é instalado quando aws-node é implantado nos nós. Você pode encontrar o binário do SDK instalado no /opt/cni/bin diretório no 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 uma VPC, como endereço IP e porta de origem e destino, juntamente com pacotes aceitos/descartados. Essas informações podem ser analisadas para procurar atividades suspeitas ou incomuns entre os recursos 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 pod e outros metadados, facilitando a decifração dos fluxos de tráfego entre os pods.

Grupos de segurança

O EKS usa AWS VPC Security Groups (SGs) 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 a versão 1.14-eks.3 ou superior do Kubernetes), um grupo de segurança de cluster é criado automaticamente para você. Esse grupo de segurança permite a comunicação sem restrições 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 os 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 nó de trabalho SG; 10250 é a porta na qual os kubelets escutam. Da mesma forma, as regras mínimas de grupo de nós permitem a entrada da porta 10250 do plano de controle SG e a saída 443 do plano de controle SG. Finalmente, há uma regra que permite a comunicação irrestrita entre os nós dentro de um grupo de nós.

Se você precisar controlar a comunicação entre os serviços executados dentro do cluster e os serviços executados fora do cluster, como um banco de dados do 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 como {} atribuirá o SGs referenciado em a todos os pods em um namespace ou SecurityGroupPolicy a todas as contas de serviço em um namespace. Certifique-se de ter se familiarizado 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 forma nativa da AWS de controlar o tráfego de rede dentro e fora do seu cluster sem a sobrecarga de um daemon de políticas, outras opções estão disponíveis. Por exemplo, o mecanismo de política do 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)

Melhores práticas de uso de grupos de segurança para pods e políticas 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 defense-in-depth estratégia robusta 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 (aplicativo) do modelo OSI, enquanto as políticas de rede kubernetes operam na camada 3 (rede) e na camada 4 (transporte). Há muitas ofertas neste 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 de rede globais, 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 ser definidas para 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 de RBAC adequadas em vigor, você pode impedir 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, que podem ser úteis para restringir o tráfego entre o Kubernetes Services/Pods e os recursos executados dentro ou fora da sua VPC. Por outro lado, o Calico Enterprise inclui um recurso que permite mapear uma política de rede 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 Calico está disponível em https://docs.projectcalico. org/security/calico-política de rede.

Migração para o Amazon VPC CNI Network Policy Engine

Para manter a consistência e evitar um comportamento inesperado de comunicação entre pods, é recomendável implantar somente um Network Policy Engine em seu cluster. Se você quiser migrar do 3P para o VPC CNI Network Policy Engine, recomendamos converter seu 3P existente para os recursos do Kubernetes antes de ativar NetworkPolicy CRDs o suporte à política de rede VPC CNI. NetworkPolicy E 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 auxiliar em seu processo de migração, desenvolvemos uma ferramenta chamada K8s Network Policy Migrator que converte sua política de rede existente em políticas CRDs de Calico/Cilium 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 da rede AWS VPC CNI. Ela é disponibilizada aos clientes com base no melhor esforço 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 GitHubproblema. 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 outras regulamentações podem precisar criptografar os 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 SSL, fornece comunicações seguras em uma rede usando protocolos criptográficos. O TLS usa criptografia simétrica em que 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.

Interfaces de rede de contêineres (CNIs)

WeaveNetpode ser configurado para criptografar automaticamente todo o tráfego usando NaCl criptografia para tráfego intermediário e IPsec ESP para tráfego rápido de caminhos de dados.

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 certificados X.509 ou Envoy's Secret Discovery Service (SDS). Tanto o Linkerd quanto o Istio têm suporte para mTLS.

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

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 aws-app-mesh-examplesGitHub repositório fornece orientações para configurar o TLS usando certificados emitidos pelo ACM e certificados que são empacotados com seu contêiner Envoy:

Controladores de entrada e balanceadores de carga

Os controladores de entrada são uma forma de rotear de forma inteligente o HTTP/S traffic that emanates from outside the cluster to services running inside the cluster. Oftentimes, these Ingresses are fronted by a layer 4 load balancer, like the Classic Load Balancer or the Network Load Balancer (NLB). Encrypted traffic can be terminated at different places within the network, e.g. at the load balancer, at the ingress resource, or the Pod. How and where you terminate your SSL connection will ultimately be dictated by your organization’s network security policy. For instance, if you have a policy that requires end-to-end encryption, you will have to decrypt the traffic at the Pod. This will place additional burden on your Pod as it will have to spend cycles establishing the initial handshake. Overall SSL/TLS processamento que consome muita CPU. Consequentemente, se você tiver flexibilidade, tente realizar o descarregamento de SSL no Ingress ou no balanceador de carga.

Use criptografia com os balanceadores de carga elásticos da AWS

O AWS Application Load Balancer (ALB) e 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 exigirem, combinando os certificados disponíveis do AWS Certificate Manager (ACM) usando o campo host. A partir do 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

A seguir estão exemplos adicionais de SSL/TLS rescisão.

CA privada do ACM com cert-manager

Você pode habilitar 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 altamente disponível, segura e gerenciada, 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 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.

Modo CA de curta duração 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 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 o ACM Private CA 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 privado do 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 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": "<CA_ARN>"
        }
    ]
}

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 ver exemplos completos.

Crie um emissor no Amazon EKS criando um arquivo de definição de recurso personalizado chamado cluster-issuer.yaml com o texto a seguir, substituindo as informações por 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 certificado, consulte o guia de recursos de certificados do cert-manager. Veja exemplos aqui.

CA privada do ACM com Istio e cert-manager

Se você estiver executando o Istio em seu cluster EKS, poderá desativar o plano de controle do Istio (especificamenteistiod) de funcionar como a Autoridade Certificadora (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 o CSR verificado 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 ACM Private CA

Você pode usar um complemento 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 pelos emissores do gerenciador de certificados, neste caso, o ACM Private CA. O agente istio-csr expõe o mesmo serviço que o istiod serve na configuração padrão de validação de entrada. CSRs Exceto que, após a verificação, ele converterá as solicitações em recursos que o cert manager suporta (ou seja, integrações com emissores externos de CA).

Sempre que houver uma CSR de uma carga de trabalho, ela será encaminhada para o istio-csr, que solicitará certificados da CA privada do ACM. Essa comunicação entre istio-csr e a CA privada do ACM é ativada pelo plug-in do emissor da CA privada da AWS. O gerenciador de certificados 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

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

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

Solicitações de assinatura de certificados do Istio

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

Ferramentas e recursos