Automatizar o gerenciamento de certificados TLS para o gateway de entrada do Anthos Service Mesh usando o Certificate Authority Service
Neste tutorial, mostramos aos operadores da plataforma como usar o emissor do Certificate Authority Service (CA Service) da ferramenta cert-manager para automatizar o gerenciamento de certificados TLS no gateway de entrada do Anthos Service Mesh. Os certificados permitem que o gateway de entrada encerre o tráfego HTTPS e outros tráfegos TLS e mTLS originários de clientes na sua nuvem privada virtual (VPC, na sigla em inglês), mas fora da malha de serviço. Neste tutorial, presumimos que haja familiaridade básica com o Kubernetes e os certificados TLS.
Introdução
O Anthos Service Mesh provisiona certificados TLS a todas as cargas de trabalho na malha de serviço. Esses certificados permitem a comunicação criptografada e TLS mutuamente autenticada (mTLS) entre cargas de trabalho na malha de serviço. Uma das CAs compatíveis emite e assina os certificados.
No entanto, o Anthos Service Mesh não provisiona certificados automaticamente no gateway de entrada para o tráfego que entra na malha de serviço. Uma solução comum é usar a ferramenta de código aberto cert-manager para automatizar o gerenciamento de certificados do gateway de entrada.
A ferramenta cert-manager solicita certificados de um emissor, que representa uma autoridade certificadora (CA, na sigla em inglês). O CA Service é um serviço do Google Cloud que permite criar sua própria CA particular. A ferramenta cert-manager pode solicitar certificados pelo CA Service usando o emissor externo de código aberto do CA Service.
Uma CA particular pode emitir certificados TLS que autenticam e criptografam o tráfego dentro de uma rede interna. Os gateways de entrada do Anthos Service Mesh geralmente são configurados para permitir o tráfego de entrada de clientes que estão dentro da VPC, mas fora da malha de serviço. Para o tráfego de rede interno, é possível usar uma CA particular no CA Service para emitir certificados para o gateway de entrada.
Neste tutorial, mostramos como configurar a ferramenta cert-manager e o emissor do CA Service para automatizar o provisionamento e a renovação de certificados TLS para o gateway de entrada. A ferramenta cert-manager provisiona certificados como recursos do secret do Kubernetes do tipo TLS. Quando a ferramenta cert-manager atualiza um certificado, ela atualiza o recurso Secret com um novo certificado. O gateway de entrada executa o proxy Envoy e oferece suporte para o serviço de descoberta de secret (SDS) do Envoy. O SDS permite que o gateway de entrada comece a usar um novo certificado sem exigir que um administrador reinicie ou atualize o processo.
Os proxies sidecar que fazem parte da malha podem conseguir certificados TLS com o CA Service ou com a autoridade certificadora do Anthos Service Mesh (Mesh CA). Neste tutorial, você usará o CA Service para os certificados de proxy sidecar e de gateway de entrada. Isso permite usar uma CA raiz para todos os certificados TLS.
O diagrama a seguir mostra os recursos provisionados neste tutorial.
Provisione um balanceador de carga de rede de passagem interna para o gateway de entrada. O
balanceador de carga de rede de passagem interno não é um proxy, por isso
não encerra conexões TCP nem executa handshakes de TLS. Em vez disso, ele encaminha
conexões aos pods da implantação istio-ingressgateway
.
O secret hello-example-com-credential
contém um certificado e uma chave
privada. O gateway hello
configura os pods da implantação
istio-ingressgateway
para usar esse certificado e a chave privada para executar handshakes de TLS para
solicitações com o nome de host hello.example.com
.
Os pods da implantação google-cas-issuer
no namespace cert-manager
solicitam certificados a partir da CA criada no CA Service. Crie uma
vinculação de política de gerenciamento de identidade e acesso que permita que os pods ca-service-isser
personifiquem uma conta de serviço do Google usando a
Identidade da carga de trabalho. Conceda
permissão à conta de serviço do Google para solicitar certificados a partir da sua
CA no CA Service criando uma vinculação de política do IAM
no pool de CAs.
Objetivos
- Configurar o serviço de CA
- Crie um cluster do GKE
- Instalar o plano de controle do Anthos Service Mesh
- Instalar o gateway de entrada
- Instalar a ferramenta cert-manager
- Instalar o controlador do emissor do CA Service
- Criar um emissor de certificado
- Implantar um aplicativo de amostra
- Verificar a solução
- (Opcional) Adicionar certificados de CA a um armazenamento confiável
Custos
Neste tutorial, usamos o seguinte componente faturável do Google Cloud:
Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.
Ao concluir este tutorial, exclua os recursos criados para evitar cobrança contínua. Para mais informações, consulte Limpeza.
Antes de começar
No console do Google Cloud, acesse a página do seletor de projetos e selecione ou crie um.
Verifique se a cobrança está ativada para o projeto do Google Cloud.
No console do Google Cloud, acesse o Cloud Shell.
Na parte inferior do console do Google Cloud, uma sessão do Cloud Shell é aberta e exibe um prompt de linha de comando. Use o Cloud Shell para executar todos os comandos neste tutorial.
Defina o projeto do console do Google Cloud que você quer usar neste tutorial:
gcloud config set core/project PROJECT_ID
Substitua PROJECT_ID pelo ID do projeto do Cloud.
Na caixa de diálogo "Autorizar o Cloud Shell", clique em Autorizar. Ao clicar em Autorizar, você permite que os comandos
gcloud
executados no Cloud Shell usem suas credenciais de usuário para autenticar nas APIs do Google.Ative o Resource Manager, o GKE, o GKE Hub, a autoridade certificadora do Anthos Service Mesh e as APIs CA Service:
gcloud services enable \ cloudresourcemanager.googleapis.com \ container.googleapis.com \ gkehub.googleapis.com \ meshca.googleapis.com \ privateca.googleapis.com
Configurar o serviço de CA
Nesta seção, você criará uma CA raiz e duas CAs subordinadas no CA Service. Uma CA subordinada emite certificados para o gateway de entrada e a outra CA subordinada emite certificados para proxies sidecar na malha.
Para simplificar, use o mesmo projeto para o cluster do GKE e as CAs raiz e subordinada neste tutorial. No seu ambiente, é possível usar um projeto diferente para o cluster do GKE e as CAs.
No Cloud Shell, crie um pool de CAs para usar na CA raiz:
gcloud privateca pools create ROOT_CA_POOL \ --location CA_LOCATION \ --tier enterprise
- ROOT_CA_POOL é o nome do pool de CAs. Por exemplo,
root-ca-pool-tutorial
. - CA_LOCATION é o local do pool de CAs. Por exemplo,
us-central1
.
É possível listar os locais disponíveis do CA Service usando este comando:
gcloud privateca locations list
- ROOT_CA_POOL é o nome do pool de CAs. Por exemplo,
Crie e ative uma CA 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 você quer usar para a CA
raiz. Por exemplo,
root-ca-tutorial
.
- ROOT_CA é o nome que você quer usar para a CA
raiz. Por exemplo,
Crie um pool de CAs para usar na CA 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
pool de CAs. Por exemplo,
subordinate-ca-mtls-pool-gateways-tutorial
.
- SUBORDINATE_CA_POOL_GATEWAYS é o nome do
pool de CAs. Por exemplo,
Crie e ative a CA 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 você quer
usar para a CA subordinada. Por exemplo,
subordinate-ca-mtls-gateways-tutorial
. - A sinalização
--use-preset-profile
configura a CA subordinada para usar o perfil de certificado Subordinado mTLS. Esse perfil permite que a CA subordinada emita certificados TLS de cliente e servidor para mTLS.
Se você quiser que o gateway de entrada use TLS simples em vez de mTLS, a CA subordinada precisa emitir apenas certificados TLS de servidor. Nesse caso, é possível usar o perfil de certificado TLS subordinado de servidor (
subordinate_server_tls_pathlen_0
).- SUBORDINATE_CA_GATEWAYS é o nome que você quer
usar para a CA subordinada. Por exemplo,
Crie uma política de emissão de certificado:
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
Essa política de emissão restringe as CAs a emitir apenas certificados para cargas de trabalho na malha.
Crie um pool de CAs para usar a CA subordinada que emite certificados para os proxies sidecar na malha. Aplique a política de emissão ao pool de CAs:
gcloud privateca pools create SUBORDINATE_CA_POOL_SIDECARS \ --issuance-policy policy.yaml \ --location CA_LOCATION \ --tier devops
- SUBORDINATE_CA_POOL_SIDECARS é o nome do
pool de CAs. Por exemplo,
subordinate-ca-mtls-pool-sidecars-tutorial
.
- SUBORDINATE_CA_POOL_SIDECARS é o nome do
pool de CAs. Por exemplo,
Crie e ative a CA 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 você quer
usar para a CA subordinada. Por exemplo,
subordinate-ca-mtls-sidecars-tutorial
.
- SUBORDINATE_CA_GATEWAYS é o nome que você quer
usar para a CA subordinada. Por exemplo,
Crie um cluster do Google Kubernetes Engine
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 você quer usar para o cluster. Por exemplo,
asm-ingress-cert-manager-ca-service
.Substitua ZONE pela zona que você quer usar para o cluster. Por exemplo,
us-central1-f
.Observe o seguinte sobre o comando:
- A sinalização
--release-channel
seleciona o canal de lançamento do GKE para o cluster. - O Anthos Service Mesh e o emissor do CA Service para
a ferramenta cert-manager exigem que você defina o escopo
cloud-platform
nos nós do cluster. - O argumento
--workload-pool
ativa a identidade da carga de trabalho, o que permite que a conta de serviço do Kubernetes do emissor de CA personifique uma conta de serviço do Google. Essa representação significa que os pods do emissor do serviço de CA podem acessar a API CA Service sem fazer o download de um arquivo de chave para a conta de serviço do Google.
- A sinalização
Conceda permissões de administrador de cluster à sua conta de usuário:
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin \ --user $(gcloud config get-value core/account)
Você precisa das permissões fornecidas pelo ClusterRole
cluster-admin
do Kubernetes para criar as regras de controle de acesso baseado em papéis (RBAC, na sigla em inglês) para o Anthos Service Mesh e para instalar a ferramenta cert-manager.
Instalar o plano de controle do Anthos Service Mesh
Neste tutorial, você instalará o Anthos Service Mesh gerenciado para um cluster do GKE no Google Cloud, com todos os recursos em um projeto. No seu ambiente, é possível aplicar a solução descrita neste documento usando o Anthos Service Mesh gerenciado ou um plano de controle no cluster.
O Anthos Service Mesh oferece várias opções de instalação para diferentes cenários. Depois de concluir este tutorial, recomendamos que você leia o guia de instalação para selecionar a opção que melhor se adapta ao seu ambiente.
No Cloud Shell, faça o download da ferramenta de instalação
asmcli
:curl --location --output asmcli https://storage.googleapis.com/csm-artifacts/asm/asmcli_1.23 chmod +x asmcli
Use
asmcli
para instalar o plano de controle do Anthos Service Mesh.Instale o plano de controle do Anthos 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
As sinalizações
--ca gcp_cas
e--ca_pool
configuram o plano de controle do Anthos Service Mesh para usar o pool de CAs secundários no CA Service para emitir certificados para proxies sidecar na malha.A sinalização
--enable_registration
registra o cluster do GKE para a frota no projeto especificado pela sinalização--fleet_id
. Neste tutorial, o cluster do GKE e a frota usam o mesmo projeto.A sinalização
--managed
configura um plano de controle do Anthos Service Mesh gerenciado.A sinalização
--output_dir
especifica um diretório queasmcli
usa para fazer o download de arquivos e configurações necessários para instalar o Anthos Service Mesh. Você usará esses arquivos posteriormente no tutorial.
A instalação leva alguns minutos. Quando a instalação estiver concluída, você verá a seguinte saída:
asmcli: Successfully installed ASM.
Instale o gateway de entrada
No Cloud Shell, crie um namespace do Kubernetes para o gateway de entrada:
kubectl create namespace GATEWAY_NAMESPACE
- GATEWAY_NAMESPACE é o nome do
namespace que você quer usar para o gateway de entrada. Por exemplo,
istio-ingress
.
- GATEWAY_NAMESPACE é o nome do
namespace que você quer usar para o gateway de entrada. Por exemplo,
Reserve um endereço IP interno estático para usar no balanceador de carga de rede do gateway de entrada interno:
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 cluster usar a zona
us-central1-f
, substitua REGION porus-central1
.
Esse comando reserva um endereço IP a partir da sub-rede padrão na região especificada.
- 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 cluster usar a zona
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
Observe o seguinte sobre o manifesto do operador:
O campo
revision
especifica o canal de lançamento do Anthos Service Mesh gerenciado a ser usado para o plano de dados. Altere o valor desse campo se você usar os canais de lançamento rápido ou estável para o plano de controle.O
annotation
,label
eimage
especificados na seçãooverlays
permitem a injeção automática de configuração do proxy para a implantação do gateway de entrada.O campo
loadBalancerIP
especifica o endereço IP a ser usado para o balanceador de carga. Se você remover esse campo do manifesto, o balanceador de carga usará um endereço IP temporário.A anotação de serviço
networking.gke.io/load-balancer-type: Internal
no gateway de entrada significa que o GKE provisiona um balanceador de carga de rede de passagem interno na frente dos pods do gateway de entrada. Se você remover essa anotação, o GKE provisionará um balanceador de carga de rede de passagem externa.A anotação de serviço opcional
networking.gke.io/internal-load-balancer-allow-global-access: "true"
permite que clientes de qualquer região na VPC acessem o balanceador de carga de rede de passagem interno. Se você remover essa anotação, o balanceador de carga de rede de passagem interno só aceitará o tráfego de clientes na mesma região na VPC.
Crie o manifesto de instalação do gateway de entrada usando o manifesto do operador e a ferramenta
istioctl
que o scriptasmcli
fez download quando você instalou o plano de controle:./asm-files/istioctl manifest generate \ --filename ingressgateway-operator.yaml \ --output ingressgateway
Instale o gateway de entrada.
kubectl apply --recursive --filename ingressgateway/
Instalar a ferramenta cert-manager
No Cloud Shell, faça o download 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 leva cerca de um minuto para ser concluída.
Instalar o controlador do emissor do CA Service
O controlador do emissor do CA Service permite que a ferramenta cert-manager solicite certificados usando o CA Service. O controlador usa o mecanismo de extensão do emissor externo da ferramenta cert-manager.
No Cloud Shell, crie uma conta de serviço do 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 do Google. Por exemplo,
cert-manager-ca-service-issuer
.
O controlador emissor do Certificate Authority Service usa essa conta de serviço do Google para fazer a autenticação nas APIs Certificate Authority Service.
- CAS_ISSUER_GSA é o nome da conta
de serviço do Google. Por exemplo,
Crie uma vinculação de política de gerenciamento de identidade e acesso para permitir que a conta de serviço do Google do controlador do emissor do Certificate Authority Service solicite certificados pelo pool de CAs que contém a CA 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
Faça o download do manifesto de instalação do controlador do emissor do Certificate Authority Service:
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"
Crie uma vinculação de política do IAM para permitir que a conta de serviço do Kubernetes
ksa-google-cas-issuer
no namespacecert-manager
personifique a conta de serviço do Google (GSA, na sigla em inglês) usando a Identidade da carga de trabalho: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 de emissor do CA Service usam a conta de serviço
ksa-google-cas-issuer
do Kubernetes.Instale o controlador do emissor do CA Service no cluster do GKE:
kubectl apply --filename ca-service-issuer.yaml
Adicione a anotação da identidade da carga de trabalho
iam.gke.io/gcp-service-account
à conta de serviço do Kubernetes usada pelos pods do controlador do emissor do CA Service:kubectl annotate serviceaccount ksa-google-cas-issuer --namespace cert-manager \ "iam.gke.io/gcp-service-account=CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com"
Essa anotação informa ao GKE que a conta de serviço do Kubernetes pode personificar a conta de serviço do Google para acessar as APIs do Google.
Criar um emissor de certificado
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 provisione certificados pelo pool de CAs subordinados no namespace do gateway de entrada.
Implantar um aplicativo de amostra
Nesta seção, você vai verificar se a ferramenta cert-manager pode usar o emissor do CA Service para receber certificados no CA Service. Para verificar, implante um aplicativo de amostra com configuração de roteamento de solicitações e um certificado para o gateway de entrada.
No Cloud Shell, crie um namespace para os recursos do aplicativo de amostra:
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 namespace do
aplicativo de amostra. Por exemplo,
sample-app
.
A anotação
mesh.cloud.google.com/proxy
ativa o plano de dados gerenciado para o namespace.O rótulo
istio.io/rev: asm-managed
seleciona o canal de lançamento regular para o plano de dados gerenciado no namespace do aplicativo de amostra. Altere o valor desse rótulo se você usar os canais de lançamento rápido ou estável.- APP_NAMESPACE é o nome do namespace do
aplicativo de amostra. Por exemplo,
Crie um recurso de implantação para o aplicativo de amostra:
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
Crie um recurso de serviço para o aplicativo de amostra:
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
.
- SERVICE_NAME é o nome do serviço; Por exemplo,
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 namespace do certificado precisa corresponder ao namespace do gateway de entrada. Normalmente, somente os administradores da plataforma podem alterar recursos nesse namespace, já que as mudanças podem afetar toda a malha de serviço. A ferramenta cert-manager cria o recurso de secret para o certificado TLS no mesmo namespace. Isso significa que os administradores do aplicativo não precisam ter acesso ao namespace do gateway de entrada.
É possível adicionar outros nomes de host à lista
dnsNames
no certificado. Esses nomes de host são incluídos no certificado como Nomes alternativos de assunto (SANs, na sigla em inglês).Crie um recurso de gateway para o aplicativo de amostra:
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 do gateway. Por exemplo,
hello
. - O campo
credentialName
no gateway corresponde ao camposecretName
no certificado. A ferramenta cert-manager cria um secret do Kubernetes com o certificado TLS do CA Service. Esse certificado permite que o gateway de entrada encerre o tráfego TLS destinado ahello.example.com
.
O manifesto do gateway especifica o TLS MÚTUO (mTLS). Se você quiser configurar o gateway para o TLS normal, defina o modo do TLS do gateway como
SIMPLE
.- GATEWAY_NAME é o nome do gateway. Por exemplo,
Crie um recurso VirtualService para o aplicativo de amostra:
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 namespaces diferentes. Esse padrão comum restringe as alterações no roteamento baseado em host no gateway para os administradores da plataforma que têm permissões para alterar recursos no namespace do gateway de entrada.
Os administradores do aplicativo com permissões para editar o VirtualService no namespace de aplicativo de amostra podem alterar o roteamento por outros campos de solicitação, como o caminho do URL, sem coordenar com os administradores da plataforma.
Se você quiser explorar outras opções de configuração, leia a documentação da API para ver os recursos de Certificado, Gateway e VirtualService.
É possível aplicar políticas de autenticação e autorização ao tráfego que entra na malha de serviço com o gateway de entrada. Para fazer isso, leia a documentação das APIs PeerAuthentication e AuthorizationPolicy do Istio.
Verificar a solução
Nesta seção, você vai verificar se é possível enviar solicitações HTTPS usando o mTLS para o aplicativo de amostra de fora da malha de serviço. Para verificar, crie uma instância de VM do Compute Engine, solicite um certificado TLS pelo CA Service e use esse certificado para autenticar a solicitação no aplicativo de amostra.
Você precisa ter acesso SSH à instância de VM. A rede padrão inclui uma regra de firewall que permite o acesso SSH. Se você não tiver acesso SSH, siga a documentação sobre regras de firewall para criar uma regra de firewall que permita conexões TCP de entrada na porta 22.
No Cloud Shell, crie uma conta de serviço do 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 do Google. Por exemplo,
cas-tutorial-client
.
Atribua essa conta de serviço do Google à instância de VM do Compute Engine.
- CLIENT_VM_GSA é o nome da conta
de serviço do Google. Por exemplo,
Conceda o papel de Solicitante de certificado do CA Service no pool de CA subordinada dos gateways à conta de serviço do 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
Esse papel fornece permissões para solicitar certificados pelo pool de CA.
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 escopo
cloud-platform
para acessar a API CA Service.Salve o endereço IP do balanceador de carga de rede de passagem interna do gateway de entrada em um arquivo:
kubectl get services istio-ingressgateway \ --namespace GATEWAY_NAMESPACE \ --output jsonpath='{.status.loadBalancer.ingress[0].ip}' > ilb-ip.txt
Salve o certificado de chave pública da CA raiz em um arquivo:
gcloud privateca roots describe ROOT_CA \ --location CA_LOCATION \ --pool ROOT_CA_POOL \ --format 'value(pemCaCertificates)' > root-ca-cert.pem
Copie o certificado de CA raiz e o arquivo que contém o endereço IP do balanceador de carga de rede de passagem interno do gateway de entrada na instância de VM:
gcloud compute scp root-ca-cert.pem ilb-ip.txt cas-tutorial-client:~ \ --zone ZONE
Conecte-se à instância de VM usando o SSH.
gcloud compute ssh cas-tutorial-client --zone ZONE
Execute o restante dos comandos desta seção na sessão do SSH.
Instale os pacotes
ca-certificates
ecoreutils
e as ferramentas de linha de comandocurl
,openssl
ejq
:sudo apt-get update --yes sudo apt-get install --yes ca-certificates coreutils curl jq openssl
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
Consulte o servidor de metadados para ver o endereço de e-mail da identidade da conta de serviço do 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)
Crie um arquivo JSON que você usa como o corpo da solicitação ao solicitar 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 sobre os campos na seção de configuração, consulte o tipo
CertificateConfig
na documentação da API CA Service.Solicite um token de acesso do OAuth 2.0 pelo 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")
Esse token de acesso fornece as permissões concedidas à conta de serviço do Google anexada à instância de VM.
Solicite um certificado TLS de cliente pela API CA Service e armazene o corpo da resposta em um arquivo:
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 a solicitação da API.
Salve o certificado do cliente e a cadeia de certificados em um arquivo:
jq --raw-output --join-output ".pemCertificate , .pemCertificateChain[]" response.json > client-cert-chain.pem
Use
curl
para enviar uma solicitação HTTPS pela instância de VM para o aplicativo de amostra: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
A saída é assim:
Hello, world!
Essa resposta mostra que
curl
enviou a solicitação HTTPS usando mTLS. O aplicativo de amostra respondeu com a mensagem que você vê na saída do terminal.O comando
curl
faz o seguinte:As sinalizações
--cert
e--key
instruemcurl
a usar o certificado TLS de cliente e a chave privada para autenticar a solicitação. O arquivo de certificado do cliente contém a cadeia completa de certificados, desde o certificado do cliente até a CA raiz.A sinalização
--cacert
instruicurl
a verificar se a CA raiz criada neste tutorial, ou uma das CAs subordinadas dela, emitiu o certificado do servidor.Se você omitir essa sinalização,
curl
tentará verificar o certificado do servidor usando o pacote de CA padrão do sistema operacional, como o pacoteca-certificates
no Debian. A verificação falha porque o pacote da CA padrão não inclui a CA raiz criada neste tutorial.A sinalização
--resolve
instruicurl
a usar o endereço IP do balanceador de carga de rede de passagem interno como destino para que as solicitações hospedemhello.example.com
na porta 443.Se você omitir essa sinalização,
curl
tentará usar o DNS para resolver o nome de hosthello.example.com
. A resolução DNS falha porque não há entrada de DNS para esse nome de host.No seu ambiente, recomendamos que você crie um registro A de DNS que aponte para o endereço IP do balanceador de carga de rede de passagem interno (
$LOAD_BALANCER_IP
). Para criar esse registro usando o Cloud DNS, siga a documentação sobre como gerenciar registros.A sinalização
--silent
suprime os relatórios de progresso de download de resposta na saída do terminal.O comando envia a saída do curl para
head -n1
. O resultado é que a saída no terminal inclui apenas a primeira linha do corpo da resposta.
Saia da sessão SSH:
exit
Nesta seção, você solicitou um certificado TLS de cliente diretamente pela API CA Service. Caso o cliente seja o gateway de saída de outra malha de serviço em um cluster separado do Kubernetes será possível usar a ferramenta cert-manager e o emissor do Certificate Authority Service com a mesma CA raiz para fornecer ao cliente. certificados para o gateway de saída.
Em outras situações, é possível usar ferramentas como o Hashicorp Vault, Terraform ou
gcloud
para solicitar certificados TLS de cliente para cargas de trabalho fora da malha
de serviço. Para saber mais, consulte a documentação do CA Service para ver
exemplos de soluções e a
documentação gcloud
do CA Service.
(Opcional) Adicionar certificados de CA ao armazenamento confiável
Esta seção opcional mostra como adicionar certificados de CA ao armazenamento de certificados de CA confiáveis para a distribuição do Linux do Debian. Essas instruções também se aplicam a distribuições derivadas do Debian, como o Ubuntu.
Adicionar certificados de CA a esse armazenamento significa que você não precisa especificar
o local dos certificados de CA confiáveis ao enviar solicitações HTTPS usando curl
,
Python, Go e Ruby.
Conecte-se à instância de VM usando o SSH.
gcloud compute ssh cas-tutorial-client --zone ZONE
Execute o restante dos comandos desta seção na sessão do SSH.
Copie o certificado da CA raiz para o diretório
/usr/local/share/ca-certificates
e verifique se o arquivo tem a extensão.crt
:sudo cp root-ca-cert.pem /usr/local/share/ca-certificates/cas-rootca.crt
Defina as permissões do arquivo para que todos os usuários possam ler o arquivo do certificado de CA raiz:
sudo chmod 644 /usr/local/share/ca-certificates/cas-rootca.crt
Execute o script
update-ca-certificates
:sudo update-ca-certificates
Esse script adiciona o certificado ao conjunto de certificados confiáveis no diretório
/etc/ssl/certs
e ao arquivo/etc/ssl/certs/ca-certificates.crt
.A saída é esta:
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done.
Use
curl
para enviar uma solicitação HTTPS pela instância de VM para o aplicativo de amostra: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
A saída é assim:
Hello, world!
Essa resposta mostra que
curl
enviou a solicitação HTTPS usando mTLS e validou o certificado TLS de servidor do gateway de entrada usando o armazenamento de certificados padrão da CA.Saia da sessão SSH:
exit
Resolver problemas
Se o controlador do emissor do CA Service não criar o secret do certificado TLS, visualize os registros do controlador do emissor do CA Service:
kubectl logs deployment/google-cas-issuer --namespace cert-manager
Se você tiver problemas para instalar o Anthos Service Mesh,
execute a ferramenta asmcli
para validar o projeto do Cloud e o cluster do GKE.
Se você tiver problemas ao seguir este tutorial, recomendamos que consulte estes documentos:
- Perguntas frequentes sobre o CA Service
- Solução de problemas do Anthos Service Mesh passo a passo
- Como resolver problemas gerenciados do Anthos Service Mesh
- Problemas comuns das operações do Istio
- Solução de problemas do GKE
- Como solucionar problemas de clusters do Kubernetes
Limpar
Para evitar cobranças recorrentes na conta do Google Cloud pelos recursos usados neste tutorial, é possível excluir o projeto ou excluir os recursos individuais.
Exclua o projeto
No Cloud Shell, exclua o projeto:
gcloud projects delete PROJECT_ID
Excluir os recursos
Se você quiser manter o projeto do Google Cloud usado neste tutorial, exclua os recursos individuais:
No Cloud Shell, cancele o registro do cluster do GKE no GKE Hub:
gcloud container hub memberships unregister CLUSTER_NAME \ --gke-cluster ZONE/CLUSTER_NAME
Exclua o cluster do GKE:
gcloud container clusters delete CLUSTER_NAME \ --zone ZONE --async --quiet
Exclua as vinculações de política do IAM no pool de CA subordinada:
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
Desative e programe a exclusão das CAs subordinadas e da CA 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
Exclua a vinculação da política do IAM da conta de serviço do controlador do emissor do CA Service:
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
Exclua as contas de serviço do 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
Exclua o endereço IP do balanceador de carga reservado:
gcloud compute addresses delete asm-ingress-gateway-ilb \ --region REGION --quiet
Exclua a instância de VM do Compute Engine:
gcloud compute instances delete cas-tutorial-client \ --zone ZONE --quiet
A seguir
- conheça outros guias de instruções do Certificate Authority Service;
- saiba mais sobre o Anthos Service Mesh, um pacote de ferramentas baseado no Istio que ajuda a monitorar e gerenciar uma malha de serviço confiável no local e no Google Cloud;
- conheça os guias de instruções do Anthos Service Mesh;