Forum Discussion

reremaru's avatar
reremaru
New Contributor
1 hour ago

AWS Secrets Manager integration: destination won't persist, zero API calls reaching AWS

Hi all,

 

Looking for help / similar reports on the AWS Secrets Manager

(Environments) integration. Our sync has completely stopped working and

re-creating the integration does not bring it back. A support ticket is

already filed; posting here in case anyone has hit the same and found a

faster fix.

 

## Symptoms

 

- Changes in 1Password Environments (additions, edits, deletions of any

variable) do **not** propagate to AWS Secrets Manager.

- The integration card in the 1Password UI stays in the unconfigured

"Configure destination" state. There is no "connected" / "ready"

indicator, just the configuration prompt.

- This affects **all environments** simultaneously, not just one.

- The "Configure destination" save action visually succeeds with no

error, but immediately reverts the screen back to the unset

"Configure destination" state. Re-entering and saving multiple times

produces the same revert. The destination is never persisted.

- Recreating the integration (deleting and setting it up again, even

with a brand new target secret name) does not restore sync. The new

target secret is also never written to.

- This was working previously; the last successful sync (visible in AWS

as the secret's `LastChangedDate`) was 25 days before the issue began,

and the freeze started without any change on our side.

 

## Environment

 

- 1Password plan: Individual

- 1Password Desktop App: 8.12.12 (Windows, latest)

- AWS region: us-east-1

 

## What we've verified on the AWS side

 

- AWS CloudTrail (`lookup-events` filtered by the target secret's

resource name) shows **zero `UpdateSecret` / `PutSecretValue` events**

in the past 24 hours from any principal — i.e., 1Password is not even

attempting an API call. There is no AccessDenied / ThrottlingException

either, just no request reaching AWS.

- IAM role / SAML provider used by the integration still exists with

unchanged trust policy and `secretsmanager:*` permissions on the target.

- KMS key is intact, no SCP changes in the org.

- Other AWS-bound integrations from our account work normally.

 

## Parallel fresh integration test

 

To rule out integration-specific corruption, we set up a completely new

parallel integration without deleting the existing one:

 

- New 1Password Environment (different name)

- New SAML Identity Provider in AWS (different name)

- New IAM Policy in AWS (different name, scoped to a new secret name

pattern)

- New IAM Role in AWS (different name, with `SAML:sub` trust condition

matching the SAML subject value provided in the 1Password

configuration page)

- New target secret name in 1Password's destination config

 

Result: **identical failure mode**.

 

- Clicking "Create integration" reverts the destination to unset, no

error shown. The integration card never moves out of the unconfigured

state.

- AWS CloudShell verification: zero matching secrets created, zero

`CreateSecret` events recorded across the entire account in the time

window of the parallel save attempts.

- A sanity-check `describe-secret` call against an unrelated existing

secret returns successfully, confirming our AWS CLI access is

functional.

 

This pattern (no API call at all, save action not persisted, parallel

fresh integration also broken) suggests an account-level issue on the

1Password side — possibly invalidated integration credentials, a stuck

sync worker, or a silent server-side validation failure preventing the

destination from being persisted. We can't diagnose further from the

AWS side.

 

## Questions

 

1. Has anyone else seen this — silent sync stop affecting all

environments simultaneously, with the save action visibly succeeding

but the destination never persisting?

2. Is there a way (CLI / SDK / admin console) to check the integration's

internal sync status / last-attempted-sync timestamp / error log on

the 1Password side?

3. Any way to force-trigger a sync attempt from outside the standard

"save in environment" path? Save-and-edit no longer triggers anything

reaching AWS.

 

We have already filed a support ticket. Posting here in case anyone has

hit the same and found a fix faster than support turnaround.

 

Thanks!

 

No RepliesBe the first to reply