ERS 1Password Secrets Architecture and Bootstrap Plan - RodrigoMattosoSilveira/EnterpriseRemoteSystems GitHub Wiki


ERS 1Password Secrets Architecture and Bootstrap Plan

1. Architecture decision

ERS will use 1Password Teams Starter Pack as the authoritative managed source for application, deployment, infrastructure, and recovery secrets.

The architecture will follow four rules:

1Password is authoritative for secrets. Git is authoritative for non-secret configuration.

The deployed files:

.env.development
.env.test
.env.production
/opt/EnterpriseRemoteSystems/secrets/aws-credentials

remain supported runtime artifacts because the existing ERS deployment, backup, migration, restore, and recovery tooling consumes them. They will eventually be generated/materialized from Git templates plus 1Password secrets, rather than being authoritative copies themselves.

1Password will not be an ERS runtime dependency.

A running ERS instance will not call 1Password on normal API requests, backups, migrations, or restores. A 1Password outage therefore will not stop an already-running ERS service.

1Password will be required when secrets must be materialized or recovered, principally during deployment, configuration changes, and owner-unavailable disaster recovery.

Human operators use individual 1Password accounts. Machines use scoped Service Accounts.

There will be no shared human 1Password login.

The initial design will use stable 1Password vaults and secret references, not the current Beta Environments runtime path.

1Password officially recommends Service Accounts for least-privilege automated access and supports restricting a Service Account to selected vaults.

2. Human account topology

Initially:

ERS person | 1Password role | Purpose -- | -- | -- SWE #1 / Rodrigo | Owner | Normal engineering + account recovery SWE #2 | Owner | Normal engineering + owner-unavailable recovery SWE #3, when hired | Team Member initially | Engineering; Owner only if operationally justified

32. Acceptance standard before changing the runbook

We should not call the 1Password architecture established until all of these are true:

Two independent Owners exist.
Both can sign in without the other.
Both have offline Emergency Kits.
Both have independent MFA.
All six vaults exist.
Both Owners can access the recovery-critical vaults.
Production runtime secrets have been copied to ers-production.
Hetzner S3 credentials have been copied to ers-production.
Deployment SSH is recoverable from ers-deployment.
SWE #2 has independent GitHub access.
SWE #2 has independent Hetzner access.
SWE #2 has independent DNS access.
Three least-privilege Service Accounts exist.
Their tokens are safely retained in ers-automation-bootstrap.
Each GitHub Environment contains only its matching OP_SERVICE_ACCOUNT_TOKEN.
Existing GitHub deployment secrets remain intact until migration validation.

Only then should we modify Bite 33.6.

⚠️ **GitHub.com Fallback** ⚠️