204 lines
4.3 KiB
Markdown
204 lines
4.3 KiB
Markdown
Short answer: **yes, you *can* use SOPS offline — and yes, it actually fits your model well — but only in a very specific role.**
|
||
It should be a **transport + hygiene container**, *not* a trust anchor or semantic authority.
|
||
|
||
Below is the precise guidance, aligned with your architecture.
|
||
|
||
---
|
||
|
||
## 1. What SOPS is good at (in *your* system)
|
||
|
||
SOPS excels at:
|
||
|
||
* Encrypting small structured payloads (YAML / JSON / binary blobs)
|
||
* Using **offline keys** (age, PGP)
|
||
* Providing tamper-evidence during transport
|
||
* Being human-operable on an air-gapped Debian machine
|
||
|
||
That maps nicely to:
|
||
|
||
> **“Move sensitive authority material safely from the offline signer to the online ASL domain.”**
|
||
|
||
---
|
||
|
||
## 2. What SOPS must *not* be used for
|
||
|
||
SOPS must **not** be used as:
|
||
|
||
* A trust model
|
||
* A certification system
|
||
* An authority definition
|
||
* A replacement for DAM / certificates
|
||
* A verifier of correctness
|
||
|
||
In your system:
|
||
|
||
* **Signatures establish truth**
|
||
* **SOPS only protects envelopes**
|
||
|
||
This distinction is critical.
|
||
|
||
---
|
||
|
||
## 3. Correct placement of SOPS in the stack
|
||
|
||
Think of SOPS as living **outside** ASL semantics:
|
||
|
||
```
|
||
[ Offline Debian ORA ]
|
||
|
|
||
| (SOPS-encrypted container)
|
||
v
|
||
[ Transport medium: USB / SCP / email ]
|
||
|
|
||
v
|
||
[ Online ASL node ]
|
||
|
|
||
| (decrypt)
|
||
v
|
||
[ ASL artifact import + signature verification ]
|
||
```
|
||
|
||
Once decrypted:
|
||
|
||
* SOPS is **discarded**
|
||
* Only hashes + signatures matter
|
||
|
||
---
|
||
|
||
## 4. What should go *inside* SOPS containers
|
||
|
||
### Good candidates ✅
|
||
|
||
* AuthorityCertificate artifacts (binary or canonical form)
|
||
* DAM source manifests (pre-hash)
|
||
* Policy documents (pre-hash)
|
||
* Key material *temporarily* (if absolutely required)
|
||
* Signing requests awaiting approval
|
||
|
||
### Bad candidates ❌
|
||
|
||
* ASL blocks
|
||
* Snapshots
|
||
* PERs
|
||
* TGK edges
|
||
* Anything whose *meaning* depends on encryption
|
||
|
||
---
|
||
|
||
## 5. Recommended SOPS payload structure
|
||
|
||
Use SOPS as a **sealed courier envelope**:
|
||
|
||
```yaml
|
||
kind: asl-authority-envelope
|
||
version: 1
|
||
|
||
payload:
|
||
type: authority-certificate
|
||
domain_id: example.org/build
|
||
policy_hash: sha256:...
|
||
artifact_bytes: |
|
||
BASE64(AuthorityCertificate canonical bytes)
|
||
|
||
metadata:
|
||
issued_by: offline-root
|
||
comment: "Initial domain bootstrap"
|
||
```
|
||
|
||
* Encrypt with **age** (simplest, modern, offline-friendly)
|
||
* No need for KMS
|
||
* No need for cloud hooks
|
||
|
||
---
|
||
|
||
## 6. Canonical rule (important)
|
||
|
||
> **The SOPS container is never hashed, never signed, and never referenced by ASL.**
|
||
|
||
Only the **decrypted payload bytes** are:
|
||
|
||
* Hashed
|
||
* Signed
|
||
* Stored as artifacts
|
||
* Snapshot-pinned
|
||
* Federated
|
||
|
||
This preserves determinism.
|
||
|
||
---
|
||
|
||
## 7. Offline Debian workflow (clean and safe)
|
||
|
||
### On offline machine
|
||
|
||
1. Generate or review authority material
|
||
2. Produce canonical bytes
|
||
3. Sign with root key
|
||
4. Place result in SOPS envelope
|
||
5. Encrypt with age recipients
|
||
6. Export file
|
||
|
||
### On online machine
|
||
|
||
1. Decrypt SOPS envelope
|
||
2. Verify signature
|
||
3. Hash payload
|
||
4. Import as ASL artifact
|
||
5. Reference from DAM / snapshot
|
||
6. Forget SOPS ever existed
|
||
|
||
---
|
||
|
||
## 8. Why SOPS is a *good* fit here
|
||
|
||
| Requirement | SOPS |
|
||
| ---------------------- | ----------------- |
|
||
| Offline | ✔ |
|
||
| Human-auditable | ✔ |
|
||
| Minimal tooling | ✔ |
|
||
| Deterministic payloads | ✔ (after decrypt) |
|
||
| Transport security | ✔ |
|
||
| Authority semantics | ✘ (by design) |
|
||
|
||
That last line is a **feature**, not a bug.
|
||
|
||
---
|
||
|
||
## 9. Alternative (why you probably don’t need more)
|
||
|
||
You *don’t* need:
|
||
|
||
* Vault
|
||
* HSM integration
|
||
* X.509
|
||
* TPM attestation
|
||
* Live secret management
|
||
|
||
Because your **authority is historical and snapshot-bound**, not session-based.
|
||
|
||
---
|
||
|
||
## 10. Final recommendation (clear and direct)
|
||
|
||
✔ **Yes, use SOPS offline**
|
||
✔ Use it as a **sealed delivery container**
|
||
✔ Keep **all meaning outside** SOPS
|
||
✘ Do not let SOPS define trust
|
||
✘ Do not hash or sign SOPS files
|
||
|
||
---
|
||
|
||
## One-sentence takeaway
|
||
|
||
> **SOPS is an excellent armored courier for authority artifacts — but the moment it defines meaning or trust, it’s being misused.**
|
||
|
||
If you want next, we can:
|
||
|
||
* Define an exact **age key strategy** for ORA
|
||
* Specify **how many offline roots to trust**
|
||
* Model **temporary rescue-node authority via SOPS**
|
||
* Show a **bootstrap-from-zero ceremony**
|
||
|
||
Just say where to go next.
|
||
|