Architecture mutualisée et multi-projets avec Knative serving

Ce guide explique comment configurer Knative serving afin d'autoriser un ou plusieurs Google Cloud projets à exécuter et gérer les charges de travail qui s'exécutent sur un cluster GKE dans un autre Google Cloud projet.

Un modèle d'exploitation commun tirant parti de Knative serving est utile lorsqu'une équipe de développeurs d'applications utilise son Google Cloud projet pour déployer et gérer des services exécutés dans des clusters GKE distincts hébergés dans lesprojets Google Cloud d'autres équipes. Cette fonctionnalité, appelée Architecture mutualisée, vous permet en tant qu'opérateur de plate-forme de personnaliser l'accès de vos équipes de développement et de le limiter à leurs propres services exécutés dans les divers environnements de vos organisations (par exemple, environnement de production ou préproduction).

Knative serving prend spécifiquement en charge l'architecture mutualisée d'entreprise. Ce type d'architecture mutualisée active un projet Google Cloud de cluster afin d'autoriser l'accès à des ressources spécifiques de son cluster GKE. Le Google Cloud projet auquel l'accès au projet de cluster est accordé est le projet locataire Google Cloud . Google Cloud Les locataires du projet de Google Cloud cluster peuvent utiliser Knative serving pour gérer les accès, l'exploitation et la propriété des services et ressources auxquels ils ont accès.

D'un point de vue conceptuel, configurer une architecture mutualisée d'entreprise avec Knative serving implique quatre étapes :

  1. Configurer l'accès du locataire au projet de cluster Google Cloud à l'aide d'un groupe Google et du Identity and Access Management.
  2. Mapper chaqueprojet locataire Google Cloud auprojet de cluster Google Cloud .
  3. Acheminer les données de journalisation du cluster Google Cloud projet vers les locataires Google Cloud projets à l'aide de buckets et de récepteurs de journaux.
  4. Définir les autorisations des locataires sur le cluster à l'aide du contrôle des accès basé sur les rôles.

Avant de commencer

L'opérateur de plate-forme responsable de la configuration de l'architecture mutualisée doit comprendre les exigences suivantes et les respecter :

Définir les variables d'environnement locales

Pour simplifier les commandes utilisées lors de ce processus, définissez des variables d'environnement locales représentant le cluster Google Cloud projet et le locataire Google Cloud projet :

  1. Remplacez YOUR_CLUSTER_PROJECT_ID par l'ID du cluster Google Cloud project, puis exécutez la commande suivante :

    export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_ID

  2. Remplacez YOUR_TENANT_PROJECT_ID par l'ID du projet locataire, puis exécutez la commande suivante : Google Cloud 

    export TENANT_PROJECT_ID=$YOUR_TENANT_PROJECT_ID

  3. Vérifiez vos variables d'environnement locales à l'aide des commandes suivantes :

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

L'ID de votreprojet de cluster et l'ID de votreprojet locataire sont désormais utilisés dans toutes les commandes suivantes où $CLUSTER_PROJECT_ID et $TENANT_PROJECT_ID sont spécifiés. Google Cloud Google Cloud

Vérifier les autorisations IAM

Exécutez les commandes testIamPermissions ci-dessous pour vérifier que vous disposez bien des autorisations IAM requises pour accéder aux ressources du projet de cluster Google Cloud , ainsi qu'à celles des projets locataires Google Cloud .

Exécutez la commande suivante pour valider vos autorisations sur le cluster Google Cloud projet :

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

Résultats attendus pour le cluster Google Cloud projet :

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

Exécutez la commande suivante pour valider vos autorisations sur chaqueprojet locataire : Google Cloud 

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

Résultats attendus pour chaqueprojet locataire Google Cloud :

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

Utiliser un groupe Google ainsi que Identity and Access Management pour configurer l'accès des locataires

Utilisez un groupe Google pour permettre aux locataires d'accéder au cluster GKE. Les autorisations IAM permettent aux locataires d'obtenir des identifiants, mais ils ne pourront effectuer aucune action au sein du cluster avant la configuration effective du contrôle des accès basé sur les rôles Kubernetes, qui intervient dans une étape ultérieure.

Vous devez créer un groupe Google contenant tous les utilisateurs de votreprojet locataire Google Cloud . Pour en savoir plus sur l'utilisation d'un groupe de sécurité, consultez Utiliser des groupes Google pour GKE.

Créez la variable d'environnement locale suivante pour représenter votre groupe Google :

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

Lecteur de cluster Kubernetes

Exécutez les commandes suivantes afin de permettre aux locataires d'obtenir des identifiants pour le cluster. Cela ne permet pas aux locataires de lire ou de manipuler des ressources sur le cluster GKE.

Documentation de référence sur IAM

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

Pour restreindre l'accès à un cluster spécifique, vous pouvez utiliser une condition 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"

Lecteur Monitoring

Exécutez la commande suivante afin d'autoriser les locataires à lire les métriques de surveillance.

Documentation de référence sur les rôles Monitoring

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

Mapper chaqueprojet locataire auprojet de cluster Google Cloud Google Cloud

Utilisez les valeurs des paramètres de ressource pour mapper lesprojets locataires à unprojet de cluster. Google Cloud Google Cloud

Le paramètre de ressource peut être configuré pour chaqueprojet locataire individuel ou défini à n'importe quel niveau de la hiérarchie des dossiers. Google Cloud Il est plus facile de définir ce paramètre au niveau d'un dossier locataire unique, mais le définir au niveau de chaque projet locataire offre davantage de souplesse. Une fois ce paramètre configuré, chaque fois que les locataires parcourent l' interface utilisateur de Knative serving, ils voient également leurs services sur le projet de Google Cloud cluster. Cela ne modifie pas les autorisations IAM sur leprojet de cluster Google Cloud ni sur les clusters GKE. Il s'agit simplement d'un mappage entre un projet (ou dossier) locataire et un projet de cluster Google Cloud .

  1. Activez l'API resourcesettings sur le locataire Google Cloud projet.

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

  2. Ajoutez les droits d'administrateur de l'organisation (roles/resourcesettings.admin) à votre ID utilisateur en exécutant la commande suivante :

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

    Remplacez YOUR_ORGANIZATION_ID par l'ID de votre organisation et YOUR_ADMIN_MEMBER_ID par votre ID utilisateur, par exemple user:my-email@my-domain.com.

  3. Choisissez l'une des méthodes suivantes pour définir le mappage.

    Vous pouvez définir la valeur du paramètre de ressource sur un dossier parent Google Cloud , si tous les projets Google Cloud et dossiers Google Cloud enfants utilisent la même valeur.

Projets locataires

Définissez la valeur du paramètre de ressource pour chaqueprojet locataire : Google Cloud

  1. Obtenez le name du projet locataire et enregistrez-le dans une variable d'environnement locale : Google Cloud 
    export TENANT_PROJECT_NUMBER=$(gcloud projects describe $TENANT_PROJECT_ID --format="value(projectNumber)")
  2. Créez un fichier de valeur de paramètre de ressource pour définir le mappage entre le locataire Google Cloud projet et le cluster Google Cloud projet. Vous pouvez définir plusieurs ID deprojet de cluster dans ce fichier et les ajouter à un seulprojet locataire. 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. Déployez les paramètres de ressource dans leprojet locataire Google Cloud : 
    gcloud resource-settings set-value cloudrun-multiTenancy --value-file value-file.json --project $TENANT_PROJECT_ID

Dossiers locataires

Définissez la valeur du paramètre de ressource pour un dossier locataire parent afin d'appliquer cette valeur à tous lesprojets etdossiers locataires enfants : Google Cloud

  1. Obtenez le numéro (number) du dossier locataire et enregistrez-le dans une variable d'environnement locale : 
    export TENANT_FOLDER_NUMBER=$TENANT_FOLDER_NUMBER
  2. Créez un fichier de valeur de paramètre de ressource pour définir le mappage entre le dossier locataire et le cluster Google Cloud projet. Vous pouvez définir plusieurs ID deprojet de cluster dans ce fichier et les ajouter à un seul dossier locataire. 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. Déployez les paramètres de ressource dans le dossier locataire : 
    gcloud resource-settings set-value cloudrun-multiTenancy --value-file value-file.json --folder $TENANT_FOLDER_NUMBER

Configurer les buckets et récepteurs de journaux pour acheminer les données de journalisation

Pour chaque locataire, vous créez un bucket de journaux et un récepteur de journaux ainsi que les autorisations requises pour acheminer les données des journaux du cluster Google Cloud projet vers leprojet locataire. Google Cloud Au cours des étapes suivantes, tous les journaux de l'espace de noms du cluster Google Cloud project sont acheminés vers le bucket. Consultez l'ensemble ci-dessous pour découvrir comment limiter les journaux partagés.

Créez les variables d'environnement locales suivantes :

  • Spécifiez l'espace de noms du cluster GKE auquel vos locataires accèdent.
  • Nom du récepteur. Pour simplifier cette étape, le nom est une combinaison des variables d'environnement locales correspondant au projet de cluster Google Cloud et auprojet locataire Google Cloud , que vous avez créées précédemment. Vous pouvez modifier cette valeur.
export NAMESPACE=$NAMESPACE
export SINK_NAME=$CLUSTER_PROJECT_ID-$TENANT_PROJECT_ID

Exécutez la commande suivante afin de créer le bucket de journaux dans le projet locataire. Note que le nom du bucket de journaux doit correspondre à l'ID duprojet de cluster, et qu'il ne peut faire l'objet d'aucune modification. Google Cloud 

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

Exécutez la commande suivante pour créer le récepteur à partir de l'espace de noms spécifié dans le cluster Google Cloud projet, vers le projet Google Cloud locataire bucket. Notez que vous pouvez réduire le champ d'application de les journaux, par exemple pour ne partager qu'un cluster GKE individuel ou des ressources Knative serving spécifiques, en définissant des log-filter valeurs supplémentaires.

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

Exécutez les commandes suivantes afin d'ajouter l'autorisation du compte de service du récepteur de journaux au bucket que vous avez créé précédemment.

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"

Configurer les autorisations des locataires à l'aide du contrôle des accès basé sur les rôles (RBAC)

Dans les étapes précédentes, vous avez utilisé Google Groupes et IAM pour configurer les autorisations permettant aux locataires d'accéder au Google Cloud projet du cluster GKE. Pour autoriser des locataires à accéder aux ressources du cluster GKE, vous devez définir des autorisations à l'aide de Kubernetes RBAC.

Créer des rôles de cluster

Une fois que vous avez défini et créé les rôles de cluster suivants, vous pouvez continuer à utiliser ces derniers pour ajouter tout nouveau locataire du projet de cluster Google Cloud .

Rôles pour l'interface utilisateur

Ce rôle permet aux locataires d'interroger tous les espaces de noms. Il sert à déterminer les espaces de noms auxquels les utilisateurs ont accès pour créer des services /sdk/gcloud/reference/logging/sinks/create.

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

Ce rôle permet aux locataires d'afficher les services Knative serving. Il est nécessaire pour lister les services dans l'interface utilisateur de Knative serving.

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

Créer des rôles de cluster

Une seule des autorisations suivantes est nécessaire. La première autorisation permet aux locataires de manipuler n'importe quelle ressource dans leur espace de noms. La seconde autorisation est plus limitée et permet uniquement de créer des services Knative serving.

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

Si l'autorisation kubernetes-developer est trop permissive, le code suivant permet aux locataires de créer des services Knative sur leurs espaces de noms et d'afficher les autres ressources 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

Créer un espace de noms locataire et attribuer des autorisations

Cette section présuppose que vous avez réalisé votre configuration à l'aide de Google Groupes pour GKE. Il est nécessaire d'effectuer cette opération pour chaque locataire.

export TENANT_GROUP=tenant-a@company.com

TENANT_GROUP doit faire partie de SECURITY_GROUP.

Rôle permettant d'afficher tous les espaces de noms

En matière d'interrogation du cluster GKE, tous les locataires ont au plus la possibilité de répertorier les espaces de noms. Il n'existe actuellement pas de commande auth can-i qui renverrait les espaces de noms sur lesquels une action donnée est autorisée. La seule solution consiste à répertorier l'ensemble des espaces de noms, puis à interroger chaque espace de noms individuellement.

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

Rôle permettant de lister les services Knative serving

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

Rôle permettant de manipuler les ressources dans l'espace de noms

Commencez par créer l'espace de noms :

kubectl create namespace $NAMESPACE

Si vous utilisez le rôle kubernetes-developer :

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

Si vous utilisez le rôle knative-developer :

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

Rôle permettant au locataire d'accéder à une adresse IP externe

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

Valider

Vous pouvez vérifier que vous avez correctement configuré l'architecture mutualisée d'entreprise en ouvrant leprojet locataire dans Knative serving et en déployant un service sur un cluster GKE. Google Cloud

Accéder à Knative serving

Félicitations, votre locataire peut désormais interagir avec les services et ressources figurant dans l'espace de noms du cluster GKE auquel il a accès.

Documentation de référence sur l'architecture mutualisée