73 lines
4.3 KiB
Markdown
73 lines
4.3 KiB
Markdown
# Inactive SOPS/age preparation, 2026-10-30
|
|
|
|
The owner selected SOPS, age and sops-nix. This directory is a template, not a
|
|
host configuration. The development flake remains unchanged. No real recipient,
|
|
key, encrypted secret or server user is supplied. No module is deployed.
|
|
|
|
Official references inspected for this pass:
|
|
- [SOPS documentation](https://getsops.io/docs/)
|
|
- [sops-nix installation and secret permissions](https://github.com/Mic92/sops-nix)
|
|
|
|
SOPS encrypts configuration at rest. sops-nix can supply decrypted values at
|
|
runtime under `/run/secrets` with explicit owners and modes. This does not make
|
|
browser ciphertext or publicly served documents private.
|
|
|
|
## Owner setup before activation
|
|
|
|
1. Supply the actual NixOS topology, host flake, deploy user, persisted key
|
|
location, backup owner, HTTPS termination and resource-service identity.
|
|
2. Pin a reviewed `github:Mic92/sops-nix` input in that host flake; import
|
|
`inputs.sops-nix.nixosModules.sops` and the reviewed template. Do not add the
|
|
input to the Astro development flake just to evaluate a deployment sketch.
|
|
3. The owner generates independent developer/recovery and VPS age identities in
|
|
private terminals. Record only public recipients in the reviewed SOPS
|
|
creation rule. Use distinct recipients, never a placeholder recipient. Keep
|
|
the VPS private identity on persistent root-controlled storage (0600), outside
|
|
`/nix/store`, Git, the public static root and CI artifacts.
|
|
4. Encrypt the approved credential material using SOPS with both recipients.
|
|
Review recipient access, least privilege and an offline recovery copy. SOPS
|
|
encrypted files may enter a deployment repository only after owner approval.
|
|
5. Set `aia.portalSecrets` options explicitly, then evaluate the complete host
|
|
configuration and test decryption on authorized nonproduction infrastructure.
|
|
Runtime consumers use the generated `.path`, not Nix evaluation of plaintext.
|
|
6. Decide which service reloads after rotation. Rotate application credentials
|
|
as well as SOPS recipients when revoking access: rewrapping alone does not
|
|
invalidate an already copied password. Test recovery and key restoration.
|
|
|
|
## Separate staff and management resource authorization
|
|
|
|
Keep original documents outside Astro `public`, `dist`, release archives and
|
|
CDN roots. Proposed delivery namespaces are `/staff-resources/` and
|
|
`/management-resources/`; neither is implemented or considered working here.
|
|
Use nginx `auth_request` to an approved authorization service or an equivalent
|
|
server-enforced policy with individually revocable identities and staff and
|
|
management roles. Staff credentials must not authorize management resources;
|
|
management access to staff resources must be an explicit policy. Backend file
|
|
locations must be internal, inaccessible through static aliases or alternate
|
|
paths. Never trust a browser-provided role header.
|
|
|
|
A separate shared Basic Auth credential file per namespace can be considered
|
|
only as an explicitly approved weaker interim model, not identity management or
|
|
automatic role inheritance. The template prepares separate secret inputs without
|
|
selecting that access model or installing an identity provider.
|
|
|
|
Use HTTPS, `Cache-Control: private, no-store`, no shared/CDN caching, and
|
|
`Referrer-Policy: no-referrer` for protected delivery. Avoid credentials and
|
|
sensitive resource paths in access/error logs; review monitoring and backups.
|
|
Authorization failures must fail closed, including at proxy/cache boundaries.
|
|
Test direct requests, alternate encodings, role crossover and rollback.
|
|
|
|
## Distinct boundaries and release checks
|
|
|
|
- SOPS: deployment secrets at rest and controlled runtime access.
|
|
- Portal HTML: shared-code browser decryption, offline-guessable access friction.
|
|
- Documents: require server authorization even if URLs are encrypted in the UI.
|
|
|
|
The compatibility preview cannot grant production portal access. Before cutover,
|
|
classify every document, implement and verify its delivery destination, rewrite
|
|
and re-encrypt links, test two-view separation, rotate shared codes privately,
|
|
check the public artifact for private files, and obtain owner/security approval.
|
|
Back up encrypted configuration and documents separately from keys; rehearse
|
|
restore and rollback. Revoking a static release cannot retract ciphertext or
|
|
files already downloaded by visitors. Site cutover is still unauthorized.
|