Rôles IAM AWS
Rôle IAM Bootstrap
Le rôle IAM Bootstrap dispose des autorisations suivantes :- Opérations EC2 et VPC : requises pour configurer le VPC et les clusters EKS.
- Opérations S3 (par ex.,
s3:CreateBucket) : nécessaires pour créer des buckets pour le stockage BYOC de ClickHouse. - Opérations IAM (par ex.,
iam:CreatePolicy) : nécessaires pour que les controllers créent des rôles supplémentaires (voir la section suivante pour plus de détails). - Opérations EKS : limitées aux ressources dont le nom commence par le préfixe
clickhouse-cloud.
Rôles IAM supplémentaires créés par le contrôleur
En plus duClickHouseManagementRole créé via CloudFormation, le contrôleur créera plusieurs rôles supplémentaires.
Ces rôles sont endossés par des applications exécutées dans le cluster EKS du client :
- State Exporter Role
- Composant ClickHouse qui transmet des informations sur l’état de santé du service à ClickHouse Cloud.
- Nécessite l’autorisation d’écrire dans une file d’attente SQS appartenant à ClickHouse Cloud.
- Load-Balancer Controller
- Contrôleur AWS de load balancer standard.
- Contrôleur EBS CSI pour gérer les volumes des services ClickHouse.
- External-DNS
- Propage les configurations DNS vers Route 53.
- Cert-Manager
- Provisionne des certificats TLS pour les domaines de service BYOC.
- Cluster Autoscaler
- Ajuste la taille du groupe de nœuds selon les besoins.
- Stockage de monitoring (Thanos)
- Endossé par les charges de travail Prometheus et Thanos de votre cluster.
- Écrit et lit les métriques conservées sur le long terme, avec une portée limitée au bucket de monitoring de votre propre compte.
data-plane-mgmt permet à un composant du plan de contrôle ClickHouse Cloud de réconcilier les Custom resources nécessaires, comme ClickHouseCluster et le service virtuel/la Gateway Istio.
Comptes de service de GCP
Compte de service Bootstrap
Le compte de service Bootstrap se voit attribuer des rôles personnalisés à l’échelle du projet avec les autorisations suivantes :- Common : autorisations de base en lecture et en identité.
- VPC : gère le VPC, les sous-réseaux, le routage et les rattachements Private Service Connect qui hébergent votre infrastructure BYOC.
- Cluster : gère les clusters GKE et les ressources du cluster.
- Storage : utilisé pour gérer les buckets Cloud Storage servant aux sauvegardes de ClickHouse, à l’état partagé et aux données de monitoring.
- IAM Role : gère les comptes de service et les rôles personnalisés dans le projet. Ce rôle ne permet pas de créer des clés de compte de service, de lier des politiques d’organisation ou de modifier des ressources dans d’autres projets.
Comptes de service supplémentaires créés par le contrôleur
En plus du compte de serviceclickhouse-management créé via Terraform dans le cadre de l’onboarding, lorsque vous provisionnez votre premier service BYOC, le plan de contrôle de ClickHouse (s’authentifiant en tant que clickhouse-management) crée des comptes de service supplémentaires dans votre projet pour des charges de travail intra-cluster spécifiques. Chacun est créé avec un jeu d’autorisations restreint, à usage unique.
- Identité d’exécution des nœuds GKE
- Attachée à chaque machine virtuelle de nœud GKE de votre cluster BYOC.
- Utilisée par le kubelet, les agents locaux au nœud et les collecteurs Cloud Operations pour émettre des logs et des métriques, ainsi que par le sous-système de récupération d’images pour télécharger des images de conteneur.
- Identité du scraper de facturation
- Utilisée par la charge de travail du scraper autonome pour collecter la télémétrie de facturation.
- Identité de monitoring
- Identité cible de la stack de monitoring exécutée dans votre cluster. Utilisée pour lire et écrire dans le stockage à long terme des métriques d’un bucket GCS dédié à ce déploiement.
- Identité de gestion de l’exécution ClickHouse
- Utilisée par le contrôleur de gestion du plan de données à l’exécution de ClickHouse, qui gère les opérations courantes post-déploiement telles que la gestion des points de terminaison Private Service Connect, les ajustements du cycle de vie des buckets et les rotations de comptes de service.
state-exporter intra-cluster de l’usurper. Aucun matériel de clé n’est impliqué, et l’identité qui publie vers Pub/Sub ne détient aucune autorisation dans votre projet.
Rôles et identités Azure
Principal de service d’onboarding
L’onboarding via le module Terraform pour Azure provisionne une application mutualisée en tant qu’application d’entreprise (principal de service) dans votre locataire, conformément aux recommandations d’Azure relatives à l’authentification inter-locataires. Le principal de service se voit attribuer un rôle personnalisé respectant le principe du moindre privilège, limité à l’abonnement cible, avec les autorisations suivantes :- Réseau : Gérer le VNet, les sous-réseaux, les adresses IP publiques, les passerelles NAT, les groupes de sécurité réseau et les zones DNS qui hébergent votre infrastructure BYOC.
- Cluster : Gérer les clusters AKS et les pools de nœuds.
- Storage : Gérer les comptes de stockage et les conteneurs blob utilisés pour les données ClickHouse, les sauvegardes et les données de monitoring.
- Identité : Gérer les identités managées attribuées par l’utilisateur et leurs informations d’identification fédérées au sein de l’abonnement.
- Autorisation : Gérer les définitions de rôles personnalisés et les attributions de rôles. Toutes les autorisations sont limitées à l’abonnement cible : le rôle ne peut pas accéder aux ressources d’autres abonnements ou locataires.
Identités managées supplémentaires créées par le contrôleur
Lorsque vous provisionnez des services BYOC, le plan de contrôle de ClickHouse crée des identités managées attribuées par l’utilisateur dans votre abonnement. Chacune est fédérée à un compte de service Kubernetes spécifique (identité de charge de travail) et dispose d’un ensemble d’autorisations restreint, dédié à un seul usage :- Identité par service
- Utilisée par chaque service ClickHouse pour accéder à son propre compte de stockage afin d’y stocker les données de table et les sauvegardes, via un rôle personnalisé de stockage Blob limité à ce compte de stockage.
- Lorsqu’un service est restauré à partir d’une sauvegarde, il reçoit également un accès en lecture seule au conteneur de sauvegarde du service source.
- Identité d’infrastructure partagée
- Utilisée par le contrôleur de gestion du plan de données à l’exécution de ClickHouse pour les opérations courantes, telles que la gestion des services Private Link.
- Identité de monitoring
- Fédérée à la charge de travail Thanos de votre cluster, via un rôle personnalisé limité à l’accès au stockage de monitoring.
- Écrit et lit les métriques conservées à long terme dans votre propre abonnement.
state-exporter du cluster d’obtenir des jetons pour celle-ci, sans échange de secrets. L’identité qui publie vers Service Bus ne détient aucune autorisation dans votre abonnement.
Cela diffère d’AWS, où le rôle de publication est créé dans votre propre compte et assume un rôle côté ClickHouse pour atteindre la file d’attente. Sur GCP et Azure, l’identité de publication réside entièrement du côté ClickHouse et votre cluster ne fait que s’y fédérer : il n’y a donc aucune autorisation supplémentaire à auditer dans votre compte pour ce flux. Le trafic sortant lui-même est inventorié dans les limites réseau.