Configurar a segurança de serviço na malha de serviço de arquivo secundário do Envoy no GKE
Nesta página, descrevemos como configurar recursos de segurança na malha de serviço de arquivo secundário do Envoy no GKE.
Pré-requisitos
Como ponto de partida, neste guia presume-se que você já:
- Criou um cluster do GKE e o registrou em uma frota.
- Configure uma malha de serviço de arquivo secundário do Envoy com as APIs Gateway.
Configurar políticas de autorização em sidecars no GKE
Nesta seção, mostramos como configurar diferentes tipos de políticas de autorização em sidecars do Cloud Service Mesh no GKE.
Antes de criar uma política de autorização, instale a 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 deve fazer apenas chamadas de saída, como um
job do cron, é possível configurar uma política de autorização para negar qualquer solicitação HTTP
de entrada para a carga de trabalho. O exemplo a seguir nega 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:
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: whereami httpRules: - to: operations: - paths: - type: Prefix value: "/" action: DENY EOF
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 permite apenas solicitações que atendam a um
critério específico e rejeita 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 estas etapas para criar e aplicar a política de autorização de permissão e excluir a política de negação criada anteriormente antes de adicionar essa política para ver os resultados:
Crie uma política personalizada criando 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
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:
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
Aplique a política:
kubectl apply -f deny-path-authz-policy.yaml