Esta página foi traduzida pela API Cloud Translation.

Crie recursos da Google Cloud em conformidade com as políticas

Este tutorial mostra como os administradores da plataforma podem usar políticas do Policy Controller para reger a forma como criar recursos Google Cloud usando o Config Connector.

Esta página destina-se a administradores de TI e operadores que querem garantir que todos os recursos executados na plataforma de nuvem cumprem os requisitos de conformidade organizacionais, fornecendo e mantendo a automatização para auditar ou aplicar, e que gerem o ciclo de vida da infraestrutura tecnológica subjacente. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

As instruções neste tutorial pressupõem que tem conhecimentos básicos do Kubernetes ou do Google Kubernetes Engine (GKE). No tutorial, define uma política que restringe as localizações permitidas para contentores do Cloud Storage.

O Policy Controller verifica, audita e aplica a conformidade dos recursos do cluster do Kubernetes com políticas relacionadas com segurança, regulamentos ou regras empresariais. O Policy Controller é criado a partir do projeto de código aberto OPA Gatekeeper.

O Config Connector cria e gere o ciclo de vida dos Google Cloud recursos, descrevendo-os como recursos personalizados do Kubernetes. Para criar um Google Cloud recurso, cria um recurso do Kubernetes num namespace que o Config Connector gere. O exemplo seguinte mostra como descrever um contentor do Cloud Storage através do Config Connector:

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-bucket
spec:
  location: us-east1

Ao gerir os seus Google Cloud recursos com o Config Connector, pode aplicar políticas do Policy Controller a esses recursos à medida que os cria no seu cluster do Google Kubernetes Engine. Estas políticas permitem-lhe impedir ou denunciar ações que criam ou modificam recursos de formas que violam as suas políticas. Por exemplo, pode aplicar uma política que restrinja as localizações dos contentores do Cloud Storage.

Esta abordagem, baseada no modelo de recursos do Kubernetes (KRM), permite-lhe usar um conjunto consistente de ferramentas e fluxos de trabalho para gerir os recursos do Kubernetes e do Google Cloud . Este tutorial demonstra como pode concluir as seguintes tarefas:

Defina políticas que regem os seus Google Cloud recursos.
Implemente controlos que impeçam os programadores e os administradores de criarem Google Cloud recursos que violem as suas políticas.
Implemente controlos que auditam os seus recursos do Google Cloud existentes em função das suas políticas, mesmo que tenha criado esses recursos fora do Config Connector.
Fornecer feedback rápido aos programadores e administradores à medida que criam e atualizam as definições de recursos.
Valide as Google Cloud definições de recursos em relação às suas políticas antes de tentar aplicar as definições a um cluster do Kubernetes.

Objetivos

Crie um cluster do GKE que inclua o suplemento Config Connector.
Instale o Policy Controller.
Crie uma política para restringir as localizações permitidas dos contentores do Cloud Storage.
Verifique se a política impede a criação de contentores do Cloud Storage em localizações não permitidas.
Avalie a conformidade com as políticas da definição do contentor do Cloud Storage durante o desenvolvimento.
Audite os contentores do Cloud Storage existentes quanto à conformidade com as políticas.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Antes de começar

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
- Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Verify that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
No Cloud Shell, defina o Google Cloud projeto que quer usar para este tutorial:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo Google Cloud ID do projeto do seu projeto. Quando executa este comando, o Cloud Shell cria uma variável de ambiente exportada denominada GOOGLE_CLOUD_PROJECT que contém o ID do seu projeto. Se não usar o Cloud Shell, pode criar a variável de ambiente com este comando:
```
export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value core/project)
```

Ative a API GKE:

gcloud services enable container.googleapis.com

Ative a API Policy Controller:

gcloud services enable anthospolicycontroller.googleapis.com

Crie um diretório para armazenar os ficheiros criados para este tutorial:
```
mkdir -p ~/cnrm-gatekeeper-tutorial
```
Aceda ao diretório que criou:
```
cd ~/cnrm-gatekeeper-tutorial
```

Crie um cluster do GKE

No Cloud Shell, crie um cluster do GKE com o suplemento Config Connector e a federação de identidade da carga de trabalho para o GKE:
```
gcloud container clusters create CLUSTER_NAME \
  --addons ConfigConnector \
  --enable-ip-alias \
  --num-nodes 4 \
  --release-channel regular \
  --scopes cloud-platform \
  --workload-pool $GOOGLE_CLOUD_PROJECT.svc.id.goog \
  --zone ZONE
```
Substitua o seguinte:
- CLUSTER_NAME: o nome do cluster que quer usar para este projeto, por exemplo, cnrm-gatekeeper-tutorial.
- ZONE: Uma zona do Compute Engine perto da sua localização, por exemplo, asia-southeast1-b.
O suplemento Config Connector instala definições de recursos personalizados (CRDs) para Google Cloud recursos no seu cluster do GKE.
Opcional: se usar um cluster privado no seu próprio ambiente, adicione uma regra de firewall que permita que o plano de controlo do cluster do GKE se ligue ao webhook do Policy Controller:
```
gcloud compute firewall-rules create allow-cluster-control-plane-tcp-8443 \
  --allow tcp:8443 \
  --network default \
  --source-ranges CONTROL_PLANE_CIDR \
  --target-tags NODE_TAG
```
Substitua o seguinte:
- CONTROL_PLANE_CIDR: o intervalo de IP do plano de controlo do cluster do GKE, por exemplo, 172.16.0.16/28.
- NODE_TAG: uma etiqueta aplicada a todos os nós no seu cluster do GKE.
Esta regra de firewall opcional é necessária para que o webhook do Policy Controller funcione quando o cluster usa nós privados.

Configure o Config Connector

O Google Cloud projeto onde instala o Config Connector é conhecido como o projeto anfitrião. Os projetos onde usa o Config Connector para gerir recursos são conhecidos como projetos geridos. Neste tutorial, vai usar o Config Connector para criar Google Cloud recursos no mesmo projeto que o seu cluster do GKE, para que o projeto anfitrião e o projeto gerido sejam o mesmo projeto.

No Cloud Shell, crie uma conta de serviço Google para o Config Connector:
```
gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \
  --display-name "Config Connector Gatekeeper tutorial"
```
Substitua SERVICE_ACCOUNT_NAME pelo nome que quer usar para esta conta de serviço, por exemplo, cnrm-gatekeeper-tutorial. O Config Connector usa esta conta de serviço Google para criar recursos no seu projeto gerido.
Conceda a função de administrador de armazenamento à conta de serviço Google:
```
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
  --member "serviceAccount:SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROiam.gserviceaccount.comJECT." \
  --role roles/storage.admin
```
Neste tutorial, usa a função de administrador de armazenamento porque usa o Config Connector para criar contentores do Cloud Storage. No seu próprio ambiente, conceda as funções necessárias para gerir os Google Cloud recursos Google Cloud que quer criar para o Config Connector. Para mais informações sobre as funções predefinidas, consulte a secção Compreender as funções na documentação do IAM.
Crie um espaço de nomes do Kubernetes para os recursos do Config Connector que criar neste tutorial:
```
kubectl create namespace NAMESPACE
```
Substitua NAMESPACE pelo namespace do Kubernetes que quer usar no tutorial, por exemplo, tutorial.
Anote o espaço de nomes para especificar que projeto o Config Connector deve usar para criar Google Cloud recursos (o projeto gerido):
```
kubectl annotate namespace NAMESPACE \
    cnrm.cloud.google.com/project-id=$GOOGLE_CLOUD_PROJECT
```
Crie um recurso ConfigConnectorContext que ative o Config Connector para o espaço de nomes do Kubernetes e o associe à conta de serviço Google que criou:
```
cat << EOF | kubectl apply -f -
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: NAMESPACE
spec:
  googleServiceAccount: SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com
EOF
```
Quando cria o recurso ConfigConnectorContext, o Config Connector cria uma conta de serviço do Kubernetes e um StatefulSet no espaço de nomes cnrm-system para gerir os recursos do Config Connector no seu espaço de nomes.
Aguarde pelo pod do controlador do Config Connector para o seu espaço de nomes:
```
kubectl wait --namespace cnrm-system --for=condition=Ready pod \
  -l cnrm.cloud.google.com/component=cnrm-controller-manager,cnrm.cloud.google.com/scoped-namespace=NAMESPACE
```
Quando o Pod estiver pronto, é apresentada a mensagem do Cloud Shell. Se receber a mensagem error: no matching resources found, aguarde um minuto e tente novamente.
Associe a sua conta de serviço do Kubernetes do Config Connector à sua conta de serviço da Google criando uma associação de políticas de IAM:
```
gcloud iam service-accounts add-iam-policy-binding \
  SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com \
  --member "serviceAccount:$GOOGLE_CLOUD_PROJECT.svc.id.goog[cnrm-system/cnrm-controller-manager-NAMESPACE]" \
  --role roles/iam.workloadIdentityUser
```
Esta associação permite que a conta de serviço do cnrm-controller-manager-NAMESPACE Kubernetes no espaço de nomes cnrm-system atue como a conta de serviço da Google que criou.

Instale o Controlador de políticas

Instale o Policy Controller seguindo as instruções de instalação.

Use um intervalo de auditoria de 60 segundos.

Crie um recurso Google Cloud com o Config Connector

No Cloud Shell, crie um manifesto do Config Connector que represente um contentor do Cloud Storage na região us-central1:

cat << EOF > tutorial-storagebucket-us-central1.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: tutorial-us-central1-$GOOGLE_CLOUD_PROJECT
  namespace: NAMESPACE
spec:
  location: us-central1
  uniformBucketLevelAccess: true
EOF

Para criar o contentor do Cloud Storage, aplique o manifesto:

kubectl apply -f tutorial-storagebucket-us-central1.yaml

Verifique se o Config Connector criou o contentor do Cloud Storage:
```
gcloud storage ls | grep tutorial
```
O resultado é semelhante ao seguinte:
```
gs://tutorial-us-central1-PROJECT_ID/
```
Este resultado inclui PROJECT_ID, que é o seu ID do projeto. Google Cloud

Se não vir este resultado, aguarde um minuto e repita o passo.

Criar uma política

Uma política no Policy Controller consiste num modelo de restrição e numa restrição. O modelo de restrição contém a lógica da política. A restrição especifica onde a política se aplica e os parâmetros de entrada da lógica da política.

No Cloud Shell, crie um modelo de restrição que restrinja as localizações dos contentores do Cloud Storage:

cat << EOF > tutorial-storagebucket-location-template.yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: gcpstoragelocationconstraintv1
spec:
  crd:
    spec:
      names:
        kind: GCPStorageLocationConstraintV1
      validation:
        openAPIV3Schema:
          properties:
            locations:
              type: array
              items:
                type: string
            exemptions:
              type: array
              items:
                type: string
  targets:
  - target: admission.k8s.gatekeeper.sh
    rego: |
      package gcpstoragelocationconstraintv1

      allowedLocation(reviewLocation) {
          locations := input.parameters.locations
          satisfied := [ good | location = locations[_]
                                good = lower(location) == lower(reviewLocation)]
          any(satisfied)
      }

      exempt(reviewName) {
          input.parameters.exemptions[_] == reviewName
      }

      violation[{"msg": msg}] {
          bucketName := input.review.object.metadata.name
          bucketLocation := input.review.object.spec.location
          not allowedLocation(bucketLocation)
          not exempt(bucketName)
          msg := sprintf("Cloud <St>orage bucket %v uses a disal<lo>wed location %v, allowed locations are %v", [bucketName, bucketLocation, input.parameters.locations])
      }

      violation[{"msg": msg}] {
          not input.parameters.locations
          bucketName := input.review.object.metadata.name
          msg := sprintf("No permitted locations provided in c<on>straint for Cloud Storage bucket %v", [bucketName])
      }
EOF

Aplique o modelo para criar o contentor do Cloud Storage:

kubectl apply -f tutorial-storagebucket-location-template.yaml

Crie uma restrição que só permita contentores nas regiões de Singapura e Jacarta (asia-southeast1 e asia-southeast2). A restrição aplica-se ao espaço de nomes que criou anteriormente. Isenta o contentor do Cloud Storage predefinido para o Cloud Build.

cat << EOF > tutorial-storagebucket-location-constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GCPStorageLocationConstraintV1
metadata:
  name: singapore-and-jakarta-only
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - storage.cnrm.cloud.google.com
      kinds:
      - StorageBucket
    namespaces:
    - NAMESPACE
  parameters:
    locations:
    - asia-southeast1
    - asia-southeast2
    exemptions:
    - ${GOOGLE_CLOUD_PROJECT}_cloudbuild
EOF

Para limitar as zonas em que os contentores podem existir, aplique a restrição:
```
kubectl apply -f tutorial-storagebucket-location-constraint.yaml
```

Valide a política

Crie um manifesto que represente um contentor do Cloud Storage numa localização não permitida (us-west1):

cat << EOF > tutorial-storagebucket-us-west1.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: tutorial-us-west1-$GOOGLE_CLOUD_PROJECT
  namespace: NAMESPACE
spec:
  location: us-west1
  uniformBucketLevelAccess: true
EOF

Para criar o contentor do Cloud Storage, aplique o manifesto:

kubectl apply -f tutorial-storagebucket-us-west1.yaml

O resultado é semelhante ao seguinte:

Error from server ([singapore-and-jakarta-only] Cloud Storage bucket
<tutorial-us-west1-PROJECT_ID> uses a disallowed location
<us-west1>, allowed locations are ["asia-southeast1",
"asia-southeast2"]): error when creating
"tutorial-storagebucket-us-west1.yaml": admission webhook
"validation.gatekeeper.sh" denied the request: [singapore-and-jakarta-only]
Cloud Storage bucket <tutorial-us-west1-PROJECT_ID> uses a
disallowed location <us-west1>, allowed locations are
["asia-southeast1", "asia-southeast2"]

Opcional: pode ver um registo da decisão de recusar o pedido nos registos de auditoria do Google Cloud. Consultar os registos de atividade de administrador do seu projeto:

gcloud logging read --limit=1 \
    "logName=\"projects/$GOOGLE_CLOUD_PROJECT/logs/cloudaudit.googleapis.com%2Factivity\""'
    resource.type="k8s_cluster"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.location="ZONE"
    protoPayload.authenticationInfo.principalEmail!~"system:serviceaccount:cnrm-system:.*"
    protoPayload.methodName:"com.google.cloud.cnrm."
    protoPayload.status.code=7'

O resultado é semelhante ao seguinte:

insertId: 3c6940bb-de14-4d18-ac4d-9a6becc70828
labels:
  authorization.k8s.io/decision: allow
  authorization.k8s.io/reason: ''
  mutation.webhook.admission.k8s.io/round_0_index_0: '{"configuration":"mutating-webhook.cnrm.cloud.google.com","webhook":"container-annotation-handler.cnrm.cloud.google.com","mutated":true}'
  mutation.webhook.admission.k8s.io/round_0_index_1: '{"configuration":"mutating-webhook.cnrm.cloud.google.com","webhook":"management-conflict-annotation-defaulter.cnrm.cloud.google.com","mutated":true}'
logName: projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
operation:
  first: true
  id: 3c6940bb-de14-4d18-ac4d-9a6becc70828
  last: true
  producer: k8s.io
protoPayload:
  '@type'-: type.googleapis.com/google.cloud.audit.AuditLog
  authenticationInfo:
    principalEmail: user@example.com
  authorizationInfo:
   permission: com.google.cloud.cnrm.storage.v1beta1.storagebuckets.create
    resource: storage.cnrm.cloud.google.com/v1beta1/namespaces/NAMESPACE/storagebuckets/tutorial-us-west1-PROJECT_ID
  methodName: com.google.cloud.cnrm.storage.v1beta1.storagebuckets.create
  requestMetadata:
    callerIp: 203.0.113.1
    callerSuppliedUserAgent: kubectl/v1.21.1 (linux/amd64) kubernetes/5e58841
  resourceName: storage.cnrm.cloud.google.com/v1beta1/namespaces/NAMESPACE/storagebuckets/tutorial-us-west1-PROJECT_ID
  serviceName: k8s.io
  status:
    code: 7
    message: Forbidden
receiveTimestamp: '2021-05-21T06:56:24.940264678Z'
resource:
  labels:
    cluster_name: CLUSTER_NAME
    location: CLUSTER_ZONE
    project_id: PROJECT_ID
  type: k8s_cluster
timestamp: '2021-05-21T06:56:09.060635Z'

O campo methodName mostra a operação tentada, o campo resourceName mostra o nome completo do recurso do Config Connector e a secção status mostra que o pedido não foi bem-sucedido, com o código de erro 7 e a mensagem Forbidden.

Crie um manifesto que represente um contentor do Cloud Storage numa localização permitida (asia-southeast1):

cat << EOF > tutorial-storagebucket-asia-southeast1.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: tutorial-asia-southeast1-$GOOGLE_CLOUD_PROJECT
  namespace: NAMESPACE
spec:
  location: asia-southeast1
  uniformBucketLevelAccess: true
EOF

Para criar o contentor do Cloud Storage, aplique o manifesto:
```
kubectl apply -f tutorial-storagebucket-asia-southeast1.yaml
```
O resultado é semelhante ao seguinte:
```
storagebucket.storage.cnrm.cloud.google.com/tutorial-asia-southeast1-PROJECT_ID created
```
Este resultado inclui PROJECT_ID, que é o seu ID do projeto. Google Cloud
Verifique se o Config Connector criou o contentor do Cloud Storage:
```
gcloud storage ls | grep tutorial
```
O resultado é semelhante ao seguinte:
```
gs://tutorial-asia-southeast1-PROJECT_ID/
gs://tutorial-us-central1-PROJECT_ID/
```
Se não vir este resultado, aguarde um minuto e repita este passo.

Restrições de auditoria

O controlador de auditoria no controlador de políticas avalia periodicamente os recursos em função das respetivas restrições. O controlador deteta violações de políticas para recursos criados antes da restrição e para recursos criados fora do Config Connector.

No Cloud Shell, veja as violações de todas as restrições que usam o modelo de restrição GCPStorageLocationConstraintV1:
```
kubectl get gcpstoragelocationconstraintv1 -o json \
  | jq '.items[].status.violations'
```
O resultado é semelhante ao seguinte:
```
[
  {
    "enforcementAction": "deny",
    "kind": "StorageBucket",
    "message": "Cloud Storage bucket <tutorial-us-central1-PROJECT_ID>
    uses a disallowed location <us-central1>, allowed locations are
    \"asia-southeast1\", \"asia-southeast2\"",
    "name": "tutorial-us-central1-PROJECT_ID",
    "namespace": "NAMESPACE"
  }
]
```
Vê o contentor do Cloud Storage que criou us-central1 antes de criar a restrição.

Nota: o atributo status.violations predefinido mostra até 20 violações por restrição. Se o controlador de auditoria encontrar mais de 20 violações de restrições, as restantes não são apresentadas. Se se deparar com esta limitação no seu próprio ambiente, crie várias restrições. Restrinja cada restrição a um namespace diferente.

Valide os recursos durante o desenvolvimento

Durante o desenvolvimento e as compilações de integração contínua, é útil validar os recursos em relação às restrições antes de aplicar esses recursos ao cluster do GKE. A validação fornece feedback rápido e permite-lhe descobrir problemas com recursos e restrições antecipadamente. Estes passos mostram como validar recursos com o kpt. A ferramenta de linha de comandos kpt permite-lhe gerir e aplicar manifestos de recursos do Kubernetes.

No Cloud Shell, execute a gatekeeper função KRM com o kpt:

kpt fn eval . --image=gcr.io/kpt-fn/gatekeeper:v0.2 --truncate-output=false

Uma função KRM é um programa que pode alterar ou validar recursos do Kubernetes armazenados no sistema de ficheiros local como ficheiros YAML. A função KRM valida os recursos do bucket do Google Cloud Storage do Config Connector em relação à política do Gatekeeper.gatekeeper A função gatekeeper KRM é embalada como uma imagem de contentor disponível no Artifact Registry.

A função comunica que os ficheiros de manifesto para contentores do Cloud Storage nas regiões us-central1 e us-west1 violam a restrição.

O resultado é semelhante ao seguinte:

[RUNNING] "gcr.io/kpt-fn/gatekeeper:v0.2"
[FAIL] "gcr.io/kpt-fn/gatekeeper:v0.2"
  Results:
    [ERROR] Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-central1-GOOGLE_CLOUD_PROJECT" in file "tutorial-storagebucket-us-central1.yaml"
    [ERROR] Cloud Storage bucket <tutorial-us-west1-PROJECT_ID> uses a disallowed location <us-west1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-west1-GOOGLE_CLOUD_PROJECT" in file "tutorial-storagebucket-us-west1.yaml"
  Stderr:
    "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-central1-PROJECT_ID : Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
    "violatedConstraint: singapore-and-jakarta-only"
    ""
    "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-west1-PROJECT_IDT : Cloud Storage bucket <tutorial-us-west1-PROJECT_IDgt; uses a disallowed location <us-west1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
    "violatedConstraint: singapore-and-jakarta-only"
    ""
  Exit code: 1

Valide os recursos criados fora do Config Connector

Pode validar Google Cloud recursos criados fora do Config Connector exportando os recursos. Depois de exportar os recursos, use uma das seguintes opções para avaliar as políticas do Policy Controller em relação aos recursos exportados:

Valide os recursos através da função gatekeeper KRM.
Importe os recursos para o Config Connector.

Para exportar os recursos, usa o Cloud Asset Inventory.

No Cloud Shell, ative a API Cloud Asset:

gcloud services enable cloudasset.googleapis.com

Elimine os ficheiros de manifesto de recursos do Kubernetes para os contentores do Cloud Storage em us-central1 e us-west1:
```
rm tutorial-storagebucket-us-*.yaml
```

Exporte todos os recursos do Cloud Storage no seu projeto atual e armazene o resultado num ficheiro denominado export.yaml:

gcloud beta resource-config bulk-export \
  --project $GOOGLE_CLOUD_PROJECT \
  --resource-format krm \
  --resource-types StorageBucket > export.yaml

O resultado é semelhante ao seguinte:

Exporting resource configurations to stdout...

Export complete.

Crie um pipeline kpt encadeando funções KRM. Este pipeline valida os recursos no diretório atual em relação à política de localização do contentor do Cloud Storage:

kpt fn source . \
  | kpt fn eval - --image=gcr.io/kpt-fn/set-namespace:v0.1 -- namespace=NAMESPACE \
  | kpt fn eval - --image=gcr.io/kpt-fn/gatekeeper:v0.2 --truncate-output=false

Os recursos exportados não têm um valor para o atributo de metadados namespace. Este pipeline usa uma função KRM denominada set-namespace para definir o valor namespace de todos os recursos.

O resultado é semelhante ao seguinte e mostra violações dos recursos que exportou:

[RUNNING] "gcr.io/kpt-fn/set-namespace:v0.1"
[PASS] "gcr.io/kpt-fn/set-namespace:v0.1"
[RUNNING] "gcr.io/kpt-fn/gatekeeper:v0.2"
[FAIL] "gcr.io/kpt-fn/gatekeeper:v0.2"
  Results:
    [ERROR] Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-central1-GOOGLE_CLOUD_PROJECT" in file "export.yaml"
  Stderr:
    "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-central1-PROJECT_ID : Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
    "violatedConstraint: singapore-and-jakarta-only"
    ""
  Exit code: 1

Se o seu Google Cloud projeto contiver contentores do Cloud Storage que criou antes de trabalhar neste tutorial e a respetiva localização violar a restrição, os contentores criados anteriormente aparecem no resultado.

Parabéns, configurou com êxito uma política que rege a localização permitida dos contentores do Cloud Storage. O tutorial está concluído. Agora, pode continuar a adicionar as suas próprias políticas para outros Google Cloud recursos.

Resolução de problemas

Se o Config Connector não criar os Google Cloud recursos esperados, use o seguinte comando no Cloud Shell para ver os registos do gestor do controlador do Config Connector:

kubectl logs --namespace cnrm-system --container manager \
  --selector cnrm.cloud.google.com/component=cnrm-controller-manager,cnrm.cloud.google.com/scoped-namespace=NAMESPACE

Se o Policy Controller não aplicar as políticas corretamente, use o seguinte comando para ver os registos do gestor do controlador:

kubectl logs deployment/gatekeeper-controller-manager \
  --namespace gatekeeper-system

Se o Policy Controller não comunicar violações no campo status dos objetos de restrição, veja os registos do controlador de auditoria com este comando:

kubectl logs deployment/gatekeeper-audit --namespace gatekeeper-system

Se tiver outros problemas com este tutorial, recomendamos que reveja estes documentos:

Limpar

Para evitar incorrer em custos na sua conta do Google Cloud pelos recursos usados neste tutorial, elimine o projeto que contém os recursos ou mantenha o projeto e elimine os recursos individuais.

Elimine o projeto

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
If the project that you plan to delete is attached to an organization, expand the Organization list in the Name column.
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Elimine os recursos

Se quiser manter o Google Cloud projeto que usou neste tutorial, elimine os recursos individuais.

No Cloud Shell, elimine a restrição de localização do contentor do Cloud Storage:
```
kubectl delete -f tutorial-storagebucket-location-constraint.yaml
```
Adicione a anotação cnrm.cloud.google.com/force-destroy com um valor de string de true a todos os recursos storagebucket no espaço de nomes gerido pelo Config Connector:
```
kubectl annotate storagebucket --all --namespace NAMESPACE \
  cnrm.cloud.google.com/force-destroy=true
```
Esta anotação é uma diretiva que permite ao Config Connector eliminar um contentor do Cloud Storage quando elimina o recurso storagebucket correspondente no cluster do GKE, mesmo que o contentor contenha objetos.
Elimine os recursos do Config Connector que representam os contentores do Cloud Storage:
```
kubectl delete --namespace NAMESPACE storagebucket --all
```

Elimine o cluster do GKE:

gcloud container clusters delete CLUSTER_NAME \
  --zone ZONE --async --quiet

Elimine a associação da política de Workload Identity no IAM:

gcloud iam service-accounts remove-iam-policy-binding \
  SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com \
  --member "serviceAccount:$GOOGLE_CLOUD_PROJECT.svc.id.goog[cnrm-system/cnrm-controller-manager-NAMESPACE]" \
  --role roles/iam.workloadIdentityUser

Elimine a associação da função de administrador do Cloud Storage para a conta de serviço Google:

gcloud projects remove-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
  --member "serviceAccount:SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROiam.gserviceaccount.comJECT." \
  --role roles/storage.admin

Elimine a conta de serviço Google que criou para o Config Connector:

gcloud iam service-accounts delete --quiet \
  SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com

O que se segue?

Descubra como executar a validação do Policy Controller como parte de um pipeline de integração contínua no Cloud Build.

Crie recursos da Google Cloud em conformidade com as políticas Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Objetivos

Custos

Antes de começar

Crie um cluster do GKE

Configure o Config Connector

Instale o Controlador de políticas

Crie um recurso Google Cloud com o Config Connector

Criar uma política

Valide a política

Restrições de auditoria

Valide os recursos durante o desenvolvimento

Valide os recursos criados fora do Config Connector

Resolução de problemas

Limpar

Elimine o projeto

Elimine os recursos

O que se segue?

Crie recursos da Google Cloud em conformidade com as políticas