Configuration persistence through restarts

bpd
bpd
Community Member
in SCIM Bridge

Hello,

I've deployed SCIM Bridge on Kubernetes with Google Workspace, it works fine. My deployment is based on https://github.com/1Password/scim-examples

Recently, the Redis pod in the deployment failed, was destroyed, and a new pod was started. SCIM Bridge continued to work however I was notified that the "synced groups" that were selected in the UI were no longer selected. So, SCIM Bridge de-provisioned access for everyone in those groups. After we regained access and re-selected the synced groups, our users regained access.

My questions are, why is it suggested to use a container deployment without any persistence for an application like this if there is configuration that should be retained? Why did we lose this configuration because of a restart in Redis? Is the application saving selections made in the UI in Redis? If so, shouldn't Redis data be persisted?

How can I avoid this problem in the future?

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser: Not Provided

Comments

  • Jamie1P
    Jamie1P

    Hi there,

    I did some digging to get more context on why the users were deactivated. It looks like the Workspace's automatic sync checks the Redis cache to determine which Workspace groups should be synced with 1Password. If no Workspace groups are set in cache, the 1Password users will not be configured with any Workspace groups. Since the users are not configured with a Workspace group, they are deactivated.