Multilocação declarativa com namespaces do projeto

Neste tutorial, mostramos como usar o blueprint de namespace do projeto com o Config Controller para criar um namespace dedicado a fim de gerenciar recursos do Google Cloud em um projeto específico. Acompanhe se você é um administrador de infraestrutura e quer permitir que seus locatários gerenciem de maneira declarativa a configuração do projeto.

O Config Controller é um serviço hospedado para provisionar e orquestrar os recursos do Anthos e do Google Cloud. Ele oferece um endpoint de API que pode provisionar, atuar e orquestrar recursos do Google Cloud como parte do Anthos Config Management.

Os blueprints de KRM são uma maneira de empacotar recursos que são comumente usados juntos ao codificar práticas recomendadas que podem ser implantadas em toda a organização.

Namespace do projeto do controlador do Config — Namespace do projeto do controlador de configuração

O blueprint do namespace do projeto é um blueprint do KRM que inclui todos os recursos necessários para provisionar um namespace no controlador de configuração, em que você ou um locatário pode gerenciar os recursos do projeto do Google Cloud. É possível instanciar o blueprint várias vezes para configurar vários namespaces do projeto.

O blueprint do namespace do projeto facilita o gerenciamento de um ou mais namespaces, mas se você quiser ver as etapas manuais usando Google Cloud CLI, confira Configurar o Config Connector para gerenciar recursos nos namespaces.

Objetivos

Configure um namespace de projeto no Config Controller.
Aplique a configuração usando kpt live apply.

Custos

Neste tutorial, usamos o seguinte componente faturável do Google Cloud:

Para ver uma lista completa de recursos incluídos no blueprint do namespace do projeto, consulte a seção Recursos do pacote do blueprint do namespace do projeto.

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais informações, consulte Como fazer a limpeza.

Requisitos

Você precisa ter uma instância do Config Controller.

Saber como configurar o Config Controller.
Você precisa ter um projeto do Google Cloud. Este é o projeto de locatário que o namespace do projeto gerenciará.

Saber como criar e gerenciar projetos.
O faturamento precisa estar ativado no projeto de locatário.

Saiba como confirmar se o faturamento está ativado para o projeto.

Antes de começar

No Console do Cloud, ative o Cloud Shell.

Ativar o Cloud Shell

Na parte inferior do console do Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

Configure o ambiente

No Cloud Shell, execute os seguintes comandos:

Instale kubectl, a principal interface de linha de comando do Kubernetes:
```
gcloud components install kubectl
```
Instale kpt, a principal interface de linha de comando para blueprints do KRM:
```
gcloud components install kpt
```
Observação: este tutorial requer kpt v1+.
Configure kubectl e kpt para se conectar com o Config Controller:
```
gcloud alpha anthos config controller get-credentials INSTANCE_NAME \
    --location COMPUTE_REGION \
    --project ADMIN_PROJECT_ID
```
Substitua:
- INSTANCE_NAME: o nome da sua instância do Controlador de configuração.
- COMPUTE_REGION: a região da instância do Config Controller (por exemplo, us-central1).
- ADMIN_PROJECT_ID: o ID do projeto da instância do Config Controller.
Observação: na prévia, o Config Controller só está disponível na região us-central1.
Ative a API Resource Manager:

A API Resource Manager é usada pelo Config Connector para gerenciar a ativação de outras APIs de serviço.
```
gcloud services enable cloudresourcemanager.googleapis.com \
    --project TENANT_PROJECT_ID
```
Substitua TENANT_PROJECT_ID pelo ID do projeto de locatário.
Instale o CRD ResourceGroup, se ainda não estiver instalado:
```
kpt live install-resource-group
```

Verifique se o Config Connector está configurado e íntegro no namespace config-control:

kubectl get ConfigConnectorContext -n config-control \
    -o "custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HEALTHY:.status.healthy"

Saída esperada:

NAMESPACE        NAME                                                HEALTHY
config-control   configconnectorcontext.core.cnrm.cloud.google.com   true

Conceda permissão ao Config Controller para gerenciar os recursos do Google Cloud no projeto de locatário:

export TENANT_PROJECT_ID=TENANT_PROJECT_ID
export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
    -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
gcloud projects add-iam-policy-binding "${TENANT_PROJECT_ID}" \
    --member "serviceAccount:${SA_EMAIL}" \
    --role "roles/owner" \
    --project "${TENANT_PROJECT_ID}"

Configurar um namespace de projeto

Para criar um namespace de projeto para gerenciar recursos em outro projeto, execute os seguintes comandos.

Busque o blueprint do namespace do projeto com kpt, do diretório de trabalho desejado:
```
kpt pkg get \
    https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project/kcc-namespace@main \
    TENANT_PROJECT_ID
```
Substitua TENANT_PROJECT_ID pelo ID do projeto de locatário.

Nesse blueprint, o ID do projeto também é usado como o nome do namespace do projeto.
Acesse o diretório do pacote:
```
cd ./TENANT_PROJECT_ID/
```
Configure o pacote modificando o arquivo setters.yaml:
```
cat > setters.yaml << EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: setters
  annotations:
    config.kubernetes.io/local-config: "true"
data:
  project-id: TENANT_PROJECT_ID
  management-project-id: ADMIN_PROJECT_ID
  management-namespace: ADMIN_NAMESPACE
  projects-namespace: PROJECTS_NAMESPACE
  networking-namespace: NETWORKING_NAMESPACE
EOF
```
Substitua:
- ADMIN_PROJECT_ID: o ID do projeto que contém o cluster do Config Controller.
  
  O projeto do administrador será usado para inicializar a identidade da carga de trabalho do Config Connector.
- ADMIN_NAMESPACE: o namespace a ser usado para gerenciar os namespaces do projeto (por exemplo, config-control).
  
  O namespace de administrador será usado para inicializar a identidade da carga de trabalho do Config Connector no projeto de administrador.
- PROJECTS_NAMESPACE: o namespace a ser usado para gerenciar as permissões do projeto (por exemplo, config-control).
  
  O namespace do projeto será usado para gerenciar itens como a política do IAM, de modo que os locatários com acesso ao namespace de locatário não possam escalonar as permissões.
  
  Se você usou o blueprint da zona de destino, já tem um namespace projects para gerenciar projetos. Caso contrário, defina-o como config-control.
- NETWORKING_NAMESPACE: o namespace usado para gerenciar VPCs compartilhadas (por exemplo, config-control).
  
  Isso permitirá que você use referências de recursos entre namespaces ao selecionar qual rede ou sub-rede usar.
  
  Se você usou o blueprint da zona de destino, já tem um namespace networking para gerenciar as VPCs compartilhadas. Caso contrário, defina como config-control.

Renderize os valores setter nos recursos com modelo:

kpt fn render

Exemplo de saída:

Package "example-1234":
[RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
[PASS] "gcr.io/kpt-fn/apply-setters:v0.1"
  Results:
    [INFO] set field value to "cnrm-network-viewer-example-1234" in file "kcc-namespace-viewer.yaml" in field "metadata.name"
    [INFO] set field value to "config-control" in file "kcc-namespace-viewer.yaml" in field "metadata.namespace"
    [INFO] set field value to "cnrm-controller-manager-example-1234" in file "kcc-namespace-viewer.yaml" in field "subjects[0].name"
    [INFO] set field value to "cnrm-project-viewer-example-1234" in file "kcc-namespace-viewer.yaml" in field "metadata.name"
    ...(20 line(s) truncated, use '--truncate-output=false' to disable)

Successfully executed 1 function(s) in 1 package(s).

Configurar permissões de locatário

Para permitir que um locatário provisione recursos de projeto do Google Cloud no projeto de locatário, você concede a ele permissão para usar o namespace do projeto de locatário com os comandos a seguir.

Crie um arquivo project-admin.yaml com o seguinte RoleBinding:
```
cat > project-admin.yaml << EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: project-admin
  namespace: TENANT_PROJECT_ID
roleRef:
  kind: ClusterRole
  name: cnrm-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: TENANT_EMAIL
  apiGroup: rbac.authorization.k8s.io
EOF
```
Substitua TENANT_EMAIL pelo e-mail da conta de usuário do locatário do Google Cloud (por exemplo, janedoe@example.com).

O papel cnrm-admin permitirá que o locatário crie recursos do Config Connector no namespace do projeto.

Para detalhes sobre como autorizar um grupo ou uma conta de serviço, consulte Como atribuir papéis usando RoleBindings ou ClusterRoleBindings.

Aplicar mudanças de configuração

As alterações locais nas etapas anteriores não afetam a nuvem até que sejam aplicadas.

Para aplicar as alterações de configuração, execute os comandos a seguir.

Inicialize o diretório de trabalho com o kpt, que cria um recurso para acompanhar as alterações:
```
kpt live init --namespace ADMIN_NAMESPACE
```
Substitua ADMIN_NAMESPACE pelo namespace usado para gerenciar namespaces do projeto (por exemplo, config-control).

Visualize os recursos que serão criados:

kpt live apply --dry-run

Todos os recursos devem indicar "criado (simulação)".

Exemplo de saída:

namespace/example-1234 created (dry-run)
rolebinding.rbac.authorization.k8s.io/cnrm-network-viewer-example-1234 created (dry-run)
rolebinding.rbac.authorization.k8s.io/cnrm-project-viewer-example-1234 created (dry-run)
rolebinding.rbac.authorization.k8s.io/project-admin created (dry-run)
configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com created (dry-run)
iampartialpolicy.iam.cnrm.cloud.google.com/example-1234-sa-workload-identity-binding created (dry-run)
iampartialpolicy.iam.cnrm.cloud.google.com/kcc-example-1234-owners-permissions created (dry-run)
iamserviceaccount.iam.cnrm.cloud.google.com/kcc-example-1234 created (dry-run)
8 resource(s) applied. 8 created, 0 unchanged, 0 configured, 0 failed (dry-run)
0 resource(s) pruned, 0 skipped, 0 failed (dry-run)

Aplique os recursos com kpt:

kpt live apply

Todos os recursos devem indicar "criado".

Exemplo de saída:

namespace/example-1234 created
rolebinding.rbac.authorization.k8s.io/cnrm-network-viewer-example-1234 created
rolebinding.rbac.authorization.k8s.io/cnrm-project-viewer-example-1234 created
rolebinding.rbac.authorization.k8s.io/project-admin created
configconnectorcontext.core.cnrm.cloud.google.com/configconnectorcontext.core.cnrm.cloud.google.com created
iampartialpolicy.iam.cnrm.cloud.google.com/example-1234-sa-workload-identity-binding created
iampartialpolicy.iam.cnrm.cloud.google.com/kcc-example-1234-owners-permissions created
iamserviceaccount.iam.cnrm.cloud.google.com/kcc-example-1234 created
8 resource(s) applied. 8 created, 0 unchanged, 0 configured, 0 failed
0 resource(s) pruned, 0 skipped, 0 failed

Verificar o sucesso

Para verificar se as alterações foram aplicadas e os recursos especificados por eles foram provisionados, execute os comandos a seguir.

Aguarde até que os recursos estejam prontos:

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

Esse comando pesquisará até que todos os recursos tenham o status Current e uma condição Ready ou <None> (para recursos que não são compatíveis com a condição Ready). O Ready ficará verde se Ready=true e vermelho se Ready=false.

Use ctrl-c para interromper, se necessário.

Exemplo de saída:

NAMESPACE   RESOURCE                                  STATUS      CONDITIONS                                AGE     MESSAGE
            Namespace/example-1234                    Current     <None>                                    13s     Resource is current
config-con  IAMPartialPolicy/example-1234-sa-workloa  Current     Ready                                     11s     Resource is Ready
config-con  IAMPartialPolicy/kcc-example-1234-owners  Current     Ready                                     11s     Resource is Ready
config-con  IAMServiceAccount/kcc-example-1234        Current     Ready                                     11s     Resource is Ready
config-con  RoleBinding/cnrm-network-viewer-example-  Current     <None>                                    13s     Resource is current
config-con  RoleBinding/cnrm-project-viewer-example-  Current     <None>                                    12s     Resource is current
example-12  ConfigConnectorContext/configconnectorco  Current     <None>                                    12s     Resource is current
example-12  RoleBinding/project-admin                 Current     <None>                                    12s     Resource is current

Em caso de erro, use a saída de evento padrão para ver mensagens de erro completas:
```
kpt live status
```

Como fazer a limpeza

Se você decidir parar de usar o Config Controller, primeiro limpe todos os recursos criados com o Config Controller e depois exclua o Config Controller.

Exclua os recursos com kpt, a partir do diretório de trabalho:
```
kpt live destroy
```
Aguarde até que todos os recursos sejam excluídos:
```
until [ -z "$(kubectl get -R -f . --ignore-not-found | tee /dev/fd/2)" ]; \
do sleep 1; done
```
Esse comando pesquisará até que todos os recursos tenham o status Deleted.

Use ctrl-c para interromper, se necessário.

A seguir

Procure o catálogo de blueprints do KRM.