Use restrições da política de segurança do Cloud Service Mesh

O Policy Controller inclui uma biblioteca predefinida de modelos de restrições que podem ser usados com o conjunto de segurança do Cloud Service Mesh para auditar a conformidade das vulnerabilidades de segurança e das práticas recomendadas da sua malha.

Esta página contém instruções para aplicar manualmente um pacote de políticas. Em alternativa, pode aplicar pacotes de políticas diretamente.

Aviso: depois de escolher um método para aplicar pacotes de políticas (manual, CLI gcloud ou Google Cloud consola), a utilização de um método diferente para instalar pacotes de políticas pode causar erros no seu ambiente.

Este conjunto de restrições aborda e aplica políticas nos seguintes domínios:

• O Cloud Service Mesh aplica o tráfego mTLS
• Práticas recomendadas da AuthorizationPolicy do Cloud Service Mesh
• Aplicação da segurança de cargas de trabalho do Cloud Service Mesh

Restrições do pacote de políticas do Cloud Service Mesh

Nome da restrição	Descrição da restrição	ID do controlo
asm-policy-v0.0.1-asm-ingressgateway-label	Aplique a utilização da etiqueta istio ingressgateway apenas em pods ingressgateway	1.1.1
asm-policy-v0.0.1-asm-sidecar-injection	Impor que o sidecar do proxy do Istio seja sempre injetado nos pods de carga de trabalho	1.1.2
asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny	Aplique a AuthorizationPolicy de recusa predefinida ao nível da malha	1.2.1
asm-policy-v0.0.1-asm-authz-policy-normalization	Aplique a normalização da AuthorizationPolicy	1.2.2
asm-policy-v0.0.1-asm-authz-policy-safe-pattern	Aplique os padrões seguros da AuthorizationPolicy	1.2.3
asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls	Aplique a PeerAuthentication strict mtls ao nível da malha	1.3.1
asm-policy-v0.0.1-asm-peer-authn-strict-mtls	A aplicação de todas as PeerAuthentications não pode substituir o mtls rigoroso	1.3.2
asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers	Aplique a jwtRules outputPayloadToHeader para não conter cabeçalhos de pedidos HTTP conhecidos	1.4.1

Agrupe perfis

No pacote de políticas de segurança do Cloud Service Mesh, pode usar dois perfis com base no nível de rigor. O nível de rigor baixo tem menos restrições aplicadas, o que oferece mais flexibilidade. O nível de rigor elevado tem mais restrições aplicadas, o que oferece um controlo de políticas mais seguro.

Nível de rigor baixo

O perfil de nível de rigor baixo tem as seguintes restrições de políticas:

• A etiqueta istio:ingressgateway só pode ser usada por pods do gateway de entrada do Istio.

• Em AuthorizationPolicy, os campos hosts ou notHosts só podem ser usados se selecionar o gateway de entrada do Istio, que tem a etiqueta istio:ingressgateway.

• Em AuthorizationPolicy, quando os campos methods ou notMethods são usados, os valores têm de ser letras maiúsculas.

• Em AuthorizationPolicy, quando o campo request.headers é usado, os valores não podem conter espaços.

• No AuthorizationPolicy, quando são usados os campos paths ou notPaths, os valores têm de ser valores normalizados.

Nível de rigor elevado

O nível de rigor elevado inclui todas as restrições do nível de rigor baixo, bem como as seguintes restrições:

• Para todos os pods de carga de trabalho, não é possível aplicar a anotação sidecar.istio.io/inject: false para ignorar a injeção de proxy.

• É aplicada uma AuthorizationPolicy ao nível da malha que define uma regra de recusa predefinida.

• O elemento AuthorizationPolicy tem de seguir ALLOW-with-positive-matching ou DENY-with-negative-match.

• Em AuthorizationPolicy, quando os campos hosts ou notHosts são usados, os valores têm de ser pares de <host-name> e <host-name>:*.

• É aplicada uma malha de nível PeerAuthentication que define mTLS rigoroso.

• Para todos os PeerAuthentication na malha, o modo mTLS só pode ser UNSET ou STRICT, para seguir o mTLS rigoroso.

Definições do pacote

KPT setter	Descrição
strictness-level	Perfil de nível de rigor do pacote do Cloud Service Mesh. As opções são "Baixo" ou "Alto" (predefinição)

Antes de começar

1. Instale e inicialize a CLI do Google Cloud, que fornece os comandos gcloud e kubectl usados nestas instruções. Se usar a Cloud Shell, a Google Cloud CLI é pré-instalada.
2. Instale o Policy Controller v.1.11.2 ou superior no seu cluster com a biblioteca predefinida de modelos de restrições. Também tem de ativar o suporte para restrições referenciais, uma vez que este pacote contém restrições referenciais.
3. Certifique-se de que o Cloud Service Mesh está instalado no seu cluster.

Configure o Policy Controller para restrições referenciais

Aviso: pode substituir as suas alterações. Se já tiver um Config no espaço de nomes gatekeeper-system, tem de incluir todas as definições de personalização anteriores para preservar as alterações.

1. Guarde o seguinte manifesto YAML como policycontroller-config.yaml:

   apiVersion: config.gatekeeper.sh/v1alpha1
   kind: Config
   metadata:
     name: config
     namespace: "gatekeeper-system"
   spec:
     sync:
       syncOnly:
         - group: ""
           version: "v1"
           kind: "Namespace"
         - group: "security.istio.io"
           version: "v1beta1"
           kind: "AuthorizationPolicy"
         - group: "security.istio.io"
           version: "v1beta1"
           kind: "PeerAuthentication"
   

   Este manifesto configura o Policy Controller para monitorizar tipos específicos de objetos.

2. Aplique o manifesto policycontroller-config.yaml:

   kubectl apply -f policycontroller-config.yaml
   

Audite o pacote de políticas do Cloud Service Mesh

O Policy Controller permite-lhe aplicar políticas ao seu cluster do Kubernetes. Para ajudar a testar as suas cargas de trabalho e a respetiva conformidade relativamente às políticas de segurança da malha de serviços na nuvem descritas na tabela anterior, pode implementar estas restrições no modo "auditoria" para revelar violações e, mais importante, dar-lhe a oportunidade de as corrigir antes de as aplicar no seu cluster do Kubernetes.

Pode aplicar estas políticas com spec.enforcementAction definido como dryrun através do kubectl, kpt, ou Config Sync.

kubectl

1. (Opcional) Pré-visualize as restrições de políticas com o kubectl:

   kubectl kustomize https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

2. Aplique as restrições de políticas com o kubectl:

   kubectl apply -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

   O resultado é o seguinte:

   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny created
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-normalization created
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-safe-pattern created
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-ingressgateway-label created
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls created
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-strict-mtls created
   asmrequestauthnprohibitedoutputheaders.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers created
   asmsidecarinjection.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-sidecar-injection created
   

3. Confirme se as restrições de políticas foram instaladas e verifique se existem violações no cluster:

   kubectl get -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

   O resultado é semelhante ao seguinte:

   NAME                                                                                                       ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny   dryrun               0
   
   NAME                                                                                                     ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-normalization   dryrun               0
   
   NAME                                                                                                  ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-safe-pattern   dryrun               0
   
   NAME                                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-ingressgateway-label   dryrun               0
   
   NAME                                                                                                     ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls   dryrun               0
   
   NAME                                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-strict-mtls   dryrun               0
   
   NAME                                                                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmrequestauthnprohibitedoutputheaders.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers   dryrun               0
   
   NAME                                                                                    ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmsidecarinjection.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-sidecar-injection   dryrun               0
   

kpt

1. Instale e configure o kpt. O kpt é usado nestas instruções para personalizar e implementar recursos do Kubernetes.

2. Transfira o pacote de políticas de segurança da Cloud Service Mesh do GitHub através do kpt:

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

3. Execute a função set-enforcement-action kpt para definir a ação de aplicação das políticas como dryrun:

   kpt fn eval asm-policy-v0.0.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 \
     -- enforcementAction=dryrun
   

4. Execute a função setter do kpt para definir campos específicos das políticas de segurança da Cloud Service Mesh:

   kpt fn eval asm-policy-v0.0.1 --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \
   strictness-level="Low"
   

5. Inicialize o diretório de trabalho com o kpt, que cria um recurso para monitorizar as alterações:

   cd asm-policy-v0.0.1
   kpt live init
   

6. Aplique as restrições de políticas com o kpt:

   kpt live apply
   

   O resultado é o seguinte:

   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-authz-policy-mesh-default-deny created
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-authz-policy-normalization created
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-authz-policy-safe-pattern created
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-ingressgateway-label created
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-peer-authn-mesh-strict-mtls created
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-peer-authn-strict-mtls created
   asmsidecarinjection.constraints.gatekeeper.sh/asm-sidecar-injection created
   7 resource(s) applied. 7 created, 0 unchanged, 0 configured, 0 failed
   

7. Confirme se as restrições de políticas foram instaladas e verifique se existem violações no cluster:

   kpt live status --output table --poll-until current
   

   O estado CURRENT confirma a instalação bem-sucedida das restrições.

Config Sync

1. Instale e configure o kpt. O kpt é usado nestas instruções para personalizar e implementar recursos do Kubernetes.

Os operadores que usam o Config Sync para implementar políticas nos respetivos clusters podem usar as seguintes instruções:

1. Altere para o diretório de sincronização do Config Sync:

   cd SYNC_ROOT_DIR
   

   Nota: o Kpt v1.0.0-beta.17 e posterior cria automaticamente um ficheiro resourcegroup.yaml durante a live init, que não deve ser adicionado ao seu repositório do Config Sync. Se ainda não estiver presente, adicione resourcegroup.yaml ao ficheiro .gitignore do repositório.

   Para criar ou acrescentar .gitignore com resourcegroup.yaml:

   echo resourcegroup.yaml >> .gitignore
   

2. Crie um diretório policies dedicado:

   mkdir -p policies
   

3. Transfira o pacote de políticas de segurança da Cloud Service Mesh do GitHub através do kpt:

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1 policies/asm-policy-v0.0.1
   

4. Execute a função set-enforcement-action kpt para definir a ação de aplicação das políticas como dryrun:

   kpt fn eval policies/asm-policy-v0.0.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=dryrun
   

5. Execute a função setter do kpt para definir campos específicos das políticas de segurança da Cloud Service Mesh:

   kpt fn eval policies/asm-policy-v0.0.1 --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \
   strictness-level="Low"
   

6. (Opcional) Pré-visualize as restrições de políticas a serem criadas:

   kpt live init policies/asm-policy-v0.0.1
   kpt live apply --dry-run policies/asm-policy-v0.0.1
   

   O resultado é o seguinte:

   Dry-run strategy: client
   inventory update started
   inventory update finished
   apply phase started
   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny apply successful
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-normalization apply successful
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-safe-pattern apply successful
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-ingressgateway-label apply successful
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls apply successful
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-strict-mtls apply successful
   asmrequestauthnprohibitedoutputheaders.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers apply successful
   asmsidecarinjection.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-sidecar-injection apply successful
   apply phase finished
   inventory update started
   inventory update finished
   apply result: 8 attempted, 8 successful, 0 skipped, 0 failed
   

7. Se o diretório de sincronização do Config Sync usar o Kustomize, adicione policies/asm-policy-v0.0.1 ao kustomization.yaml raiz. Caso contrário, remova o ficheiro policies/asm-policy-v0.0.1/kustomization.yaml:

   rm SYNC_ROOT_DIR/policies/asm-policy-v0.0.1/kustomization.yaml
   

8. Envie alterações para o repositório do Config Sync:

   git add SYNC_ROOT_DIR/policies/asm-policy-v0.0.1
   git commit -m 'Adding ASM security policy audit enforcement'
   git push
   

9. Verifique o estado da instalação:

   watch gcloud beta container fleet config-management status --project PROJECT_ID
   

   O estado SYNCED confirma a instalação das políticas.

Veja as violações de políticas

Depois de instaladas no modo de auditoria, as restrições de políticas no cluster podem ser vistas na IU através do Painel de controlo do Policy Controller.

Também pode usar kubectl para ver as violações no cluster através do seguinte comando:

kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1 -o json | jq -cC '.items[]| [.metadata.name,.status.totalViolations]'

Se existirem violações, pode ver uma lista das mensagens de violação por restrição com o seguinte comando:

kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1 -o json | jq -C '.items[]| select(.status.totalViolations>0)| [.metadata.name,.status.violations[]?]'

Altere a ação de aplicação do pacote de políticas do Cloud Service Mesh

Depois de rever as violações de políticas no seu cluster, pode considerar alterar o modo de aplicação para que o controlador de admissão warn ative ou até mesmo deny bloqueie a aplicação de recursos não conformes ao cluster.

Aviso: a ação de aplicação deny deve ser usada com cuidado, pois pode bloquear potencialmente as alterações necessárias, o que resulta na interrupção das cargas de trabalho críticas ou do cluster. Recomendamos vivamente que apenas as ações de aplicação warn ou dryrun sejam usadas em clusters com cargas de trabalho de produção, quando testar novas restrições ou realizar migrações, como a atualização de plataformas. Para mais informações acerca das ações de aplicação, consulte o artigo Auditoria com restrições.

kubectl

1. Use o kubectl para definir a ação de aplicação das políticas como warn:

   kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1 -o name | xargs -I {} kubectl patch {} --type='json' -p='[{"op":"replace","path":"/spec/enforcementAction","value":"warn"}]'
   

2. Verifique se a ação de aplicação das restrições de políticas foi atualizada:

   kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1
   

kpt

1. Execute a função set-enforcement-action kpt para definir a ação de aplicação das políticas como warn:

   kpt fn eval -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

2. Aplique as restrições de políticas:

   kpt live apply
   

Config Sync

Os operadores que usam o Config Sync para implementar políticas nos respetivos clusters podem usar as seguintes instruções:

1. Altere para o diretório de sincronização do Config Sync:

   cd SYNC_ROOT_DIR
   

2. Execute a função set-enforcement-action kpt para definir a ação de aplicação das políticas como warn:

   kpt fn eval policies/asm-policy-v0.0.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

3. Envie alterações para o repositório do Config Sync:

   git add SYNC_ROOT_DIR/policies/asm-policy-v0.0.1
   git commit -m 'Adding ASM security policy bundle warn enforcement'
   git push
   

4. Verifique o estado da instalação:

   nomos status
   

   O cluster deve apresentar o estado SYNCED com as políticas instaladas.

Teste a aplicação de políticas

Crie um recurso não compatível no cluster com o seguinte comando:

cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: non-compliant-authz-policy
spec:
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["get"]
EOF

O controlador de admissão deve produzir um aviso que liste as violações de políticas que este recurso viola, conforme mostrado no exemplo seguinte:

Warning: [asm-policy-v0.0.1-asm-authz-policy-normalization] in rules-to-operation, methods or notMethods must be uppercase
authorizationpolicy.security.istio.io/non-compliant-authz-policy created

Remova o pacote de políticas do Cloud Service Mesh

Se necessário, o pacote de políticas do Cloud Service Mesh pode ser removido do cluster.

kubectl

• Use o kubectl para remover as políticas:

  kubectl delete constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1
  

kpt

• Remova as políticas:

  kpt live destroy
  

Config Sync

Os operadores que usam o Config Sync para implementar políticas nos respetivos clusters podem usar as seguintes instruções:

1. Envie alterações para o repositório do Config Sync:

   git rm -r SYNC_ROOT_DIR/policies/asm-policy-v0.0.1
   git commit -m 'Removing Cloud Service Mesh  policies'
   git push
   

2. Valide o estado:

   nomos status
   

   O cluster deve apresentar o estado SYNCED com os recursos removidos.