Automatize a gestão de certificados TLS para o gateway de entrada do Cloud Service Mesh com o Certificate Authority Service

Este tutorial mostra aos operadores de plataformas como usar o emissor do serviço de autoridade de certificação (serviço de AC) para a ferramenta cert-manager para automatizar a gestão de certificados TLS para o gateway de entrada do Cloud Service Mesh. Os certificados permitem que o gateway de entrada termine o HTTPS e outro tráfego TLS e mTLS originário de clientes na sua nuvem privada virtual (VPC), mas fora da malha de serviços. O tutorial pressupõe uma familiaridade básica com o Kubernetes e os certificados TLS.

Introdução

O Cloud Service Mesh aprovisiona certificados TLS para cada carga de trabalho na malha de serviços. Estes certificados permitem a comunicação encriptada e autenticada mutuamente por TLS (mTLS) entre cargas de trabalho na malha de serviços. Uma das ACs suportadas emite e assina os certificados.

No entanto, o Cloud Service Mesh não aprovisiona automaticamente certificados para o gateway de entrada para o tráfego que entra na malha de serviços. Uma solução comum é usar a ferramenta de código aberto cert-manager para automatizar a gestão de certificados de gateway de entrada.

A ferramenta cert-manager pede certificados a um emissor, que representa uma autoridade de certificação (AC). O serviço de AC é um Google Cloud serviço que lhe permite criar a sua própria AC privada. A ferramenta cert-manager pode pedir certificados ao serviço de AC através do emissor externo de código aberto para o serviço de AC.

Uma AC privada pode emitir certificados TLS que autenticam e encriptam o tráfego numa rede interna. As gateways de entrada do Cloud Service Mesh são frequentemente configuradas para permitir o tráfego recebido de clientes que estão dentro da sua VPC, mas fora da malha de serviços. Para o tráfego de rede interno, pode usar uma AC privada no serviço de AC para emitir certificados para o gateway de entrada.

Este tutorial mostra como configurar a ferramenta cert-manager e o emissor do serviço de AC para automatizar o aprovisionamento e a renovação de certificados TLS para o gateway de entrada. A ferramenta cert-manager aprovisiona certificados como recursos secretos do Kubernetes do tipo TLS. Quando a ferramenta cert-manager renova um certificado, atualiza o recurso Secret com um novo certificado. O gateway de entrada executa o Envoy Proxy e suporta o serviço de deteção de segredos (SDS) do Envoy. O SDS permite que o gateway de entrada comece a usar um novo certificado sem que um administrador tenha de reiniciar ou recarregar o processo.

Os proxies sidecar que fazem parte da malha podem obter certificados TLS da autoridade de certificação do serviço de AC ou da autoridade de certificação do Cloud Service Mesh. Neste tutorial, usa o serviço de AC para os certificados do proxy sidecar e do gateway de entrada. Isto permite-lhe usar uma AC raiz para todos os certificados TLS.

O diagrama seguinte mostra os recursos que aprovisiona neste tutorial. Aprovisiona um balanceador de carga de rede de passagem interno para o gateway de entrada. O balanceador de carga de passagem interno não é um proxy, pelo que não termina as ligações TCP nem realiza negociações TLS. Em vez disso, encaminha as ligações para os pods da implementação istio-ingressgateway.

O segredo hello-example-com-credential contém um certificado e uma chave privada. A configuração do gateway hello configura os pods da implementação istio-ingressgateway para usar este certificado e chave privada para realizar negociações de TLS para pedidos com o nome do anfitrião hello.example.com.

Gestão de MTLS com serviço de AC

Os pods da implementação google-cas-issuer no espaço de nomes cert-manager pedem certificados à AC que cria no serviço de AC. Cria uma associação de políticas de gestão de identidade e de acesso que permite aos ca-service-isser pods fazerem-se passar por uma conta de serviço Google através da federação de identidade da carga de trabalho para o GKE. Concede autorização a esta conta de serviço Google para pedir certificados à sua AC no serviço de AC através da criação de uma associação de políticas da IAM no seu conjunto de ACs.

Objetivos

Custos

Este tutorial usa os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços. Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar este tutorial, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

  1. Na Google Cloud consola, aceda à página do seletor de projetos, e, em seguida, selecione ou crie um projeto.

  2. Certifique-se de que a faturação está ativada para o seu Google Cloud projeto.

  3. Na Google Cloud consola, aceda ao Cloud Shell.

    Na parte inferior da Google Cloud consola, é aberta uma sessão do Cloud Shell e apresentado um comando. Vai usar a Cloud Shell para executar todos os comandos neste tutorial.

  4. Defina o Google Cloud projeto da consola que quer usar para este tutorial:

    gcloud config set core/project PROJECT_ID

    Substitua PROJECT_ID pelo ID do projeto do seu projeto do Google Cloud.

    Na caixa de diálogo Autorizar o Cloud Shell, clique em Autorizar. Ao clicar em Autorizar, permite que os comandos gcloud que executa no Cloud Shell usem as suas credenciais de utilizador para autenticar nas APIs Google.

  5. Ative as APIs Resource Manager, GKE, GKE Hub, autoridade de certificação do Cloud Service Mesh e CA Service:

    gcloud services enable \
    cloudresourcemanager.googleapis.com \
    container.googleapis.com \
    gkehub.googleapis.com \
    meshca.googleapis.com \
    privateca.googleapis.com

Configure o serviço de CA

Nesta secção, cria uma AC raiz e duas ACs subordinadas no serviço de AC. Uma AC subordinada emite certificados para o gateway de entrada e a outra AC subordinada emite certificados para proxies sidecar na malha.

Para simplificar, usa o mesmo projeto para o cluster do GKE e as ACs raiz e subordinadas neste tutorial. No seu próprio ambiente, pode usar um projeto diferente para o cluster do GKE e as ACs.

  1. No Cloud Shell, crie um conjunto de ACs para usar para a AC de raiz:

    gcloud privateca pools create ROOT_CA_POOL \
    --location CA_LOCATION \
    --tier enterprise
    • ROOT_CA_POOL é o nome do conjunto de CAs. Por exemplo, root-ca-pool-tutorial.
    • CA_LOCATION é a localização do grupo de CA. Por exemplo, us-central1.

    Pode listar as localizações do serviço de AC disponíveis através deste comando: gcloud privateca locations list

  2. Crie e ative uma AC de raiz:

    gcloud privateca roots create ROOT_CA \
    --auto-enable \
    --key-algorithm ec-p384-sha384 \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --subject "CN=Example Root CA, O=Example Organization" \
    --use-preset-profile root_unconstrained
    • ROOT_CA é o nome que quer usar para a AC raiz. Por exemplo, root-ca-tutorial.

  3. Crie um conjunto de ACs para usar na AC subordinada que emite certificados para o gateway de entrada:

    gcloud privateca pools create SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --tier devops
    • SUBORDINATE_CA_POOL_GATEWAYS é o nome do conjunto de AC. Por exemplo, subordinate-ca-mtls-pool-gateways-tutorial.

  4. Crie e ative a AC subordinada que emite certificados para o gateway de entrada:

    gcloud privateca subordinates create SUBORDINATE_CA_GATEWAYS \
    --auto-enable \
    --issuer-location CA_LOCATION \
    --issuer-pool ROOT_CA_POOL \
    --key-algorithm ec-p256-sha256 \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_GATEWAYS \
    --subject "CN=Example Gateway mTLS CA, O=Example Organization" \
    --use-preset-profile subordinate_mtls_pathlen_0
    • SUBORDINATE_CA_GATEWAYS é o nome que quer usar para a AC subordinada. Por exemplo, subordinate-ca-mtls-gateways-tutorial.
    • A flag --use-preset-profile configura a AC subordinada para usar o perfil de certificado mTLS subordinado. Este perfil permite que a AC subordinada emita certificados TLS de cliente e servidor para mTLS.

    Se quiser que o gateway de entrada use o TLS simples em vez do mTLS, a AC subordinada só precisa de emitir certificados TLS do servidor. Neste caso, pode usar o perfil de certificado TLS do servidor subordinado (subordinate_server_tls_pathlen_0).

  5. Crie uma política de emissão de certificados:

    cat << EOF > policy.yaml
baselineValues:
  keyUsage:
    baseKeyUsage:
      digitalSignature: true
      keyEncipherment: true
    extendedKeyUsage:
      serverAuth: true
      clientAuth: true
  caOptions:
    isCa: false
identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
EOF

    Esta política de emissão restringe as ACs à emissão de certificados apenas para cargas de trabalho na malha.

  6. Crie um conjunto de ACs para usar na AC subordinada que emite certificados para os proxies sidecar na malha. Aplique a política de emissão ao conjunto de ACs:

    gcloud privateca pools create SUBORDINATE_CA_POOL_SIDECARS \
 --issuance-policy policy.yaml \
 --location CA_LOCATION \
 --tier devops
    • SUBORDINATE_CA_POOL_SIDECARS é o nome do conjunto de AC. Por exemplo, subordinate-ca-mtls-pool-sidecars-tutorial.

  7. Crie e ative a AC subordinada que emite certificados para os proxies sidecar na malha:

    gcloud privateca subordinates create SUBORDINATE_CA_SIDECARS \
    --auto-enable \
    --issuer-location CA_LOCATION \
    --issuer-pool ROOT_CA_POOL \
    --key-algorithm ec-p256-sha256 \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_SIDECARS \
    --subject "CN=Example Sidecar mTLS CA, O=Example Organization" \
    --use-preset-profile subordinate_mtls_pathlen_0
    • SUBORDINATE_CA_GATEWAYS é o nome que quer usar para a AC subordinada. Por exemplo, subordinate-ca-mtls-sidecars-tutorial.

Crie um cluster do Google Kubernetes Engine

  1. No Cloud Shell, crie um cluster do GKE:

    gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --num-nodes 4 \
    --release-channel regular \
    --scopes cloud-platform \
    --workload-pool PROJECT_ID.svc.id.goog \
    --zone ZONE

    Substitua CLUSTER_NAME pelo nome que quer usar para o cluster. Por exemplo, asm-ingress-cert-manager-ca-service.

    Substitua ZONE pela zona que quer usar para o cluster. Por exemplo, us-central1-f.

    Tenha em atenção o seguinte acerca do comando:

    • A flag --release-channel seleciona o canal de lançamento do GKE para o cluster.
    • O Cloud Service Mesh e o emissor do serviço de AC para a ferramenta cert-manager requerem que defina o âmbito cloud-platform nos nós do cluster.
    • O argumento --workload-pool ativa a federação de identidades da carga de trabalho para o GKE, o que permite que a conta de serviço do Kubernetes do emissor do serviço de AC se faça passar por uma conta de serviço Google. Esta representação significa que os pods do emissor do serviço de AC podem aceder à API do serviço de AC sem transferir um ficheiro de chave para a conta de serviço Google.

  2. Conceda autorizações de administrador do cluster à sua conta de utilizador:

    kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin \
    --user $(gcloud config get-value core/account)

    Precisa das autorizações fornecidas pelo cluster-adminClusterRole do Kubernetes para criar as regras de controlo de acesso baseado em funções (CABF) para a Cloud Service Mesh e para instalar a ferramenta cert-manager.

Instale o plano de controlo do Anthos Service Mesh

Neste tutorial, instala o Cloud Service Mesh gerido para um cluster do GKE no Google Cloud, com todos os recursos num projeto. No seu próprio ambiente, pode aplicar a solução descrita neste documento através da malha de serviços na nuvem gerida ou de um plano de controlo no cluster.

O Cloud Service Mesh oferece uma variedade de opções de instalação para diferentes cenários. Depois de concluir este tutorial, recomendamos que reveja o guia de instalação para selecionar a opção mais adequada ao seu ambiente.

  1. No Cloud Shell, transfira a asmcli ferramenta de instalação:

    curl --location --output asmcli https://storage.googleapis.com/csm-artifacts/asm/asmcli_1.26

chmod +x asmcli

    Usa o asmcli para instalar o plano de controlo da malha de serviços na nuvem.

  2. Instale o plano de controlo do Cloud Service Mesh:

    ./asmcli install \
    --ca gcp_cas \
    --ca_pool projects/PROJECT_ID/locations/CA_LOCATION/caPools/SUBORDINATE_CA_POOL_SIDECARS \
    --cluster_location ZONE \
    --cluster_name CLUSTER_NAME \
    --enable_all \
    --enable_registration \
    --fleet_id PROJECT_ID \
    --managed \
    --output_dir asm-files \
    --project_id PROJECT_ID \
    --verbose

    A instalação demora vários minutos. Quando a instalação estiver concluída, é apresentada a seguinte saída:

    asmcli: Successfully installed ASM.

Instale o gateway de entrada

  1. No Cloud Shell, crie um namespace do Kubernetes para o gateway de entrada:

    kubectl create namespace GATEWAY_NAMESPACE
    • GATEWAY_NAMESPACE é o nome do espaço de nomes que quer usar para o gateway de entrada. Por exemplo, istio-ingress.

  2. Reserve um endereço IP interno estático para usar no Network Load Balancer de encaminhamento interno do gateway de entrada:

    LOAD_BALANCER_IP=$(gcloud compute addresses create \
    asm-ingress-gateway-ilb \
    --region REGION \
    --subnet default \
    --format 'value(address)')
    • Substitua REGION pela região que contém a zona ou as zonas que os nós do cluster do GKE usam. Por exemplo, se o seu cluster usar a zona us-central1-f, substitua REGION por us-central1.

    Este comando reserva um endereço IP da sub-rede predefinida na região que especificar.

  3. Crie um manifesto do operador para o gateway de entrada:

    cat << EOF > ingressgateway-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: ingressgateway-operator
  annotations:
    config.kubernetes.io/local-config: "true"
spec:
  profile: empty
  revision: asm-managed
  components:
    ingressGateways:
    - name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
      enabled: true
      k8s:
        overlays:
        - apiVersion: apps/v1
          kind: Deployment
          name: istio-ingressgateway
          patches:
          - path: spec.template.metadata.annotations
            value:
              inject.istio.io/templates: gateway
          - path: spec.template.metadata.labels.sidecar\.istio\.io/inject
            value: "true"
          - path: spec.template.spec.containers[name:istio-proxy]
            value:
              name: istio-proxy
              image: auto
        service:
          loadBalancerIP: $LOAD_BALANCER_IP
        serviceAnnotations:
          networking.gke.io/load-balancer-type: Internal
          networking.gke.io/internal-load-balancer-allow-global-access: "true"
EOF

    Tenha em atenção o seguinte acerca do manifesto do operador:

  4. Crie o manifesto de instalação do gateway de entrada com o manifesto do operador e a ferramenta istioctl que o script asmcli transferiu quando instalou o plano de controlo:

    ./asm-files/istioctl manifest generate \
    --filename ingressgateway-operator.yaml \
    --output ingressgateway

  5. Instale o gateway de entrada:

    kubectl apply --recursive --filename ingressgateway/

Instale a ferramenta cert-manager

  1. No Cloud Shell, transfira e aplique o manifesto de instalação da ferramenta cert-manager:

    CERT_MANAGER_VERSION=v1.5.4

curl --location --output cert-manager.yaml "https://github.com/jetstack/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.yaml"

kubectl apply --filename cert-manager.yaml

    A instalação da ferramenta cert-manager demora cerca de 1 minuto.

Instale o controlador do emissor do serviço de AC

O controlador do emissor do serviço de AC permite que a ferramenta cert-manager peça certificados através do serviço de AC. O controlador usa a ferramenta cert-manager external issuer mecanismo de extensão.

  1. No Cloud Shell, crie uma conta de serviço Google:

    gcloud iam service-accounts create CAS_ISSUER_GSA \
    --display-name "CA Service issuer for cert-manager"
    • CAS_ISSUER_GSA é o nome da conta de serviço Google. Por exemplo, cert-manager-ca-service-issuer.

    O controlador do emissor do Certificate Authority Service usa esta conta de serviço da Google para fazer a autenticação nas APIs do Certificate Authority Service.

  2. Crie uma associação de políticas de gestão de identidade e de acesso que permita à conta de serviço Google do controlador do emissor do serviço de autoridade de certificação pedir certificados ao conjunto de ACs que contém a sua AC subordinada:

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

  3. Transfira o manifesto de instalação do controlador do emissor do serviço de autoridade de certificação:

    CAS_ISSUER_VERSION=v0.5.3

curl --location --output ca-service-issuer.yaml "https://github.com/jetstack/google-cas-issuer/releases/download/${CAS_ISSUER_VERSION}/google-cas-issuer-${CAS_ISSUER_VERSION}.yaml"

  4. Crie uma associação de política de IAM para permitir que a conta de serviço do Kubernetes no espaço de nomes cert-manager se faça passar pela conta de serviço Google (GSA) através da federação de identidades da carga de trabalho para o GKE:ksa-google-cas-issuer

    gcloud iam service-accounts add-iam-policy-binding \
 CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[cert-manager/ksa-google-cas-issuer]" \
    --role roles/iam.workloadIdentityUser

    Os pods do controlador do emissor do serviço de AC usam a conta de serviço do Kubernetes ksa-google-cas-issuer.

  5. Instale o controlador do emissor do serviço de AC no seu cluster do GKE:

    kubectl apply --filename ca-service-issuer.yaml

  6. Adicione a anotação da federação de identidades da carga de trabalho para o GKE iam.gke.io/gcp-service-account à conta de serviço do Kubernetes usada pelos pods do controlador do emissor do serviço de AC:

    kubectl annotate serviceaccount ksa-google-cas-issuer --namespace cert-manager \
   "iam.gke.io/gcp-service-account=CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com"

    Esta anotação informa o GKE de que a conta de serviço do Kubernetes pode roubar a identidade da conta de serviço Google para aceder às APIs Google.

Crie um emissor de certificados

  1. No Cloud Shell, crie e aplique um manifesto GoogleCASIssuer:

    cat << EOF > gateway-cas-issuer.yaml
apiVersion: cas-issuer.jetstack.io/v1beta1
kind: GoogleCASIssuer
metadata:
  name: gateway-cas-issuer
  namespace: GATEWAY_NAMESPACE
spec:
  caPoolId: SUBORDINATE_CA_POOL_GATEWAYS
  location: CA_LOCATION
  project: PROJECT_ID
EOF

kubectl apply --filename gateway-cas-issuer.yaml

    O emissor permite que a ferramenta cert-manager aprovisione certificados a partir do seu conjunto de ACs subordinadas no espaço de nomes do gateway de entrada

Implemente uma aplicação de exemplo

Nesta secção, verifica se a ferramenta cert-manager pode usar o emissor do serviço de AC para obter certificados do serviço de AC. Para validar, implemente uma aplicação de exemplo com a configuração de encaminhamento de pedidos e um certificado para o gateway de entrada.

  1. No Cloud Shell, crie um namespace para os recursos da aplicação de exemplo:

    cat << EOF > sample-app-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: APP_NAMESPACE
  annotations:
    mesh.cloud.google.com/proxy: '{"managed":"true"}'
  labels:
    istio.io/rev: asm-managed
EOF

kubectl apply --filename sample-app-namespace.yaml
    • APP_NAMESPACE é o nome do espaço de nomes para a aplicação de exemplo. Por exemplo, sample-app.

    A anotação mesh.cloud.google.com/proxy ativa o plano de dados gerido para o espaço de nomes.

    A etiqueta istio.io/rev: asm-managed seleciona o canal de lançamento normal para o plano de dados gerido no espaço de nomes da aplicação de exemplo. Altere o valor desta etiqueta se usar os canais de lançamento rápido ou estável.

  2. Crie um recurso de implementação para a aplicação de exemplo:

    cat << EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  namespace: APP_NAMESPACE
  labels:
    app: hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:1.0
        name: hello-app
        ports:
        - containerPort: 8080
EOF

kubectl apply --filename deployment.yaml

  3. Crie um recurso Service para a aplicação de exemplo:

    cat << EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  namespace: APP_NAMESPACE
spec:
  ports:
  - name: http-hello
    port: 8080
  selector:
    app: hello
  type: ClusterIP
EOF

kubectl apply --filename service.yaml
    • SERVICE_NAME é o nome do serviço. Por exemplo, hello.

  4. Crie um recurso de certificado para o nome de domínio hello.example.com usando o emissor do certificado:

    cat << EOF > certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: hello-example-com-certificate
  namespace: GATEWAY_NAMESPACE
spec:
  secretName: hello-example-com-credential
  commonName: hello.example.com
  dnsNames:
  - hello.example.com
  duration: 24h
  renewBefore: 8h
  issuerRef:
    group: cas-issuer.jetstack.io
    kind: GoogleCASIssuer
    name: gateway-cas-issuer
EOF

kubectl apply --filename certificate.yaml

    O espaço de nomes do certificado tem de corresponder ao espaço de nomes do gateway de entrada. Normalmente, apenas os administradores da plataforma podem alterar os recursos neste espaço de nomes, uma vez que as alterações podem afetar toda a malha de serviço. A ferramenta cert-manager cria o recurso secreto para o certificado TLS no mesmo espaço de nomes. Isto significa que os administradores de aplicações não precisam de ter acesso ao espaço de nomes do gateway de entrada.

    Pode adicionar nomes de anfitriões adicionais na lista dnsNames no certificado. Estes nomes de anfitrião estão incluídos no certificado como nomes alternativos de assunto (SANs).

  5. Crie um recurso Gateway para a aplicação de exemplo:

    cat << EOF > gateway.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: GATEWAY_NAME
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - APP_NAMESPACE/hello.example.com
    port:
      name: https-hello
      number: 443
      protocol: HTTPS
    tls:
      credentialName: hello-example-com-credential
      mode: MUTUAL
EOF

kubectl apply --filename gateway.yaml
    • GATEWAY_NAME é o nome da gateway. Por exemplo, hello.
    • O campo credentialName no gateway corresponde ao campo secretName no certificado. A ferramenta cert-manager cria um segredo do Kubernetes com o certificado TLS do serviço de AC. Este certificado permite que o gateway de entrada termine o tráfego TLS destinado ao hello.example.com.

    O manifesto do gateway especifica o TLS MUTUAL (mTLS). Se quiser configurar o gateway para TLS normal, defina o modo TLS do gateway como SIMPLE.

  6. Crie um recurso VirtualService para a aplicação de exemplo:

    cat << EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: hello
  namespace: APP_NAMESPACE
spec:
  hosts:
  - hello.example.com
  gateways:
  - GATEWAY_NAMESPACE/GATEWAY_NAME
  http:
  - route:
    - destination:
        host: SERVICE_NAME
        port:
          number: 8080
EOF

kubectl apply --filename virtual-service.yaml

    O Gateway e o VirtualService usam espaços de nomes diferentes. Este padrão comum restringe as alterações ao encaminhamento baseado no anfitrião no Gateway aos administradores da plataforma que têm autorizações para alterar recursos no espaço de nomes do gateway de entrada.

    Os administradores de aplicações com autorizações para editar o VirtualService no espaço de nomes da aplicação de exemplo podem alterar o encaminhamento por outros campos de pedido, como o caminho do URL, sem coordenação com os administradores da plataforma.

Se quiser explorar outras opções de configuração, leia a documentação da API para os recursos Certificate, Gateway e VirtualService.

Pode aplicar políticas de autenticação e autorização ao tráfego que entra na malha de serviços através do gateway de entrada. Para o fazer, leia a documentação das APIs PeerAuthentication e AuthorizationPolicy do Istio.

Valide a solução

Nesta secção, verifica se consegue enviar pedidos HTTPS através de mTLS para a aplicação de exemplo a partir do exterior da malha de serviços. Para validar, cria uma instância de VM do Compute Engine, pede um certificado TLS do cliente ao serviço de AC e usa este certificado para autenticar o pedido na aplicação de exemplo.

Precisa de acesso SSH à instância de VM. A rede predefinida inclui uma regra de firewall que permite o acesso SSH. Se não tiver acesso SSH, siga a documentação sobre regras de firewall para criar uma regra de firewall que permita ligações TCP recebidas na porta 22.

  1. No Cloud Shell, crie uma conta de serviço Google:

    gcloud iam service-accounts create CLIENT_VM_GSA \
    --display-name "CA Service tutorial VM instance service account"
    • CLIENT_VM_GSA é o nome da conta de serviço Google. Por exemplo, cas-tutorial-client.

    Atribui esta conta de serviço Google à instância da VM do Compute Engine.

  2. Conceda a função CA Service Certificate Requester no conjunto de ACs subordinadas dos gateways à conta de serviço da Google:

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

    Esta função concede autorizações para pedir certificados ao conjunto de ACs.

  3. Crie uma instância de VM do Compute Engine na mesma VPC que o cluster do GKE:

    gcloud compute instances create cas-tutorial-client \
    --scopes cloud-platform \
    --service-account CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --zone ZONE

    A instância de VM requer o âmbito cloud-platform para aceder à API CA Service.

  4. Guarde o endereço IP do Network Load Balancer de passagem interna do gateway de entrada num ficheiro:

    kubectl get services istio-ingressgateway \
   --namespace GATEWAY_NAMESPACE \
   --output jsonpath='{.status.loadBalancer.ingress[0].ip}' > ilb-ip.txt

  5. Guarde o certificado de chave pública da sua CA de raiz num ficheiro:

    gcloud privateca roots describe ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --format 'value(pemCaCertificates)' > root-ca-cert.pem

  6. Copie o certificado da AC de raiz e o ficheiro que contém o endereço IP do Network Load Balancer de passagem interna do gateway de entrada para a instância de VM:

    gcloud compute scp root-ca-cert.pem ilb-ip.txt cas-tutorial-client:~ \
   --zone ZONE

  7. Estabeleça ligação à instância da VM através de SSH:

    gcloud compute ssh cas-tutorial-client --zone ZONE

    Execute os restantes comandos nesta secção a partir da sessão SSH.

  8. Instale os pacotes ca-certificates e coreutils, bem como as ferramentas de linha de comandos curl, openssl e jq:

    sudo apt-get update --yes

sudo apt-get install --yes ca-certificates coreutils curl jq openssl

  9. Crie um par de chaves para o certificado TLS do cliente:

    openssl genrsa -out private-key.pem 2048

openssl rsa -in private-key.pem -pubout -out public-key.pem

  10. Consulte o servidor de metadados para obter o endereço de email da identidade da conta de serviço Google anexada à instância de VM:

    GSA_EMAIL=$(curl --silent --header "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email)

  11. Crie um ficheiro JSON que usa como corpo do pedido quando pede um certificado TLS de cliente à API Certificate Authority Service:

    cat << EOF > request.json
{
  "config": {
    "publicKey": {
      "format": "PEM",
      "key": "$(base64 --wrap 0 public-key.pem)"
    },
    "subjectConfig": {
      "subject": {
        "commonName": "$(hostname --short)",
        "organization": "Example Organization"
      },
      "subjectAltName": {
        "dnsNames": [
          "$(hostname --fqdn)"
        ],
        "emailAddresses": [
          "$GSA_EMAIL"
        ]
      }
    },
    "x509Config": {
      "caOptions": {
        "isCa": false
      },
      "keyUsage": {
        "baseKeyUsage": {
          "digitalSignature": true,
          "keyEncipherment": true
        },
        "extendedKeyUsage": {
          "clientAuth": true
        }
      }
    }
  },
  "lifetime": "86400s"
}
EOF

    Para saber mais acerca dos campos na secção de configuração, consulte o CertificateConfig tipo na documentação da API CA Service.

  12. Peça uma chave de acesso OAuth 2.0 ao servidor de metadados:

    TOKEN=$(curl --silent --header "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token | jq --raw-output ".access_token")

    Este token de acesso fornece as autorizações concedidas à conta de serviço Google associada à instância de VM.

  13. Peça um certificado TLS de cliente à API CA Service e armazene o corpo da resposta num ficheiro:

    curl --silent --request POST \
    --header "Authorization: Bearer $TOKEN" \
    --header "Content-Type: application/json" \
    --data @request.json \
    --output response.json \
    "https://privateca.googleapis.com/v1/projects/PROJECT_ID/locations/CA_LOCATION/caPools/SUBORDINATE_CA_POOL_GATEWAYS/certificates"

    O comando usa o token de acesso para autenticar o pedido da API.

  14. Guarde o certificado de cliente e a cadeia de certificados num ficheiro:

    jq --raw-output --join-output ".pemCertificate , .pemCertificateChain[]" response.json > client-cert-chain.pem

  15. Use curl para enviar um pedido HTTPS da instância da VM para a aplicação de exemplo:

    curl --cert client-cert-chain.pem --key private-key.pem \
    --cacert root-ca-cert.pem \
    --resolve hello.example.com:443:$(cat ilb-ip.txt) \
    --silent https://hello.example.com | head -n1

    O resultado tem o seguinte aspeto:

    Hello, world!

    Esta resposta mostra que curl enviou com êxito o pedido HTTPS através do mTLS. A aplicação de exemplo respondeu com a mensagem que vê na saída do terminal.

    O comando curl faz o seguinte:

    • As flags --cert e --key indicam ao curl que use o certificado TLS do cliente e a chave privada para autenticar o pedido. O ficheiro de certificado do cliente contém a cadeia completa de certificados, desde o certificado do cliente à AC de raiz.

    • A flag --cacert indica ao curl que verifique se a AC raiz que criou neste tutorial, ou uma das respetivas ACs subordinadas, emitiu o certificado do servidor.

      Se omitir esta flag, o curl tenta validar o certificado do servidor com o pacote de AC predefinido do seu sistema operativo, como o pacote ca-certificates no Debian. A validação falha porque o pacote de AC predefinido não inclui a AC de raiz que criou neste tutorial.

    • A flag --resolve indica ao curl que use o endereço IP do Network Load Balancer de passagem interna como o destino dos pedidos para alojar o hello.example.com na porta 443.

      Se omitir esta flag, o curl tenta usar o DNS para resolver o nome do anfitrião hello.example.com. A resolução de DNS falha porque não existe nenhuma entrada de DNS para este nome do anfitrião.

      No seu próprio ambiente, recomendamos que crie um registo A de DNS que aponte para o endereço IP do Network Load Balancer de passagem interno ($LOAD_BALANCER_IP). Crie este registo através do Cloud DNS, seguindo a documentação sobre a gestão de registos.

    • A flag --silent suprime os relatórios de progresso da transferência de respostas no resultado do terminal.

    • O comando envia o resultado do curl para head -n1. O resultado é que o resultado no terminal inclui apenas a primeira linha do corpo da resposta.

  16. Saia da sessão SSH:

    exit

Nesta secção, pediu um certificado TLS de cliente diretamente à API CA Service. Na situação em que o cliente é o gateway de saída de outra malha de serviço num cluster do Kubernetes separado, pode usar a ferramenta cert-manager e o emissor do serviço de autoridade de certificação com a mesma CA raiz para fornecer certificados de cliente ao gateway de saída.

Noutras situações, pode usar ferramentas como o Hashicorp Vault, o Terraform ou o gcloud para pedir certificados TLS de cliente para cargas de trabalho fora da malha de serviços. Para mais informações, consulte a documentação do serviço de CA para soluções de exemplo e a documentação gcloud para o serviço de CA.

(Opcional) Adicione certificados da AC ao repositório fidedigno

Esta secção opcional mostra como adicionar certificados da AC à loja de certificados da AC fidedignos para a distribuição Debian do Linux. Estas instruções também se aplicam a distribuições derivadas do Debian, como o Ubuntu.

A adição dos seus certificados de AC a esta loja significa que não tem de especificar a localização dos certificados de AC fidedignos quando envia pedidos HTTPS através de curl, Python, Go e Ruby.

  1. Estabeleça ligação à instância da VM através de SSH:

    gcloud compute ssh cas-tutorial-client --zone ZONE

    Execute os restantes comandos nesta secção a partir da sessão SSH.

  2. Copie o certificado da CA de raiz para o diretório /usr/local/share/ca-certificates e certifique-se de que o ficheiro tem a extensão .crt:

    sudo cp root-ca-cert.pem /usr/local/share/ca-certificates/cas-rootca.crt

  3. Defina as autorizações de ficheiros para que todos os utilizadores possam ler o ficheiro de certificado da AC de raiz:

    sudo chmod 644 /usr/local/share/ca-certificates/cas-rootca.crt

  4. Execute o script update-ca-certificates 

    sudo update-ca-certificates

    Este script adiciona o certificado ao conjunto de certificados fidedignos no diretório /etc/ssl/certs e ao ficheiro /etc/ssl/certs/ca-certificates.crt.

    O resultado é o seguinte:

    Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

  5. Use curl para enviar um pedido HTTPS da instância da VM para a aplicação de exemplo:

    curl --cert client-cert-chain.pem --key private-key.pem \
   --resolve hello.example.com:443:$(cat ilb-ip.txt) \
   --silent https://hello.example.com | head -n1

    O resultado tem o seguinte aspeto:

    Hello, world!

    Esta resposta mostra que curl enviou com êxito o pedido HTTPS através do mTLS e validou o certificado TLS do servidor a partir do gateway de entrada através do repositório de certificados da AC predefinido.

  6. Saia da sessão SSH:

    exit

Resolver problemas

Se o controlador do emissor do serviço de AC não criar o segredo do certificado TLS, veja os registos do controlador do emissor do serviço de AC:

kubectl logs deployment/google-cas-issuer --namespace cert-manager

Se tiver problemas ao instalar o Cloud Service Mesh, execute a ferramenta asmcli para validar o seu projeto do Google Cloud e cluster do GKE.

Se tiver outros problemas com este tutorial, recomendamos que reveja estes documentos:

Limpar

Para evitar incorrer em encargos contínuos na sua Google Cloud conta pelos recursos usados neste tutorial, pode eliminar o projeto ou eliminar os recursos individuais.

Elimine o projeto

  1. No Cloud Shell, elimine o projeto:

    gcloud projects delete PROJECT_ID

Elimine os recursos

Se quiser manter o Google Cloud projeto que usou neste tutorial, elimine os recursos individuais:

  1. No Cloud Shell, anule o registo do cluster do GKE no GKE Hub:

    gcloud container hub memberships unregister CLUSTER_NAME \
    --gke-cluster ZONE/CLUSTER_NAME

  2. Elimine o cluster do GKE:

    gcloud container clusters delete CLUSTER_NAME \
    --zone ZONE --async --quiet

  3. Elimine as associações de políticas IAM no conjunto de CAs subordinadas:

    gcloud privateca pools remove-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

gcloud privateca pools remove-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

  4. Desative e agende a eliminação das CAs subordinadas e da CA de raiz:

    gcloud privateca subordinates disable SUBORDINATE_CA_GATEWAYS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_GATEWAYS \
    --quiet

gcloud privateca subordinates delete SUBORDINATE_CA_GATEWAYS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_GATEWAYS \
    --ignore-active-certificates \
    --quiet

gcloud privateca subordinates disable SUBORDINATE_CA_SIDECARS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_SIDECARS \
    --quiet

gcloud privateca subordinates delete SUBORDINATE_CA_SIDECARS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_SIDECARS \
    --ignore-active-certificates \
    --quiet

gcloud privateca roots disable ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --quiet

gcloud privateca roots delete ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --ignore-active-certificates \
    --quiet

  5. Elimine a associação da política IAM para a conta de serviço Google do controlador do emissor do serviço de AC:

    gcloud iam service-accounts remove-iam-policy-binding \
    CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[cert-manager/ksa-google-cas-issuer]" \
    --role roles/iam.workloadIdentityUser

  6. Elimine as contas de serviço Google:

    gcloud iam service-accounts delete --quiet \
    CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com

gcloud iam service-accounts delete --quiet \
    CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com

  7. Elimine o endereço IP do balanceador de carga reservado:

    gcloud compute addresses delete asm-ingress-gateway-ilb \
    --region REGION --quiet

  8. Elimine a instância de VM do Compute Engine:

    gcloud compute instances delete cas-tutorial-client \
    --zone ZONE --quiet

O que se segue?