Ce guide vous explique comment configurer Knative serving pour permettre à un ou plusieurs projets Google Cloud d'exécuter et de gérer les charges de travail qui s'exécutent sur un cluster GKE situé dans un autre projet Google Cloud.
Avec Knative serving, un modèle d'exploitation commun consiste à, pour une équipe de développeurs d'applications, d'utiliser son projet Google Cloud pour déployer et gérer des services qui s'exécutent dans des clusters GKE disparates sur les projets 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 est spécifiquement compatible avec l'architecture mutualisée d'entreprise. Ce type d'architecture mutualisée active un projet de cluster Google Cloud pour permettre l'accès à des ressources spécifiques de son cluster GKE. Le projet Google Cloud autorisé à accéder au projet Google Cloud de cluster est le projet Google Cloud locataire. Les locataires du projet Google Cloud de cluster peuvent utiliser Knative serving pour accéder aux services et ressources auxquels ils ont accès, les exploiter et en être propriétaires.
D'un point de vue conceptuel, la configuration de l'architecture mutualisée d'entreprise avec Knative serving s'effectue en quatre étapes:
- Configurer l'accès du locataire au projet Google Cloud de cluster à l'aide d'un groupe Google et d'Identity and Access Management
- Mappez chaque projet Google Cloud locataire au projet Google Cloud du cluster.
- Acheminez les données de journal du projet Google Cloud du cluster vers les projets Google Cloud locataires à l'aide de buckets et de récepteurs de journaux.
- 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 :
Comme expliqué dans la documentation GKE, vous devez comprendre les concepts suivants relatifs aux architectures mutualisées :
Ce document part du principe que les projets Google Cloud pour lesquels vous souhaitez activer l'architecture mutualisée existent déjà.
Vous devez disposer d'un accès aux services et ressources Google Cloud suivants :
Autorisations Identity and Access Management dans le projet Google Cloud locataire:
- roles/logging.configWriter
- Administrateur de locataires du groupe Google
Autorisations Identity and Access Management dans le projet Google Cloud de cluster:
Vous devez avoir installé ou installer la dernière version de la [CLI Google Cloud]](/sdk/docs/install).
Définir les variables d'environnement locales
Pour simplifier les commandes utilisées dans ce processus, définissez des variables d'environnement locales pour le projet Google Cloud de cluster et le projet Google Cloud locataire:
Remplacez
YOUR_CLUSTER_PROJECT_ID
par l'ID du projet Google Cloud de cluster, puis exécutez la commande suivante:export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_ID
Remplacez
YOUR_TENANT_PROJECT_ID
par l'ID du projet Google Cloud locataire, puis exécutez la commande suivante:export TENANT_PROJECT_ID=$YOUR_TENANT_PROJECT_ID
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 du projet Google Cloud de votre cluster et l'ID du projet Google Cloud locataire sont désormais utilisés dans toutes les commandes suivantes, où $CLUSTER_PROJECT_ID
et $TENANT_PROJECT_ID
sont spécifiés.
Vérifier les autorisations IAM
Exécutez les commandes testIamPermissions suivantes pour vérifier que vous disposez des autorisations IAM requises pour accéder aux ressources du projet Google Cloud du cluster ainsi qu'aux projets Google Cloud locataires.
Exécutez la commande suivante pour valider vos autorisations sur le projet Google Cloud du cluster:
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 projet Google Cloud de cluster:
{
"permissions": [
"logging.sinks.create",
"logging.sinks.get",
"resourcemanager.projects.setIamPolicy"
]
}
Exécutez la commande suivante pour valider vos autorisations sur chaque projet Google Cloud locataire:
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 chaque projet Google Cloud locataire:
{
"permissions": [
"logging.buckets.create",
"logging.buckets.get",
"resourcemanager.projects.setIamPolicy",
"resourcesettings.settingvalues.create",
"serviceusage.services.enable",
]
}
Utiliser un groupe Google ainsi que la gestion de l'authentification et des accès 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 d'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 votre projet Google Cloud locataire. Pour plus d'informations sur l'utilisation d'un groupe de sécurité, consultez la section Utiliser Google Groupes 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 chaque projet Google Cloud locataire au projet Google Cloud du cluster
Vous utilisez des valeurs de paramètres de ressources pour mapper des projets Google Cloud locataires à un projet Google Cloud de cluster.
Le paramètre de ressource peut être configuré pour chaque projet Google Cloud locataire individuel ou à n'importe quel niveau de la hiérarchie des dossiers. 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 cette configuration effectuée, chaque fois que les locataires parcourent l'interface utilisateur de Knative serving, ils voient également leurs services dans le projet Google Cloud de cluster. Cela ne modifie pas les autorisations IAM sur le projet Google Cloud de cluster ou les clusters GKE. Il s'agit simplement d'un mappage entre un projet (ou dossier) locataire et un projet Google Cloud de cluster.
Activez l'API
resourcesettings
sur le projet Google Cloud locataire.gcloud services enable resourcesettings.googleapis.com \ --project=$TENANT_PROJECT_ID
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 etYOUR_ADMIN_MEMBER_ID
par votre ID utilisateur, par exempleuser:my-email@my-domain.com
.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 Google Cloud parent si tous les projets Google Cloud enfants et les dossiers Google Cloud utilisent cette même valeur.
Projets locataires
Définissez la valeur du paramètre de ressource pour chaque projet Google Cloud locataire:
- Obtenez la valeur
name
du projet Google Cloud locataire et définissez-la dans une variable d'environnement locale :export TENANT_PROJECT_NUMBER=$(gcloud projects describe $TENANT_PROJECT_ID --format="value(projectNumber)")
- Créez un fichier de valeur de paramètre de ressource pour définir le mappage entre le projet Google Cloud locataire et le projet Google Cloud de cluster. Plusieurs ID de projets Google Cloud de cluster peuvent être définis dans ce fichier et ajoutés à un seul projet Google Cloud locataire.
cat > value-file.json << EOF { "name": "projects/$TENANT_PROJECT_NUMBER/settings/cloudrun-multiTenancy/value", "value": { "stringSetValue": { "values": [ "projects/$CLUSTER_PROJECT_ID" ] } } } EOF
- Déployez les paramètres de ressource sur le projet Google Cloud locataire :
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 de définir cette valeur sur tous les projets et dossiers Google Cloud locataires enfants:
- Obtenez le
number
du dossier locataire et définissez-le dans une variable d'environnement locale :export TENANT_FOLDER_NUMBER=$TENANT_FOLDER_NUMBER
- Créez un fichier de valeur de paramètre de ressource pour définir le mappage du dossier locataire au projet Google Cloud du cluster. Plusieurs ID de projets Google Cloud de cluster peuvent être définis dans ce fichier et ajoutés à un même dossier locataire.
cat > value-file.json << EOF { "name": "folders/$TENANT_FOLDER_NUMBER/settings/cloudrun-multiTenancy/value", "value": { "stringSetValue": { "values": [ "projects/$CLUSTER_PROJECT_ID" ] } } } EOF
- 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, un récepteur et les autorisations permettant d'acheminer les données des journaux du projet Google Cloud du cluster vers le projet Google Cloud locataire. Dans les étapes suivantes, tous les journaux de l'espace de noms dans le projet Google Cloud de cluster 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 du projet Google Cloud de cluster et du projet Google Cloud locataire que vous avez précédemment créées. 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. Notez que le nom du bucket de journaux doit correspondre à l'ID du projet Google Cloud du cluster. Il ne peut être ni modifié, ni modifié.
gcloud logging buckets \
create $CLUSTER_PROJECT_ID \
--location=global \
--project=$TENANT_PROJECT_ID
Exécutez la commande suivante pour créer le récepteur depuis l'espace de noms spécifié dans le projet Google Cloud de cluster vers le bucket du projet Google Cloud locataire. Notez que vous pouvez réduire le champ d'application des journaux, par exemple pour ne partager qu'un cluster GKE individuel ou des ressources Knative serving spécifiques, en définissant des valeurs log-filter
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 d'accès basé sur les rôles (RBAC)
Vous avez précédemment utilisé Google Groupes et IAM pour configurer les autorisations permettant aux locataires d'accéder au projet Google Cloud 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
Après avoir défini et créé les rôles de cluster suivants, vous pouvez continuer à les utiliser à l'avenir pour ajouter tous les locataires ultérieurs du projet Google Cloud de cluster.
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. Nécessaire pour répertorier 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 deuxième 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
Possibilité 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 le projet Google Cloud locataire dans Knative serving et en déployant un service sur un cluster GKE.
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
- Architecture GKE mutualisée
- Bonnes pratiques concernant l'architecture GKE mutualisée
- Quota d'espaces de noms