Security, access control & governance¶
Who may do what, and the evidence that they did it.
Authentication, authorization, dual control, tenancy and abuse protection, plus the tamper-evident audit log that records the outcome of every privileged operation and the export path that ships it to a SIEM.
| Guide | Covers |
|---|---|
| RBAC, audit logging & config | Organization-wide roles, per-CA permissions, the hash-chained event log, and centralized policy/profiles |
| Per-CA & per-key authorization (resource grants) | Authorizing users and groups on one individually-addressed CA or signing key, so a platform administrator can keep the root CA while a specific group administers a single subordinate: the ca-admin/ca-manager/ca-issuer/ca-auditor and key-admin/key-signer/key-auditor roles, self vs subtree scope, declarative rbac.grants config plus the /api/grants API, secsy-ca grant CLI and console Access page, effective-access review, and the resource.grant/resource.revoke audit trail |
| Operator authentication (SSO, mTLS, WebAuthn) | Strong console/API authentication: interactive OIDC/OAuth2 login with claim/group → RBAC role mapping, mutual-TLS client-cert binding for machine callers, WebAuthn/passkey step-up for high-risk operations, plus sessions, CSRF, and login/step-up audit + metrics |
| Role-mapping expressions (CEL) | Mapping an IdP's group names to RBAC roles when the names encode structure: CEL expression / tenant_expression on any role_mappings list, the identity variables and the function library (startsWith/endsWith/matches, regex.replace/regex.extract, sets and lists), deriving one or several tenant ids out of a group name, the fail-closed rules (compile at startup, cost-bounded evaluation, an empty tenant grants nothing, a derived id must name a declared tenant), and the secsy-ca role-mapping list/test/reference dry-run |
| Four-eyes / maker-checker approvals | Holding high-risk operations for distinct-approver sign-off: the guarded classes (CA create/rotate/retire, bulk revocation, KEK rotation) and the per-profile manual issuance gate (require_approval → cert.issue) — park on 202, approve, then fetch the certificate; the approver role & self-approval denial, secsy-ca approvals + /api/approvals/{id}/certificate + console, why ACME/EST/SCEP/CMP always bypass the gate, and the cert.issue.* audit events/metrics |
| Multi-tenant isolation | Serving several isolated organizations from one deployment: per-tenant CAs, profiles, revocation/CRL state, secret envelopes, RBAC (platform vs. tenant roles), and a tenant-scoped audit trail; cross-tenant access is denied |
| Rate limiting & abuse protection | Tiered token-bucket rate limiting (global / per-IP / per-account) and a bounded in-flight HSM concurrency guard for the public ACME/OCSP/CRL/SCEP/EST endpoints, with 429/503 + Retry-After and Prometheus throttle/queue metrics |
| Audit log export to SIEM | Streaming the audit event log to syslog (TCP/TLS)/CEF/webhook with at-least-once delivery & a durable cursor, plus secsy-ca audit verify (tamper detection) and audit export (offline batch) |
| Credentials from files, not from the config | Keeping every password out of config.yaml: the uniform <key>_file convention (root_user.password_file, yubihsm.password_file, pkcs11.pin_file, database.dsn_file, …), the fail-closed 0600 invariant and the security.allow_insecure_secret_file_perms escape hatch container runtimes need, the SECSY_*_FILE environment forms and their precedence, what a redacted config dump shows, and worked Kubernetes/Compose examples |
| FIPS 140-3 mode | Running as a FIPS-capable PKI: the make build-fips/GOFIPS140 build on the Go Cryptographic Module (verified at build time, reported by -version, the startup log, and /healthz build info), the fail-closed security.fips algorithm policy (no Ed25519 leaves, no SHA-1 anywhere, no RSA<2048, no software-PQC paths — enforced at config load, key generation, and issuance), the SoftHSM SHA-1-OAEP refusal + KEK re-wrap migration, the fips.* doctor checks, and the module-boundary-vs-HSM-validation scope |
| Security review & hardening | The security review of the main branch: findings, fixes, residual risks, and how to re-verify |
↩ Back to the documentation map · project README