Problem
When a customer sets up bring-your-own-key (BYOK) config encryption, they must grant decrypt on their KMS key to the right Estuary data plane identity. That identity:
- Differs per KMS provider (GCP service account, AWS IAM user, Azure application).
- Differs per data plane.
- Is independent of the cloud the data plane runs in. A data plane carries an identity for all three clouds, so a customer on an AWS plane can encrypt with a GCP, AWS, or Azure key.
Today the Data Plane details panel (Admin > Settings > Data Planes) shows only the plane's native-cloud essentials (for an AWS plane: the IAM OIDC issuer and egress IPs). None of the three KMS grant identities are shown:
- GCP:
data_planes.gcp_service_account_email
- AWS:
data_planes.aws_iam_user_arn
- Azure:
data_planes.azure_application_client_id
So customers can't self-serve, and support has to look the values up in the database and hand them over.
Concrete case
A customer on two private AWS data planes asked how to grant access for BYOK with a GCP KMS key. We offered both options (a GCP key, or, since they run on AWS, an AWS key). That meant handing them two different principals pulled from the database:
- The GCP service account (for a GCP KMS key)
- The AWS IAM user ARN (for an AWS KMS key)
Neither was visible anywhere in the dashboard.
Ask
Surface all three KMS grant identities for a data plane, clearly labeled by KMS provider, ideally grouped under a BYOK / KMS heading in the data plane details popup. For each, show the exact principal to grant and the permission to grant it (for example GCP roles/cloudkms.cryptoKeyDecrypter, AWS kms:Decrypt). That lets a customer complete BYOK without a support round-trip.
These columns already carry a column-level GRANT SELECT ... TO authenticated, so the dashboard can read them.
At minimum, show the GCP service account and the AWS IAM user ARN, the two most-requested paths.
Context
Came up via a support thread on BYOK config encryption: a customer on private AWS data planes wanting to encrypt connector configs with their own key, offered both a GCP-key and an AWS-key path. The identities to grant were not visible in the dashboard for either.
Related docs clarification: estuary/flow#3065
Problem
When a customer sets up bring-your-own-key (BYOK) config encryption, they must grant decrypt on their KMS key to the right Estuary data plane identity. That identity:
Today the Data Plane details panel (Admin > Settings > Data Planes) shows only the plane's native-cloud essentials (for an AWS plane: the IAM OIDC issuer and egress IPs). None of the three KMS grant identities are shown:
data_planes.gcp_service_account_emaildata_planes.aws_iam_user_arndata_planes.azure_application_client_idSo customers can't self-serve, and support has to look the values up in the database and hand them over.
Concrete case
A customer on two private AWS data planes asked how to grant access for BYOK with a GCP KMS key. We offered both options (a GCP key, or, since they run on AWS, an AWS key). That meant handing them two different principals pulled from the database:
Neither was visible anywhere in the dashboard.
Ask
Surface all three KMS grant identities for a data plane, clearly labeled by KMS provider, ideally grouped under a BYOK / KMS heading in the data plane details popup. For each, show the exact principal to grant and the permission to grant it (for example GCP
roles/cloudkms.cryptoKeyDecrypter, AWSkms:Decrypt). That lets a customer complete BYOK without a support round-trip.These columns already carry a column-level
GRANT SELECT ... TO authenticated, so the dashboard can read them.At minimum, show the GCP service account and the AWS IAM user ARN, the two most-requested paths.
Context
Came up via a support thread on BYOK config encryption: a customer on private AWS data planes wanting to encrypt connector configs with their own key, offered both a GCP-key and an AWS-key path. The identities to grant were not visible in the dashboard for either.
Related docs clarification: estuary/flow#3065