Configura Service Security sul mesh di servizi sidecar Envoy su GKE

Questa pagina descrive come configurare le funzionalità di sicurezza nel mesh di servizi sidecar Envoy su GKE.

Prerequisiti

Come punto di partenza, questa guida presuppone che tu abbia già:

Configura i criteri di autorizzazione sui file collaterali su GKE

In questa sezione viene illustrato come configurare diversi tipi di criteri di autorizzazione sui file collaterali di Cloud Service Mesh su GKE.

Prima di poter creare un criterio di autorizzazione, devi installare la risorsa personalizzata CustomResourceDefinition (CRD) GCPAuthzPolicy:

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

I criteri di autorizzazione possono applicare il controllo dell'accesso al traffico che entra nei file collaterali di Envoy. I criteri possono essere applicati ai deployment Kubernetes. Il deployment deve trovarsi nello stesso spazio dei nomi del criterio di autorizzazione.

Criterio di autorizzazione per rifiutare tutte le richieste

Quando hai un carico di lavoro che dovrebbe effettuare solo chiamate in uscita, ad esempio cron job, puoi configurare un criterio di autorizzazione per rifiutare qualsiasi HTTP richieste al carico di lavoro. L'esempio seguente nega le richieste HTTP in entrata al workload whereami.

Per creare e applicare il criterio di autorizzazione di rifiuto:

  1. Crea un criterio di negazione creando un file denominato 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. Applica il criterio:

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

Criterio di autorizzazione per consentire le richieste

Puoi anche configurare un criterio di autorizzazione che consenta solo le richieste che corrispondono a criteri specifici rifiutando le altre. L'esempio seguente configura un criterio di autorizzazione su whereamiin cui saranno consentite solo le richieste GET che hanno l'intestazione HTTP x-user-role:admin presente nella richiesta.

Per creare e applicare il criterio di autorizzazione di autorizzazione, elimina il criterio di negazione creato in precedenza prima di aggiungerlo per visualizzare i risultati:

  1. Crea un criterio personalizzato creando un file denominato 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. Applica il criterio:

    kubectl apply -f allow-authz-policy.yaml

Criterio di autorizzazione per rifiutare le richieste in base alle regole

L'esempio seguente nega le richieste HTTP GET in entrata a il carico di lavoro whereami quando si trova nel percorso /admin .

Per creare e applicare il criterio di autorizzazione di negazione, segui questi passaggi:

  1. Crea un criterio di negazione creando un file denominato 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. Applica il criterio:

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