Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance da S3NS. Consulte Diferenças do Google Cloud para saber mais.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Preparar a rede ambiente do GKE

Autopilot Standard

Esta página mostra como ativar a rede ambiente em um cluster novo ou atual, registrar namespaces e cargas de trabalho para ativar o redirecionamento de tráfego ambiente e configurar políticas de autorização e mTLS.

Para mais informações sobre a arquitetura, os benefícios e os recursos da rede ambiente, consulte a Visão geral da rede ambiente.

Pré-requisitos e limitações

Antes de configurar a rede ambiente, revise as seguintes limitações de recursos, requisitos de versão e restrições de escopo:

Versão do GKE:requer a versão 1.35.2-gke.1842000 ou mais recente do GKE.
Suporte regional:os clusters precisam ser criados em uma região compatível com o Cloud Service Mesh regional.
Interoperabilidade de carga de trabalho:as cargas de trabalho registradas em rede ambiente não podem interoperar com cargas de trabalho injetadas por sidecar ou gRPC sem proxy na prévia privada.
Recursos não compatíveis:
- Campo trafficDistribution do serviço do Kubernetes.
- Serviços sem comando.
- GKE Sandbox (gVisor).
Aviso de segurança:se o componente gke-ambient-nriplugin ficar indisponível em um nó, a autenticação e a autorização do tráfego de entrada poderão ser ignoradas.

Antes de começar

Conclua as etapas de configuração de pré-requisitos a seguir em Cloud de Confiance by S3NS:

Crie ou selecione um projeto.

Ative as APIs necessárias:

gcloud services enable \
    privateca.googleapis.com \
    gkehub.googleapis.com \
    compute.googleapis.com \
    container.googleapis.com \
    trafficdirector.googleapis.com \
    networkservices.googleapis.com \
    networksecurity.googleapis.com \
    telemetry.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com

Configure a autenticação de identidade da carga de trabalho gerenciada para o GKE.

Ativar a rede ambiente em um novo cluster

Execute o comando a seguir para criar um cluster do GKE com a rede ambiente ativada:

Criar um cluster do GKE com a rede ambiente ativada

gcloud beta container clusters create CLUSTER_NAME \
    --machine-type=e2-standard-4 \
    --enable-ambient-networking \
    --enable-dataplane-v2 \
    --enable-fleet \
    --gateway-api=standard \
    --location=CLUSTER_LOCATION \
    --release-channel=rapid \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog

Dois DaemonSets agora são executados no namespace gke-managed-ambient.

Ativar a rede ambiente em um cluster atual

Siga estas etapas para ativar o ambient mesh em um cluster do GKE atual:

Verifique se o cluster atende aos seguintes requisitos:
- Versão 1.35.2-gke.1842000 ou mais recente.
- O GKE Dataplane V2 está ativado.
- O tipo de máquina precisa ser e2-standard-4 ou maior.
- O cluster precisa ser adicionado a uma frota.
- O cluster precisa ter a API Gateway e a Identidade da carga de trabalho ativadas.

Ative a rede ambiente em um cluster atual:

gcloud beta container clusters update CLUSTER_NAME \
    --enable-ambient-networking \
    --location=CLUSTER_LOCATION \
    --enable-fleet

Dois DaemonSets agora são executados no namespace gke-managed-ambient.

Para verificar, aponte a CLI para o cluster:

gcloud beta container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_LOCATION

Receba os daemonsets no namespace gke-managed-ambient:

kubectl get daemonset -n gke-managed-ambient

A saída é semelhante a:

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
gke-ambient-nriplugin   9         9         9       9            9           4d1h
gke-ambient-proxy       9         9         9       9            9           4d1h

Registrar um namespace para rede ambiente

Siga estas etapas para implantar um aplicativo de amostra e ativar o redirecionamento de tráfego ambiente no namespace dele:

Implante um aplicativo de amostra:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: ambient-test
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: client
  namespace: ambient-test
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: server
  namespace: ambient-test
---
apiVersion: v1
kind: Service
metadata:
  name: server
  namespace: ambient-test
  labels:
    app: server
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: client
  namespace: ambient-test
  labels:
    app: client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: client
  template:
    metadata:
      labels:
        app: client
    spec:
      serviceAccountName: client
      containers:
      - name: nginx
        image: nginx:1.29.6
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
  namespace: ambient-test
  labels:
    app: server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
    spec:
      serviceAccountName: server
      containers:
      - name: nginx
        image: nginx:1.29.6
        readinessProbe:
          httpGet:
            path: /
            port: 80
EOF

Identifique o namespace ambient-test para ativar o redirecionamento de tráfego pelo proxy ambiente do GKE:
```
kubectl label namespace ambient-test networking.gke.io/dataplane-mode=ambient
```

Verifique se os pods individuais no namespace foram configurados para redirecionamento de tráfego:

kubectl get pods -n ambient-test -o yaml | grep redirection

A saída é semelhante a:

ambient.networking.gke.io/redirection: enabled
ambient.networking.gke.io/redirection: enabled

Teste o tráfego do cliente para o servidor:

kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Para verificar se o tráfego de texto simples está passando por gke-ambient-proxy, confira os registros de acesso na Análise de registros e pesquise o gke-ambient-node-proxy-accesslog:

Acessar a Análise de registros
Opcionalmente, ative a geração de métricas da camada 4 para cargas de trabalho no namespace:
```
kubectl label namespace ambient-test networking.gke.io/ambient-network-metrics=enabled
```
Depois de ativadas, as métricas de carga de trabalho ficam disponíveis no Cloud Monitoring em Monitoramento de serviços de rede.

Ativar o mTLS para um serviço

Depois de ativar o redirecionamento de tráfego para cargas de trabalho em um namespace, aplique políticas para impor criptografia, autenticação e autorização.

Configure uma política permissiva de mTLS nas cargas de trabalho do lado do servidor:
```
kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPServerTLSPolicy
metadata:
  name: server
  namespace: ambient-test
spec:
  mtlsMode: Permissive
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
EOF
```
Essa política faz com que os pods aceitem tráfego mTLS e de texto simples. O mTLS permissivo usa a detecção de tráfego para identificar se ele é mTLS ou texto simples. Isso vai interromper o tráfego de aplicativos que usam o próprio TLS ou um protocolo "o servidor fala primeiro", como o MySQL.

Verifique se a política foi aceita pelo controlador:

kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

A saída é semelhante a:

[...]

    Conditions:
    Last Transition Time:  2026-03-25T17:47:30Z
    Message:
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Controller Name:         networking.gke.io/dpv2-1n
Events:
Type    Reason  Age                   From                   Message
----    ------  ----                  ----                   -------
Normal  Sync    108s (x2 over 2m20s)  sc-dpv2-1n-controller  Sync on Mesh dpv2-1n-fqtx-mesh succeeded

A propagação da política pode levar até três minutos após a aceitação do controlador. Aguarde três minutos antes de continuar.

Configure uma política de mTLS do lado do cliente que tenha como destino o serviço:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPClientTLSPolicy
metadata:
  name: server-mtls
  namespace: ambient-test
spec:
  targetRefs:
  - group: ""
    kind: Service
    name: server
  subjectAltNames:
  - uri: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/server
EOF

Essa política configura os clientes registrados para originar tráfego mTLS para o serviço do servidor. Talvez seja necessário aguardar pelo menos dois minutos antes de prosseguir para a próxima etapa.

Verifique se a política foi aceita pelo controlador:

kubectl describe gcpclienttlspolicies -n ambient-test server-mtls | grep -A50 Status

A saída é semelhante a:

[...]
Status:
Conditions:
    Last Transition Time:  2024-10-13T01:15:03Z
    Message:
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted

Teste o tráfego do cliente para o servidor:
```
kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
O tráfego dos pods inscritos na rede ambiente para o serviço de servidor no namespace ambient-test agora deve usar mTLS.
Para verificar se as conexões estão usando mTLS, confira os registros de acesso no Análise de registros e pesquise o nome do registro personalizado:

Acessar a Análise de registros

Atualize a GCPServerTLSPolicy atual para mudar o mode de Permissive para Strict no serviço do servidor para que os pods de carga de trabalho não aceitem mais tráfego de texto simples:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPServerTLSPolicy
metadata:
  name: server
  namespace: ambient-test
spec:
  mtlsMode: Strict
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
EOF

Verifique se a política foi aceita:

kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

A saída é semelhante a:

Name:         server

<...>

UID:                 e4f2a7a3-69aa-4528-8ea6-6f1bf2142011
Spec:
Mtls Mode:  Strict
Target Refs:
Group:
Kind:   Pod
Selector:
  Match Labels:
    App:  server
Status:
Ancestors:
    Ancestor Ref:
    Group:
    Kind:   Pod
    Name:   app=server
    Conditions:
    Last Transition Time:  2026-03-25T22:33:54Z
    Message:
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Controller Name:         networking.gke.io/dpv2-1n
Events:
Type    Reason  Age                  From                   Message
----    ------  ----                 ----                   -------
Normal  Sync    43s (x5 over 4m57s)  sc-dpv2-1n-controller  Sync on Mesh dpv2-1n-2cdi-mesh succeeded

Todo o tráfego de texto simples para o serviço do servidor será rejeitado.

Para verificar se o tráfego de texto simples está sendo rejeitado, envie tráfego para o serviço de servidor de um cliente que NÃO está registrado na rede ambiente:

kubectl create namespace noambient-test && \
kubectl run -it -n noambient-test --rm curl --image=nginx -- \
    /bin/curl -fsLSv http://server.ambient-test.svc.cluster.local

Essa conexão vai falhar com uma mensagem semelhante a esta:

* Request completely sent off
* Empty reply from server
* shutting down connection #0
curl: (52) Empty reply from server

Definir a política de autorização da camada 4

Para aplicar a autorização baseada em identidade, os proprietários da carga de trabalho especificam rótulos de pod no seletor de política. Os proprietários de namespaces aplicam políticas em todo o namespace sem seletores.

Aplique a seguinte política para garantir que apenas o cliente possa se comunicar com o servidor:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-client
  namespace: ambient-test
spec:
  action: ALLOW
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
  rules:
  - from:
      sources:
      - principals:
        - principalSelector: CLIENT_CERT_URI_SAN
          principal:
            type: Exact
            value: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client
EOF

Essa política é aplicada ao tráfego para pods de servidor no namespace ambient-test. Isso garante que o tráfego só seja permitido de fontes com a identidade SPIFFE spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client.

Verifique se a aplicação da política é permitida enviando uma solicitação de amostra da conta de serviço do cliente.

kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Verifique se a aplicação da política não é permitida enviando uma solicitação de amostra da conta de serviço do servidor.

kubectl exec -it deploy/server -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

A saída é semelhante a:

curl: (52) Empty reply from server
command terminated with exit code 52

Use a Análise de registros para conferir o registro de aplicação da autorização. No console do Cloud de Confiance , acesse a página Análise de registros.

Acessar a Análise de registros