Configurar o Service Security na malha de serviço do arquivo secundário do Envoy no GKE

Esta página descreve como configurar recursos de segurança na malha de serviço de sidecar do Envoy no GKE.

Pré-requisitos

Como ponto de partida, este guia pressupõe que você já:

Configurar políticas de autorização em sidecars no GKE

Esta seção mostra como configurar diferentes tipos de políticas de autorização nos arquivos secundários do Cloud Service Mesh no GKE.

Antes de criar uma política de autorização, é preciso instalar o GCPAuthzPolicy CustomResourceDefinition (CRD):

curl https://github.com/GoogleCloudPlatform/gke-networking-recipes/blob/main/gateway-api/config/mesh/crd/experimental/gcpauthzpolicy.yaml \
| kubectl apply -f -

As políticas de autorização podem aplicar o controle de acesso ao tráfego que entra nos sidecars do Envoy. As políticas podem ser aplicadas em implantações do Kubernetes. A implantação precisa estar no mesmo namespace que a política de autorização.

Política de autorização para negar todas as solicitações

Quando você tem uma carga de trabalho que precisa fazer apenas chamadas de saída, como um job cron, é possível configurar uma política de autorização para negar todas as solicitações HTTP recebidas na carga de trabalho. O exemplo a seguir nega as solicitações HTTP recebidas para a carga de trabalho whereami.

Siga estas etapas para criar e aplicar a política de autorização de negação:

  1. Crie uma política de negação criando um arquivo chamado deny-all-authz-policy.yaml:

    cat >deny-all-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: myworkload-authz
  namespace: sidecar-example
spec:
targetRefs:
- kind: Deployment
  name: wherami
httpRules:
- to:
    operations:
    - paths:
      - type: Prefix
        value: "/"
action: DENY
EOF

  2. Aplique a política:

    kubectl apply -f deny-all-authz-policy.yaml

Política de autorização para permitir solicitações

Também é possível configurar uma política de permissão que permita somente solicitações que correspondam a uma critérios específicos, rejeitando o restante. O exemplo a seguir configura uma política de autorização no whereami, em que apenas solicitações GET que têm o cabeçalho http x-user-role:admin presente na solicitação serão permitidas.

Siga as etapas abaixo para criar e aplicar a política de permissão de autorização e excluir a política de negação criada anteriormente antes de adicionar esta política para conferir os resultados:

  1. Para criar uma política personalizada, crie um arquivo chamado allow-authz-policy.yaml:

    cat >allow-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: myworkload-authz
  namespace: sidecar-example
spec:
targetRefs:
- kind: Deployment
  name: whereami
httpRules:
- to:
    operations:
    - methods: ["GET"]
  when: "request.headers['x-user-role'] == 'admin'
action: ALLOW
EOF

  2. Aplique a política:

    kubectl apply -f allow-authz-policy.yaml

Política de autorização para negar solicitações com base em regras

O exemplo a seguir nega solicitações HTTP GET recebidas para a carga de trabalho whereami quando ela está no caminho /admin.

Siga estas etapas para criar e aplicar a política de autorização de negação:

  1. Crie uma política de negação criando um arquivo chamado deny-path-authz-policy.yaml:

    cat >deny-path-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: myworkload-authz
  namespace: sidecar-example
spec:
targetRefs:
- kind: Deployment
  name: whereami
httpRules:
- to:
    operations:
    - paths:
      - type: Prefix
        value: "/admin"
      methods: ["GET"]
action: DENY
EOF

  2. Aplique a política:

    kubectl apply -f deny-path-authz-policy.yaml