Bearer token required to unlock SCIM bridge (GKE & Google Workspace)

[petrmvala]

We are running SCIM bridge in the following setup:

• Deployment in GKE (latest version v2.9.13)
• Memorystore Redis with enabled TLS and REDIS_AUTH
• Secrets in GCP Secrets Manager mounted via secrets-store.sci.x-k8s.io/v1 SecretProviderClass respectively via external-secrets.io/v1beta1 ExternalSecret (REDIS_AUTH only as env var)
• Workload Identity (annotated Service Account created for the deployment)
• Deployment via FluxCD

What works:

We have been running this deployment for about 5 months. Deployment is running fine, connection to Memorystore works albeit it was a bit finnicky to set up.

What does not work:

SCIM Bridge requires to be unlocked in order to sync users from the workspace. Whenever a pod gets rotated, the bridge comes up as locked. This requires an admin to go to our scim bridge and manually input a bearer token in order to unlock the vault. Only then can a sync be performed.

Why is this a problem:

Pods in GKE get rotated by design. An automation can only be considered automation if it does not require people signing in manually all the time.

How do we work around it:

Currently we are running a sidecar pod that is sending a ping to the metrics endpoint with a bearer token as a header. This keeps our automation running, but it's an ugly workaround.

How should it work instead:

SCIM bridge can run (and it does for us) under a dedicated service account with permissions to sync users from google workspace. That should be enough. It has service account, it has secrets, it should not require manual action.

A question to you:

Did I miss something in the setup? Is there an undocumented parameter that needs to be set up so we don't need to provide the Bearer token in order to enable the sync?

[plttn]

Hey @petrmvala:

Great question. In short, the SCIM bridge needs the bearer token to decrypt the scimsession file so that it can fully boot to authenticate to 1Password servers.

Generally speaking there are two ways for this to happen:

1. Logging in directly with the bearer token as you've mentioned.
2. The live notifications sent from Workspace should also be able to bootstrap the SCIM bridge assuming they're sent relatively quickly after the pod is rotated.

The fact that you're not seeing 2 occur makes me suspect that your bridge maybe isn't successfully subscribing to Workspace notifications. Have you happened to get in touch with our Integrations Support folks to take a closer look at what exactly might be going on here?

[petrmvala]

Hey @plttn!

Thanks for the response. Is there any documentation to this?

Additionally, I can't imagine how that would possibly work. Google Workspace ha zero knowledge about SCIM bridge running or not. The bridge is just pulling/syncing resources I assume. Can't really tell as it is closed source.
That would mean that the Workspace would have to keep spamming notifications just in case.

But maybe I'm not understanding properly?

Regards