Referência de política YAML

Esta página contém informações de referência para políticas de autorização binária, conforme especificado no formato YAML. Ao configurar uma política usando a interface de linha de comando, você edita um arquivo no formato YAML que está em conformidade com essa especificação. Para exemplos de políticas no formato YAML, consulte Políticas de exemplo.

Os arquivos YAML da política 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ório
name Nome da política. Sim
admissionWhitelistPatterns Especifica imagens de contêiner que sempre podem ser implantadas. Não
globalPolicyEvaluationMode Especifica se é necessário aplicar uma política global que isenta as imagens do sistema do Google. Não
defaultAdmissionRule Especifica as regras que se aplicam a todos os clusters em que não há uma regra específica do cluster. 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

em que PROJECT_ID é o nome do projeto do Google Cloud Platform (GCP) em que a política é definida.

Exemplo:

name: projects/example-project/policy

admissionWhitelistPatterns

admissionWhitelistPatterns especifica uma lista de permissões de imagens de contêiner isentas da aplicação da política. Você especifica o caminho para as imagens no Container Registry ou em outro registro no subnó namePattern:

admissionWhitelistPatterns:
  - namePattern: MATCHING_PATTERN
  - ...

em que MATCHING_PATTERN é o caminho para uma única imagem por correspondência exata ou para qualquer imagem que corresponda a um padrão usando o símbolo de caractere curinga (*). Observe que os caracteres curinga podem estar presentes apenas no final, não em qualquer outro lugar no padrão, ou seja, gcr.io/n*x não é permitido, mas gcr.io/nginx* é permitido. Os caracteres curinga também não correspondem a /, ou seja, gcr.io/nginx* corresponde a gcr.io/nginx@latest, mas não corresponde a gcr.io/nginx/image.

O exemplo a seguir adiciona registros que contêm imagens normalmente usadas do Google Kubernetes Engine (GKE), bem como uma imagem localizada em gcr.io/example-project/helloworld, à lista de imagens isentas da política:

admissionWhitelistPatterns:
  - namePattern: gcr.io/google_containers/*
  - namePattern: gcr.io/google-containers/*
  - namePattern: k8s.gcr.io/*
  - namePattern: gke.gcr.io/*
  - namePattern: gcr.io/stackdriver-agents/*
  - namePattern: gcr.io/example-project/helloworld

Padrões da lista de permissões

Para colocar todas as imagens de contêiner com local de registro que corresponda ao caminho especificado na lista de permissões:

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

Para colocar uma imagem específica na lista de permissões:

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

Para colocar uma versão marcada na lista de permissõ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 autorizar uma versão específica de uma imagem pelo resumo:

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

globalPolicyEvaluationMode

O modo de avaliação de política global é uma configuraçã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 você configura como usuário. A política do sistema é fornecida pelo Google e isenta uma lista de imagens de sistema mantidas pelo Google de avaliação adicional de política. Quando essa configuração está ativada, as imagens exigidas pelo GKE não são bloqueadas pela aplicação da política. A política global é avaliada antes e além da avaliação da política do usuário, incluindo admissionWhitelistPatterns.

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

globalPolicyEvaluationMode: ENABLE

Para desativar o modo de avaliação de política global:

globalPolicyEvaluationMode: DISABLE

defaultAdmissionRule

defaultAdmissionRule especifica a regra padrão da política. A regra padrão define as restrições que se aplicam a todas as imagens de contêiner não isentas, exceto aquelas que têm a própria regra específica do cluster. Você especifica a regra padrão usando a coleção ADMISSION_RULE:

defaultAdmissionRule:
  ADMISSION_RULE

O exemplo a seguir mostra uma regra padrão que permite a implantação apenas dessas imagens de contêiner que foram autorizadas pelo attestor especificado. Caso todos os atestadores necessários não tenham autorizado a imagem, a autorização binária bloqueia a implantação e grava no registro de auditoria.

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

clusterAdmissionRules

clusterAdmissionRules declare regras específicas do cluster para a política. As restrições nessas regras se aplicam apenas ao cluster especificado. Se a autorização binária aplicar uma regra específica do cluster a uma implantação, a regra padrão não será considerada. Assim como nas regras padrão, você especifica regras específicas do cluster usando a coleção ADMISSION_RULE:

clusterAdmissionRules:
  CLUSTER_SPECIFIER:
    ADMISSION_RULE

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

Os exemplos a seguir mostram uma regra específica do cluster que só permite a implantação dessas imagens de contêiner 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 da regra no seguinte formato:

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

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

evaluationMode

evaluationMode especifica a operação que a autorização binária executa para avaliar se implantar uma imagem de contêiner. Os valores possíveis são:

  • ALWAYS_ALLOW: sempre permitir a implantação de imagens avaliadas por esta regra
  • ALWAYS_DENY: sempre negar a implantação de imagens avaliadas por essa regra
  • REQUIRE_ATTESTATION: exigir um ou mais atestadores para autorizar a versão antes da implantação

Se evaluationMode for REQUIRE_ATTESTATION, forneça 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 contêiner 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 implantação e grava no registro de auditoria.
  • DRYRUN_AUDIT_LOG_ONLY: permite a implantação de imagens não compatíveis e grava detalhes sobre a violação no registro 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 que ela entre em vigor.

requireAttestationsBy

requireAttestationsBy especifica um ou mais atestadores que precisam autorizar a versão antes que uma imagem de contêiner possa ser implantada. Isso é necessário apenas para regras REQUIRE_ATTESTATION. O formato desse nó é:

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

em que PROJECT_ID é o nome do projeto em que os atestadores são definidos e ATTESTOR_NAME é o nome de um atestador que é necessário para assinar a versão.

O exemplo a seguir mostra como especificar atestadores:

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