Multilocação entre projetos para o Knative serving

Este guia orienta você na configuração do Knative serving para permitir que um ou mais Google Cloud projetos executem e gerenciem as cargas de trabalho em execução em um cluster do GKE em um Google Cloud projeto diferente.

Um modelo operacional comum com o Knative serving é para que uma equipe de desenvolvedores de aplicativos use o Google Cloud projeto do Google Cloud para implantar e gerenciar serviços executados em diferentes clusters do GKE em projetos do Google Cloud de outras equipes' Google Cloud projetos. Esse recurso, chamado multilocação, permite que você, como operador da plataforma, adapte o acesso das suas equipes de desenvolvimento somente aos serviços em execução nos diversos ambientes da sua organização (por exemplo, produção e preparação).

O Knative serving é compatível especificamente com a multilocação empresarial. Esse tipo de multilocação ativa um cluster Google Cloud project para permitir o acesso a recursos específicos do cluster do GKE. O Google Cloud projeto que é concedido acesso ao cluster Google Cloud projeto é o projeto de locatário Google Cloud . Os locatários do cluster Google Cloud projeto podem usar o Knative serving para acessar, operar e ser proprietários desses serviços e recursos a que eles têm acesso.

Conceitualmente, há quatro etapas para configurar a multilocação empresarial com o Knative serving:

  1. Configure o acesso do locatário aoprojeto de cluster usando um Grupo do Google e o Identity and Access Management acesso. Google Cloud
  2. Mapeie cadaprojeto de locatário para oprojeto de cluster. Google Cloud Google Cloud
  3. Encaminhe os dados de registro doprojeto de cluster para osprojetos de locatário usando coletores e buckets de registro. Google Cloud Google Cloud
  4. Defina permissões de cluster para locatários usando o controle de acesso baseado em papéis.

Antes de começar

O operador da plataforma responsável pela configuração da multilocação precisa entender e atender aos requisitos a seguir:

Defina as variáveis de ambiente locais

Para simplificar os comandos usados neste processo, defina variáveis de ambiente locais para oprojeto de cluster Google Cloud e oprojeto de locatário Google Cloud :

  1. Substitua YOUR_CLUSTER_PROJECT_ID pelo ID doprojeto de cluster e execute o comando a seguir: Google Cloud 

    export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_ID

  2. Substitua YOUR_TENANT_PROJECT_ID pelo ID doprojeto de locatário e execute o comando a seguir: Google Cloud 

    export TENANT_PROJECT_ID=$YOUR_TENANT_PROJECT_ID

  3. Verifique as variáveis de ambiente locais executando os comandos a seguir:

    echo "cluster Google Cloud project is:" $CLUSTER_PROJECT_ID
echo "tenant Google Cloud project is:" $TENANT_PROJECT_ID

O ID do projeto de cluster e o ID do projeto de locatário agora são usados em todos os comandos a seguir em que $CLUSTER_PROJECT_ID e $TENANT_PROJECT_ID são especificados. Google Cloud Google Cloud

Verificação das permissões do IAM

Execute os comandos testIamPermissions a seguir para confirmar que você tem as permissões necessárias do IAM para acessar os recursos noprojeto de cluster e nosprojetos de locatário. Google Cloud Google Cloud

Execute o comando a seguir para validar suas permissões no cluster Google Cloud projeto:

curl -X POST \
  -H "Authorization: Bearer "$(gcloud auth application-default print-access-token) \
  --header "Content-Type: application/json" \
  --data '{"permissions":["logging.sinks.create", "logging.sinks.get", "resourcemanager.projects.setIamPolicy"]}' \
  https://cloudresourcemanager.googleapis.com/v1/projects/$CLUSTER_PROJECT_ID:testIamPermissions

Resultados esperados para o cluster Google Cloud projeto:

{
  "permissions": [
    "logging.sinks.create",
    "logging.sinks.get",
    "resourcemanager.projects.setIamPolicy"
  ]
}

Execute o comando a seguir para validar suas permissões em cadalocatário Google Cloud projeto:

curl -X POST \
  -H "Authorization: Bearer "$(gcloud auth application-default print-access-token) \
  --header "Content-Type: application/json" \
  --data '{"permissions":["logging.buckets.create", "logging.buckets.get", "resourcemanager.projects.setIamPolicy", "resourcesettings.settingvalues.create", "serviceusage.services.enable"]}' \
  https://cloudresourcemanager.googleapis.com/v1/projects/$TENANT_PROJECT_ID:testIamPermissions

Resultados esperados para cada locatário Google Cloud projeto:

{
  "permissions": [
    "logging.buckets.create",
    "logging.buckets.get",
    "resourcemanager.projects.setIamPolicy",
    "resourcesettings.settingvalues.create",
    "serviceusage.services.enable",
  ]
}

Usar um Grupo do Google e o Identity and Access Management para configurar o acesso do locatário

Usar um Grupo do Google para permitir que os locatários acessem o cluster do GKE. Com as permissões do IAM, os locatários podem acessar as credenciais, mas não podem fazer nada no cluster até que o controle de acesso baseado em papéis do Kubernetes seja configurado em uma etapa posterior.

Você precisa criar um Grupo do Google que contenha todos os usuários doprojeto de locatário Google Cloud . Para mais informações sobre como usar um grupo de segurança, consulte Usar Grupos do Google para o GKE.

Crie a seguinte variável de ambiente local para seu Grupo do Google:

export SECURITY_GROUP=gke-security-groups@company.com

Leitor de cluster do Kubernetes

Execute os comandos a seguir para permitir que os locatários consigam credenciais no cluster. Isso não permite que eles leiam ou manipulem recursos no cluster do GKE.

Referência do IAM

gcloud projects add-iam-policy-binding $CLUSTER_PROJECT_ID \
   --member=group:$SECURITY_GROUP \
   --role='roles/container.clusterViewer' \
   --condition=None

Para restringir o acesso a um cluster específico, use uma condição do IAM.

gcloud projects add-iam-policy-binding $CLUSTER_PROJECT_ID \
   --member=group:$SECURITY_GROUP \
   --role='roles/container.clusterViewer' \
   --condition="expression=resource.name == 'cluster-name',title=Restrict cluster access"

Leitor do Monitoring

Execute o comando a seguir para permitir que os locatários leiam as métricas de monitoramento.

Referência dos papéis do Monitoring

gcloud projects add-iam-policy-binding $CLUSTER_PROJECT_ID \
   --member=group:$SECURITY_GROUP \
   --role='roles/monitoring.viewer' \
   --condition=None

Mapear cadaprojeto de locatário para oprojeto de cluster Google Cloud Google Cloud

Use valores de configuração de recursos para mapearprojetos de locatário para umprojeto de cluster. Google Cloud Google Cloud

A configuração de recursos pode ser definida para cadaprojeto de locatário ou pode ser definida em qualquer nível da hierarquia de pastas. Google Cloud É mais fácil definir isso no nível da pasta do locatário individual, mas é mais flexível definir isso no nível do projeto de cada locatário. Após a configuração, sempre que os locatários navegarem UI do Knative serving, eles também vão encontrar os serviços no projeto de cluster Google Cloud . Isso não altera as permissões do IAM noprojeto de cluster Google Cloud ou nos clusters do GKE. É apenas um mapeamento de um projeto de locatário (ou pasta) para um projeto de cluster Google Cloud .

  1. Ative a API resourcesettings no projeto de locatário Google Cloud .

    gcloud services enable resourcesettings.googleapis.com \
  --project=$TENANT_PROJECT_ID

  2. Execute o seguinte comando para adicionar os privilégios de administrador da organização (roles/resourcesettings.admin) ao seu ID de usuário:

    gcloud organizations add-iam-policy-binding YOUR_ORGANIZATION_ID \
  --member=YOUR_ADMIN_MEMBER_ID \
  --role='roles/resourcesettings.admin'

    Substitua YOUR_ORGANIZATION_ID pelo ID da organização e YOUR_ADMIN_MEMBER_ID pelo ID do usuário, por exemplo, user:my-email@my-domain.com.

  3. Escolha um dos métodos a seguir para definir o mapeamento.

    É possível definir o valor da configuração do recurso em umapasta pai Google Cloud , se todos osprojetos filhos e aspastas usarem esse mesmo valor. Google Cloud Google Cloud

Projetos de locatário

Defina o valor da configuração de recursos para cadalocatário Google Cloud projeto:

  1. Consiga o name doprojeto de locatário e defina-o como uma variável de ambiente local: Google Cloud 
    export TENANT_PROJECT_NUMBER=$(gcloud projects describe $TENANT_PROJECT_ID --format="value(projectNumber)")
  2. Crie um arquivo de valor de configuração de recursos para definir o mapeamento do locatário Google Cloud projeto para o cluster Google Cloud projeto. Vários IDs doprojeto de cluster podem ser definidos nesse arquivo e adicionados a um únicoprojeto de locatário. Google Cloud Google Cloud 
    cat > value-file.json << EOF
{
"name": "projects/$TENANT_PROJECT_NUMBER/settings/cloudrun-multiTenancy/value",
"value": {
  "stringSetValue": {
    "values": [ "projects/$CLUSTER_PROJECT_ID" ]
  }
}
}
EOF
  3. Implante as configurações de recursos no locatário Google Cloud projeto: 
    gcloud resource-settings set-value cloudrun-multiTenancy --value-file value-file.json --project $TENANT_PROJECT_ID

Pastas de locatário

Defina o valor da configuração de recursos em uma pasta de locatário pai para definir esse valor para todas as pastas eprojetos filhos de locatário: Google Cloud

  1. Consiga o number da pasta de locatário e defina-o como uma variável de ambiente local: 
    export TENANT_FOLDER_NUMBER=$TENANT_FOLDER_NUMBER
  2. Crie um arquivo de valor de configuração de recursos para definir o mapeamento da pasta de locatário para oprojeto de Google Cloud cluster. Vários IDs doprojeto de cluster podem ser definidos nesse arquivo e adicionados a uma única pasta de locatário. Google Cloud 
    cat > value-file.json << EOF
{
"name": "folders/$TENANT_FOLDER_NUMBER/settings/cloudrun-multiTenancy/value",
"value": {
  "stringSetValue": {
    "values": [ "projects/$CLUSTER_PROJECT_ID" ]
  }
}
}
EOF
  3. Implante as configurações de recursos na pasta de locatário: 
    gcloud resource-settings set-value cloudrun-multiTenancy --value-file value-file.json --folder $TENANT_FOLDER_NUMBER

Como configurar coletores e buckets de registros para rotear dados de registro

Para cada locatário, você cria um bucket de registros, um coletor e as permissões para rotear os dados de registro do cluster Google Cloud projeto para o projeto de locatário Google Cloud . Nas etapas a seguir, todos os registros de o namespace no cluster Google Cloud projeto são encaminhados para o bucket. Consulte o conjunto abaixo para ver detalhes sobre como limitar quais registros são compartilhados.

Crie as seguintes variáveis de ambiente locais:

  • Especifique o namespace do cluster do GKE que os locatários acessam.
  • O nome do coletor. Para simplificar essa etapa, o nome é uma combinação do projeto de cluster com as variáveis de ambiente locais doprojeto de locatário criadas anteriormente . Google Cloud Google Cloud É possível modificar esse valor.
export NAMESPACE=$NAMESPACE
export SINK_NAME=$CLUSTER_PROJECT_ID-$TENANT_PROJECT_ID

Execute o comando a seguir para criar o bucket de registros no projeto de locatário. Observe que o nome do bucket de registros precisa ser o ID doprojeto de cluster e não pode ser alterado ou modificado. Google Cloud 

gcloud logging buckets \
   create $CLUSTER_PROJECT_ID \
   --location=global \
   --project=$TENANT_PROJECT_ID

Execute o comando a seguir para criar o coletor do namespace especificado no cluster Google Cloud projeto para o bucket doprojeto de locatário. Google Cloud É possível restringir o escopo de registros, por exemplo, para compartilhar apenas clusters individuais do GKE ou recursos específicos do Knative serving, definindo log-filter valores adicionais.

gcloud logging sinks \
   create $SINK_NAME \
   logging.googleapis.com/projects/$TENANT_PROJECT_ID/locations/global/buckets/$CLUSTER_PROJECT_ID \
   --log-filter=resource.labels.namespace_name=$NAMESPACE \
   --project $CLUSTER_PROJECT_ID

Execute os comandos a seguir para adicionar a permissão da conta de serviço do coletor de registros ao bucket criado.

export SINK_SERVICE_ACCOUNT=$(gcloud logging sinks \
   describe $SINK_NAME \
   --project $CLUSTER_PROJECT_ID \
   --format="value(writerIdentity)")

gcloud projects add-iam-policy-binding $TENANT_PROJECT_ID \
   --member=$SINK_SERVICE_ACCOUNT \
   --role='roles/logging.bucketWriter' \
   --condition="expression=resource.name.endsWith\
   (\"locations/global/buckets/$CLUSTER_PROJECT_ID\"),\
   title=Log bucket writer from $CLUSTER_PROJECT_ID"

Configuração de permissões de locatário com controle de acesso baseado em papéis (RBAC)

Você usou anteriormente Grupos do Google e o IAM para configurar permissões e permitir que os locatários acessem o Google Cloud projeto do cluster do GKE. Para permitir que os locatários acessem os recursos no cluster do GKE, você precisa definir permissões com o RBAC do Kubernetes.

Criar papéis de cluster

Depois de definir e criar os papéis de cluster a seguir, é possível continuar a usar estes no futuro para adicionar todos os locatários subsequentes doprojeto de cluster Google Cloud .

Papéis de IU

Com esse papel, os locatários podem consultar todos os namespaces. Isso é necessário para descobrir quais namespaces os usuários têm acesso para criar serviços /sdk/gcloud/reference/logging/sinks/create.

kubectl create clusterrole \
   namespace-lister \
   --verb=list \
   --resource=namespaces

Esse papel permite que os locatários visualizem serviços do Knative serving. Isso é necessário para listar os serviços na interface do Knative serving.

kubectl create clusterrole \
   ksvc-lister \
   --verb=list \
   --resource=services.serving.knative.dev

Criar papéis de cluster

Apenas uma dessas permissões é necessária. A primeira permissão admite que os locatários manipulem qualquer recurso no seu namespace. A segunda permissão permite um conjunto mais limitado apenas para criar serviços do Knative serving.

kubectl create clusterrole \
   kubernetes-developer \
   --verb="*" \
   --resource="*.*"

Se a permissão kubernetes-developer for muito permissiva, o código a seguir admitirá que os locatários criem serviços do Knative nos seus namespaces e vejam os outros recursos do Knative.

cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: knative-developer
rules:
- apiGroups: ["serving.knative.dev"]
  resources: ["services"]
  verbs: ["*"]
- apiGroups: ["serving.knative.dev"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
EOF

Crie namespace de locatário e atribua permissões.

Isso pressupõe que você configurou usando o Grupos do Google para o GKE. Isso é necessário para cada locatário.

export TENANT_GROUP=tenant-a@company.com

TENANT_GROUP precisa parte de SECURITY_GROUP

Capacidade de visualizar todos os namespaces

Para consultar o cluster do GKE, todos os locatários precisam da capacidade de listar namespaces. Atualmente, não há um auth can-i que retorna namespaces para os quais uma ação é possível. A única solução é listar os namespaces e, em seguida, consultar cada namespace individualmente.

kubectl create clusterrolebinding \
   all-namespace-listers \
   --clusterrole=namespace-lister \
   --group=$TENANT_GROUP

Capacidade de listar os serviços do Knative serving

kubectl create clusterrolebinding \
   all-ksvc-listers \
   --clusterrole=ksvc-lister \
   --group=$TENANT_GROUP

Capacidade de manipular recursos no namespace

Primeiro, crie o namespace:

kubectl create namespace $NAMESPACE

Se estiver usando o papel kubernetes-developer:

kubectl create rolebinding \
   kubernetes-developer \
   --namespace=$NAMESPACE \
   --clusterrole=kubernetes-developer \
   --group=$TENANT_GROUP

Se estiver usando o papel knative-developer:

kubectl create rolebinding \
   kubernetes-developer \
   --namespace=$NAMESPACE \
   --clusterrole=knative-developer \
   --group=$TENANT_GROUP

Adicione a possibilidade de o locatário acessar o endereço IP externo

cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ingress-reader
rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get"]
EOF

kubectl create rolebinding \
   ingress-reader-$TENANT_GROUP \
   --namespace=istio-system \
   --clusterrole=ingress-reader \
   --group=$TENANT_GROUP

Verificar

Para verificar se você configurou corretamente a multilocação empresarial, você pode abrir o Google Cloud projeto de locatário no Knative serving e implantar um serviço em um cluster do GKE.

Acessar o Knative serving

Parabéns, agora seu locatário pode interagir com os serviços e recursos dentro do namespace do cluster do GKE a que ele recebeu acesso.

Referência de multilocação