Présentation de la connexion de l'orchestrateur de conteneurs

Sélectionnez une version de la documentation :

Cette présentation décrit les configurations de connexion et d'accès critiques pour les bases de données AlloyDB Omni déployées sur un cluster Kubernetes, et explique comment établir une connectivité flexible et sécurisée. La connexion comprend les zones suivantes :

  • Mise en réseau : découvrez comment configurer des clusters de bases de données AlloyDB Omni pour un accès interne à l'aide d'un service Kubernetes ClusterIP ou un accès externe à l'aide d'un LoadBalancer, y compris comment limiter le trafic externe à l'aide de plages CIDR (Classless Inter-Domain Routing) sources.
  • Regroupement de connexions : utilisez la ressource personnalisée PgBouncer pour implémenter le regroupement de connexions afin de gérer efficacement les connexions et de réduire la charge sur les instances de base de données.
  • Authentification et autorisation : sécurisez l'accès à l'aide de méthodes compatibles, telles que l'intégration basée sur un mot de passe, Active Directory et Kerberos, ainsi qu'un contrôle précis mis en œuvre via les règles de réseau Kubernetes et les rôles PostgreSQL.

Mise en réseau

Vous pouvez configurer les clusters de bases de données AlloyDB Omni, gérés par la ressource personnalisée DBCluster, pour un accès interne ou externe.

Pour en savoir plus sur les options de mise en réseau DBCluster, consultez la documentation de référence sur la CRD DBCluster.

Connectivité interne

Par défaut, les instances AlloyDB Omni sont exposées à l'aide d'un service Kubernetes ClusterIP. Cela garantit que les instances ne sont accessibles qu'aux autres applications exécutées dans le même cluster Kubernetes. Vous pouvez trouver le point de terminaison de l'instance principale dans l'état DBCluster.

Connectivité externe

Pour autoriser les connexions depuis l'extérieur du cluster Kubernetes, mettez à jour la spécification DBCluster :

  • Activer le trafic externe : définissez spec.allowExternalIncomingTraffic: true, qui provisionne généralement un service LoadBalancer.
  • Mettre en œuvre un contrôle ultraprécis : utilisez spec.primarySpec.dbLoadBalancerOptions. Par exemple, surGoogle Cloud, définissez gcp.loadBalancerType: "External" pour obtenir une adresse IP accessible depuis l'Internet public.

Limiter l'accès

Pour sécuriser les connexions externes, utilisez spec.primarySpec.sourceCidrRanges pour définir une liste de plages CIDR autorisées. Le système bloque toutes les connexions provenant d'adresses IP situées en dehors de ces plages.

Regroupement de connexions avec PgBouncer

Pour gérer efficacement les connexions et réduire la charge des instances, utilisez PgBouncer. L'opérateur AlloyDB Omni fournit une ressource personnalisée (CR) PgBouncer pour simplifier cette opération.

Pour en savoir plus sur la configuration de PgBouncer, consultez la documentation de référence sur les CRD PgBouncer.

Déploiement et configuration

Créez une ressource PgBouncer et référencez votre cluster de bases de données dans spec.dbclusterRef. Les paramètres clés de spec.parameters sont les suivants :

  • pool_mode : détermine quand les connexions sont réutilisées (session, transaction ou statement).
  • default_pool_size : connexions au serveur par utilisateur et par base de données.
  • max_client_conn : nombre maximal de connexions client autorisées.
  • max_db_connections : nombre maximal de connexions ouvertes à l'instance AlloyDB Omni.

Exposer PgBouncer

Utilisez spec.serviceOptions.type pour contrôler la visibilité.

  • ClusterIP : accès au cluster interne uniquement.
  • LoadBalancer : accès externe. Vous pouvez restreindre cela avec spec.serviceOptions.loadBalancerSourceRanges à l'aide de blocs CIDR.

Authentification et autorisation

AlloyDB Omni accepte plusieurs méthodes pour valider les identités et contrôler les accès.

Méthodes d'authentification

  • Basée sur un mot de passe : authentification standard par nom d'utilisateur et mot de passe PostgreSQL. Le mot de passe administrateur est généralement fourni à l'aide d'un secret Kubernetes, comme indiqué dans l'exemple de DBCluster complet.

  • Active Directory et Kerberos : gérés à l'aide de la ressource personnalisée UserDefinedAuthentication. Cela permet la synchronisation des groupes GSSAPI et LDAP à l'aide des éléments suivants :

    • spec.keytabSecretRef : pour les keytabs Kerberos.
    • spec.ldapConfiguration : pour le mappage de groupes et les paramètres LDAP.
    • spec.pgHbaEntries : pour configurer des règles pg_hba.conf, par exemple gss ou ldap.

    Pour en savoir plus, consultez la documentation de référence sur la CRD UserDefinedAuthentication.

  • Basée sur un certificat (prévue) : la compatibilité avec l'authentification par certificat TLS sans mot de passe est prévue dans une prochaine version.

Autorisation et contrôle des accès

  • Règles de réseau Kubernetes : définissez des règles au niveau des pods pour sécuriser le trafic entre les applications et les pods AlloyDB Omni ou PgBouncer.
  • Plages CIDR sources : limitez le trafic au niveau de LoadBalancer.
  • Rôles PostgreSQL : utilisez des rôles et des droits de base de données standards pour gérer les autorisations des utilisateurs une fois qu'ils sont authentifiés.

Étapes suivantes