Referência do YAML de políticas

Esta página contém informações de referência para as políticas de autorização binária, conforme especificado no formato YAML. Quando configura uma política através da interface de linhas de comando, edita um ficheiro formatado em YAML que está em conformidade com esta especificação. Para ver exemplos de políticas no formato YAML, consulte o artigo Políticas de exemplo.

Os ficheiros YAML de políticas têm o seguinte formato:

name: projects/<PROJECT_ID>/policy
admissionWhitelistPatterns:
- namePattern: <MATCHING_PATTERN>
- ...
globalPolicyEvaluationMode: <GLOBAL_EVAL_MODE>
defaultAdmissionRule:
  <ADMISSION_RULE>
clusterAdmissionRules:
  <CLUSTER_SPECIFIER>:
    <ADMISSION_RULE>
  ...

Nós

O formato YAML tem os seguintes nós de nível superior:

Descrição Obrigatória
name Nome da política. Sim
admissionWhitelistPatterns Especifica as imagens de contentores que têm sempre autorização para serem implementadas. Não
globalPolicyEvaluationMode Especifica se deve aplicar uma política do sistema que isenta as imagens do sistema pertencentes à Google. Não
defaultAdmissionRule A regra a usar quando não se aplica nenhuma regra específica. Sim
clusterAdmissionRules Especifica regras que se aplicam a clusters específicos. Não

name

O nó name contém o nome da política no seguinte formato:

name: projects/PROJECT_ID/policy

onde PROJECT_ID é o nome do seu Google Cloud projeto onde a sua política está definida.

Por exemplo:

name: projects/example-project/policy

admissionWhitelistPatterns

admissionWhitelistPatterns especifica uma lista de autorizações de imagens de contentores que estão isentos da aplicação de políticas. Especifica o caminho para as imagens no Container Registry e no Artifact Registry, noutro registo ou numa referência local no subnó namePattern:

admissionWhitelistPatterns:
  - namePattern: MATCHING_PATTERN
  - ...

Substitua MATCHING_PATTERN por um caminho para uma única imagem ou um padrão correspondente que contenha um dos símbolos de caráter universal (*, **).

Tenha em atenção que os carateres universais só são válidos no final do padrão. Por exemplo, gcr.io/my-project/nginx* é um padrão válido, mas gcr.io/my-project/n*x não é. O caráter universal * só corresponde a imagens no diretório especificado. Por exemplo, gcr.io/my-project/nginx* corresponde a gcr.io/my-project/nginx:latest, mas não a gcr.io/my-project/nginx-images/nginx. O caráter universal ** corresponde a imagens em subdiretórios. Por exemplo, o caminho gcr.io/my-project/nginx** corresponde a gcr.io/my-project/nginx-1.14.2/image:latest.

O exemplo seguinte adiciona registos que contêm imagens do Google Kubernetes Engine (GKE) usadas com frequência, uma imagem localizada em gcr.io/example-project/helloworld e uma referência local a uma imagem, à lista de imagens isentas da política:

admissionWhitelistPatterns:
  - namePattern: gcr.io/google-containers/*
  - namePattern: k8s.gcr.io/**
  - namePattern: gke.gcr.io/**
  - namePattern: gcr.io/gke-release/asm/*
  - namePattern: gcr.io/stackdriver-agents/*
  - namePattern: gcr.io/example-project/helloworld
  - namePattern: loc-ref

Padrões da lista de autorizações

Para permitir todas as imagens de contentores cuja localização do registo corresponda ao caminho especificado:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/*

Para adicionar uma imagem específica à lista de permitidos:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/helloworld

Para adicionar uma versão atualmente etiquetada à lista de autorizações:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/helloworld:latest
  - namePattern: gcr.io/example-project/helloworld:my-tag
  - namePattern: gcr.io/example-project/helloworld:v1.*

Para adicionar uma versão específica de uma imagem à lista de autorizações através do respetivo resumo:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

Para adicionar imagens à lista de autorizações em subdiretórios de um determinado caminho:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/**

globalPolicyEvaluationMode

O modo de avaliação da política do sistema é uma definição de política que faz com que a autorização binária avalie uma política do sistema antes de avaliar a política que configura. A política de sistema é fornecida pela Google e isenta uma lista de imagens de sistema mantidas pela Google de uma avaliação de políticas adicional. Quando esta definição está ativada, as imagens necessárias pelo GKE não são bloqueadas pela aplicação de políticas. A política de sistema é avaliada antes e além da avaliação da política do utilizador, incluindo admissionWhitelistPatterns.

Para permitir todas as imagens do sistema mantidas pela Google, defina a propriedade globalPolicyEvaluationMode como ENABLE:

globalPolicyEvaluationMode: ENABLE

Para desativar o modo de avaliação de políticas do sistema:

globalPolicyEvaluationMode: DISABLE
admissionWhitelistPatterns

defaultAdmissionRule

defaultAdmissionRule especifica a regra predefinida para a política. A regra predefinida define as restrições que se aplicam a todas as imagens de contentores não isentas, exceto as que têm a sua própria regra específica do cluster. Especifique a regra predefinida através da recolha ADMISSION_RULE:

defaultAdmissionRule:
  ADMISSION_RULE

O exemplo seguinte mostra uma regra predefinida que permite a implementação apenas das imagens de contentores que foram autorizadas pelo atestador especificado. Caso todos os atestadores necessários não tenham autorizado a imagem, a autorização binária bloqueia a implementação e escreve no registo de auditoria.

defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
  - projects/example-project/attestors/secure-build

clusterAdmissionRules

clusterAdmissionRules declarar regras específicas do cluster para a política. As restrições nestas regras aplicam-se apenas ao cluster especificado. Se a autorização binária aplicar uma regra específica do cluster a uma implementação, a regra predefinida não é considerada. Tal como acontece com as regras predefinidas, especifica regras específicas do cluster através da coleção ADMISSION_RULE:

clusterAdmissionRules:
  CLUSTER_SPECIFIER:
    ADMISSION_RULE

em que CLUSTER_SPECIFIER é o ID do recurso do cluster ao qual a regra se aplica no formato location.name (por exemplo, us-east1-a.prod-cluster).

Os exemplos seguintes mostram uma regra específica do cluster que só permite a implementação das imagens de contentores que foram autorizadas pelos atestadores especificados:

clusterAdmissionRules:
  us-east1-a.prod-cluster:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/example-project/attestors/secure-build
    - projects/example-project/attestors/prod-qualified

Coleções de nós

ADMISSION_RULE

ADMISSION_RULE é uma coleção de nós que especificam as restrições para a regra no seguinte formato:

evaluationMode: EVAL_MODE
enforcementMode: ENFORCEMENT_MODE
requireAttestationsBy:
- ATTESTOR
- ...

defaultAdmissionRule e clusterAdmissionRule fazem referência a esta coleção.

evaluationMode

evaluationMode especifica a operação que a autorização binária realiza para avaliar se deve implementar uma imagem de contentor. Os valores possíveis são:

  • ALWAYS_ALLOW: permitir sempre a implementação de imagens avaliadas por esta regra
  • ALWAYS_DENY: negar sempre a implementação de imagens avaliadas por esta regra
  • REQUIRE_ATTESTATION: Exigir que um ou mais atestadores autorizem a publicação antes da implementação

Se o evaluationMode for REQUIRE_ATTESTATION, tem de fornecer uma referência aos atestadores necessários em requireAttestationsBy.

enforcementMode

enforcementMode especifica a ação que a autorização binária realiza se uma imagem de contentor não estiver em conformidade com as restrições definidas na regra. Os valores possíveis são:

  • ENFORCED_BLOCK_AND_AUDIT_LOG: bloqueia a implementação e escreve no registo de auditoria.
  • DRYRUN_AUDIT_LOG_ONLY: permite a implementação de imagens não conformes e escreve detalhes sobre a violação no registo de auditoria.

A maioria das regras de produção usa o modo de aplicação ENFORCED_BLOCK_AND_AUDIT_LOG. O DRYRUN_AUDIT_LOG_ONLY é usado principalmente para testar uma política no seu ambiente antes de entrar em vigor.

requireAttestationsBy

O requireAttestationsBy especifica um ou mais atestadores que têm de autorizar a versão antes de poder implementar uma imagem de contentor. Isto é necessário apenas para as regras de REQUIRE_ATTESTATION. O formato deste nó é:

requireAttestationsBy:
  - projects/PROJECT_ID/attestors/ATTESTOR_NAME
  - ...

onde PROJECT_ID é o nome do projeto onde os seus atestadores estão definidos e ATTESTOR_NAME é o nome de um atestador que tem de assinar a versão.

O exemplo seguinte mostra como especificar atestadores:

requireAttestationsBy:
- projects/example-project/attestors/secure-build
- projects/example-project/attestors/prod-qualified