Bernd RodlerandClaude Opus 5
759ab7fe8c
Manifests and a runbook for the internal CA that issues 1-year S/MIME certificates. Per the agreed split: these are applied by hand, and the root-key ceremony in section 3 is deliberately NOT automated - the whole value of an offline root is that its private key never exists on a machine that runs services or tooling. Structural recommendation up front (section 0), because it decides whether promoting to vncmail later is a config change or a re-rooting: name the root for the ORGANISATION, not the environment. One root, generated once at prod grade, with per-environment intermediates under it. Promotion is then "issue a second intermediate from the same root" - a one-hour ceremony - and the trust anchor already distributed to laptops, phones and partners does not change. A throwaway "VNC Sandbox Root" instead means redistributing a new anchor to every device and every external party who ever verified a signature. That cost is invisible today and expensive later. Security shape of the deployment: - Own namespace (vnc-ca), NOT vncmail. The webmail pod is internet-facing; the CA signs certificates. A compromise of the former must not be a compromise of the latter. - Port 8080 (CRL + OCSP) is the ONLY thing the public ingress routes, and only two path prefixes. Not the admin web, not the REST API, not the public enrolment pages. - Port 8443 (admin + REST, client-cert authenticated) is never exposed through an ingress - cluster-internal or kubectl port-forward only, enforced by NetworkPolicy as defence in depth. - The RA credential the enrolment route uses gets its own EJBCA role limited to issue/revoke under one profile. It lives on an internet-facing pod, so its blast radius should be "mint an S/MIME cert" and not "reconfigure the CA". Two things the runbook makes you prove rather than assume: - The NetworkPolicy actually enforces. Applying one on a CNI that does not implement it succeeds silently and protects nothing, so section 6 has a probe that MUST time out - a 401 means the REST API is exposed cluster-wide. - The CA backup restores. ejbca-db-data holds the intermediate private key and, with key recovery on, escrowed user decryption keys; an untested CA backup is a belief. Section 7 surfaces a decision rather than making it silently. S/MIME is unlike TLS in that losing a private key makes every message ever encrypted to that user permanently unreadable - re-issuing does not help, the old mail was encrypted to the old key. So key escrow is on by default here, which is the defensible choice when mail is a business record, but it means the CA operator can decrypt user mail. That is worth deciding consciously and being able to explain, not discovering. MariaDB rather than the container's embedded H2 deliberately: H2 is not supported for data you intend to keep, and the database is the one component that must not need re-platforming on promotion. Image tag pinned. The env-var contract is the part most likely to have drifted between EJBCA releases, so the runbook says to verify it against the tag pulled rather than trusting these values, and gives the log grep that shows the failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
83 lines
2.3 KiB
YAML
83 lines
2.3 KiB
YAML
# Default-deny ingress for the CA namespace, then three narrow allowances.
|
|
#
|
|
# Without this, the REST API on 8443 is reachable from every pod in the cluster.
|
|
# It is still client-cert authenticated, so this is defence in depth rather than
|
|
# the only control — but "the only thing standing between any compromised pod and
|
|
# a certificate factory is one TLS handshake" is not a position to be in.
|
|
#
|
|
# PREREQUISITE: microk8s needs a CNI that enforces NetworkPolicy. The default
|
|
# (Calico) does. If you are on flannel without a policy plugin these objects
|
|
# apply cleanly and silently enforce NOTHING — verify with the test in
|
|
# README.md § Verify the network policy rather than assuming.
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: NetworkPolicy
|
|
metadata:
|
|
name: default-deny-ingress
|
|
namespace: vnc-ca
|
|
spec:
|
|
podSelector: {}
|
|
policyTypes: [Ingress]
|
|
---
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: NetworkPolicy
|
|
metadata:
|
|
name: allow-public-web-from-ingress
|
|
namespace: vnc-ca
|
|
spec:
|
|
podSelector:
|
|
matchLabels:
|
|
app: ejbca
|
|
policyTypes: [Ingress]
|
|
ingress:
|
|
# Port 8080 (CRL/OCSP) from the ingress controller only.
|
|
# VERIFY THE NAMESPACE: microk8s' nginx addon has historically used
|
|
# `ingress`, `kube-system`, and `ingress-nginx` depending on version.
|
|
# kubectl get pods -A | grep -i ingress
|
|
- from:
|
|
- namespaceSelector:
|
|
matchLabels:
|
|
kubernetes.io/metadata.name: ingress
|
|
ports:
|
|
- port: 8080
|
|
protocol: TCP
|
|
---
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: NetworkPolicy
|
|
metadata:
|
|
name: allow-rest-from-vncmail
|
|
namespace: vnc-ca
|
|
spec:
|
|
podSelector:
|
|
matchLabels:
|
|
app: ejbca
|
|
policyTypes: [Ingress]
|
|
ingress:
|
|
# Port 8443 (REST API) from the webmail namespace only. This is the
|
|
# enrolment route calling the CA with its RA client certificate.
|
|
- from:
|
|
- namespaceSelector:
|
|
matchLabels:
|
|
kubernetes.io/metadata.name: vncmail
|
|
ports:
|
|
- port: 8443
|
|
protocol: TCP
|
|
---
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: NetworkPolicy
|
|
metadata:
|
|
name: allow-db-from-ejbca
|
|
namespace: vnc-ca
|
|
spec:
|
|
podSelector:
|
|
matchLabels:
|
|
app: ejbca-db
|
|
policyTypes: [Ingress]
|
|
ingress:
|
|
- from:
|
|
- podSelector:
|
|
matchLabels:
|
|
app: ejbca
|
|
ports:
|
|
- port: 3306
|
|
protocol: TCP
|