Google GKE and Amazon EKS
Use an agent. Install the agent chart into the cluster (the runtime's install command); it uses its own in-cluster ServiceAccount and only dials out, so it works with private GKE and EKS clusters and needs no cloud IAM sign-in or kubeconfig in BeziSync.
Direct mode (BeziSync talks to the cluster API itself, which must be reachable): untick "Use BeziSync's in-cluster service account" and choose how to sign in.
- GKE — API server endpoint and cluster CA certificate (both in the cluster's details), and a Google service-account key with Kubernetes Engine Developer, or nothing when BeziSync itself runs with Workload Identity. BeziSync mints and refreshes short-lived access tokens.
- EKS — endpoint, CA certificate, cluster name and region, and AWS keys, or nothing when BeziSync
runs with IRSA / an instance role. BeziSync creates the same
k8s-aws-v1.tokens asaws eks get-token(15 minutes, refreshed). Map that IAM identity to a Kubernetes user or group with an access entry (oraws-auth) bound to the Role below. - kubeconfig — any kubeconfig with a static ServiceAccount token (exec plugins such as
gke-gcloud-auth-pluginare not available in the image).
The identity needs the Role from the agent chart in the connector namespace: Deployments,
ConfigMaps, Secrets, pods, logs and pods/proxy.
Around the cluster:
- Databases: choose the AWS RDS/Aurora or GCP Cloud SQL/AlloyDB preset on the source; checks
and fixes then use the provider's settings (
rds.logical_replication,cloudsql.logical_decoding, …). - Secrets: AWS Secrets Manager and Google Secret Manager stores work with keys, or with the control plane's pod identity (IRSA / Workload Identity) when the credentials are left empty.
- Destinations: Kinesis, SQS, SNS, Iceberg (S3, Glue, S3 Tables) and Pub/Sub use keys, or the connector pod's own identity: set the
runtime's connector service account to a ServiceAccount bound to IRSA
(
eks.amazonaws.com/role-arn) or Workload Identity (iam.gke.io/gcp-service-account), and leave the keys empty. - Images: connector pods pull
quay.io/debezium/server; for clusters without that egress, mirror it to Artifact Registry / ECR and choose it as the runtime's default image (or under Settings → Debezium versions).
Checks run where connectors run. For pipelines on an agent runtime, the final checks before a deploy run on the agent, inside the cluster's VPC, so a database reachable only from there passes (the sections say "checked by the agent"). If the agent cannot answer, BeziSync checks from its own network and says so. Checks on the Connections page always run from BeziSync.