Skip to content

12. Authentication & Secrets Constitution

Authenticate once. Execute everywhere.

Purpose

Bluefly delegates authentication and secret management to 1Password. Bluefly governs authorization, secret references, naming, policy, and runtime authorization. Bluefly must never recreate capabilities already provided by 1Password.

Authentication is infrastructure. Authorization is business.

Prime Directive

Authenticate once. Reuse the authenticated session. Reference secrets directly. Never copy secrets.

If authentication becomes repetitive, the architecture is wrong. Stop and fix the architecture.

Authority Model

Responsibility Authority
User authentication 1Password
Machine authentication 1Password
Secret storage 1Password
Secret rotation 1Password
Secret audit 1Password
Secret delivery 1Password
Authorization Bluefly
Secret references Bluefly
Naming standards Bluefly
Policy Bluefly

Bluefly decides who may use a secret. 1Password decides how the secret is authenticated and delivered.

Canonical Authentication Methods

Developer workstations

Developers authenticate interactively once using the official 1Password application and CLI; subsequent commands reuse the authenticated session. Applications retrieve secrets using secret references:

op whoami
op read "op://BlueflyAgents/<item>/token"

No additional authentication layer is permitted.

CI/CD

CI systems authenticate using 1Password Service Accounts. No interactive login, no copied credentials, no .env generation, no custom secret wrappers. CI retrieves secrets directly from 1Password via the official integrations or CLI. Secrets exist only for the lifetime of the executing job. Pipelines never persist secrets into repositories or generated files.

Runtime infrastructure (Oracle and long-lived services)

Applications authenticate using 1Password Connect: a private REST API inside the infrastructure that caches secrets locally while preserving centralized management. Applications consume secrets through Connect SDKs or the Connect REST API. Applications do not invoke the CLI. Oracle owns runtime; Oracle never becomes a secondary secret store.

Kubernetes

Kubernetes uses the official 1Password integrations only: Connect, the Kubernetes Injector, the Kubernetes Operator, and Helm charts. Never invent a custom synchronization mechanism; never duplicate Kubernetes Secret management already provided by 1Password. Bluefly owns deployment policy; 1Password owns secret delivery.

Session Model

Before executing authenticated work: op whoami. If a secret is required: op read op://BlueflyAgents/<vault>/<item>/<field>. Only launch a new authentication boundary when starting a new process: op run -- <command>. op run creates a process environment — it is not a wrapper around every command.

Secret Rules

Configuration contains references, never values.

Allowed: op://… references · 1Password SDK · Connect SDK · Connect REST API · Service Accounts · op read · op run (new process boundaries only).

Forbidden: .env files containing secrets · .op-env · secret synchronization · secret duplication · secret caching · exporting long-lived secrets · committed credentials · personal API key files · custom authentication brokers · copying secrets into configuration · op run --no-masking / OP_RUN_NO_MASKING · token inspection or printing · secret discovery by agents.

Runtime Rules

Runtime configuration contains references only:

gitlab:
  token: op://<vault>/GitLab/token   # never a plaintext PAT value

SDK Usage

SDKs (Go, JavaScript, Python) are allowed only inside Bluefly-owned applications that genuinely need programmatic access. SDKs may resolve approved references, validate presence, and read metadata. SDKs may not print secrets, return secrets to LLMs, expose secrets through APIs, log secret values, or implement a custom broker.

Agent Contract

Agents may: verify authentication · verify secret references · validate required configuration · report missing permissions.

Agents may not: enumerate vaults · print secrets · cache secrets · export secrets · create .env · create .op-env · synchronize secrets · wrap every command with op run · request users paste credentials · build alternative authentication systems.

Failure Rule

If any workflow requires repeated op run, repeated sign-in, repeated biometric approval, .env generation, .op-env, copying secrets, caching secrets, synchronizing secrets, custom authentication wrappers, or exporting long-lived environment variables — the architecture is broken. Stop. Fix the architecture. Do not automate around the problem.

Constitutional Invariants

  1. Authenticate once.
  2. Reuse authenticated sessions.
  3. Secrets remain inside 1Password.
  4. Configurations contain references, not values.
  5. Applications authenticate through official 1Password mechanisms.
  6. Bluefly governs authorization, never authentication.
  7. Never duplicate functionality already owned by 1Password.
  8. Prefer references over copies.
  9. Prefer official integrations over custom code.
  10. If authentication becomes repetitive, redesign the architecture.

Guiding Principle

Authenticate once. Reference secrets. Reuse the authenticated session. Deploy through official 1Password integrations. 1Password authenticates. Bluefly authorizes. Bluefly executes.

Upstream References