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:
Nó | 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 regraALWAYS_DENY
: negar sempre a implementação de imagens avaliadas por esta regraREQUIRE_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