Présentation de la connexion AlloyDB Omni sur Kubernetes

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. Elle explique également comment établir une connectivité flexible et sécurisée. La connexion inclut les domaines suivants :

  • Mise en réseau : découvrez comment configurer les clusters de bases de données AlloyDB Omni pour un accès interne à l'aide d'un service ClusterIP Kubernetes ou pour un accès externe à l'aide d'un LoadBalancer, y compris comment limiter le trafic externe à l'aide de plages d'adresses CIDR (Classless Inter-Domain Routing) sources.
  • Pooling de connexions : utilisez la ressource personnalisée PgBouncer pour implémenter le pooling 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 : accès sécurisé à l'aide de méthodes compatibles telles que l'intégration basée sur un mot de passe et Active Directory/Kerberos, ainsi qu'un contrôle précis implémenté par le biais des règles réseau Kubernetes et des 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 le CRD DBCluster.

Connectivité interne

Par défaut, les instances AlloyDB Omni sont exposées à l'aide d'un service ClusterIP Kubernetes. Cela garantit que les instances ne sont accessibles qu'aux autres applications s'exécutant dans le même cluster Kubernetes. Vous trouverez 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 :

  • Activez le trafic externe : définissez spec.allowExternalIncomingTraffic: true, ce qui provisionne généralement un service LoadBalancer.
  • Mettez en œuvre un contrôle ultraprécis : utilisez spec.primarySpec.dbLoadBalancerOptions. Par exemple, sur Google 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 afin de définir une liste de plages CIDR autorisées. Le système bloque toutes les connexions provenant d'adresses IP 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 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. Voici les principaux paramètres de spec.parameters :

  • 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 limiter cela avec spec.serviceOptions.loadBalancerSourceRanges à l'aide de blocs CIDR.

Authentification et autorisation

AlloyDB Omni est compatible avec plusieurs méthodes permettant de valider les identités et de contrôler les accès.

Méthodes d'authentification

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

  • Active Directory et Kerberos : gérés à l'aide du CR UserDefinedAuthentication. Il est compatible avec 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 le CRD UserDefinedAuthentication.

  • Basée sur les certificats (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.
  • Les plages CIDR sources permettent de limiter le trafic au niveau de LoadBalancer.
  • Rôles PostgreSQL : utilisez les rôles et les droits d'accès standards des bases de données pour gérer les autorisations des utilisateurs une fois qu'ils sont authentifiés.

Étapes suivantes