Define an explicit Zero-Trust Architecture maturity tier consolidating TLS, identity, mesh, and network-policy work

Closed
  • Is something wrong?
#778 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
kubernetes, python
Domain
documentation, security

Research direction

Start with docs/haven-parity-plan.md sections 3.7 and 9, docs/roadmap.md, and the referenced issues for TLS, identity, NetworkPolicy, service mesh, audit logging, and pod hardening. Map the existing work to NIST SP 800-207, identify any genuine gaps as separate follow-up issues, and add the requested cross-links. Done means the new ZTA document and all specified links are in place, with the maturity-tier framing aligned to the mapping.

Written by the indexing model from the issue text.

Description

area:docs area:security documentation priority:medium size:small

Problem statement

CDS already has, or has scoped, every individual building block of a Zero-Trust Architecture (ZTA) — TLS/cert-management contracts (#205/#577/#579/#580), an identity/OIDC-broker module (#370), Kubernetes NetworkPolicy generation (#75), pod/container hardening (cli/k8s_security.py, PR #608), and now a service-mesh contract (#776) — but nowhere is this framed or tracked as a coherent Zero-Trust story. docs/haven-parity-plan.md's maturity model (workstream 3.7, tracked by #769) already implies a "Secured" tier (TLS + service-mesh + identity-broker bound) but does not use Zero-Trust terminology or cite the explicit ZTA principles (NIST SP 800-207: verify explicitly, least-privilege access, assume breach) a reader/auditor would expect.

Proposed solution

  • Add docs/zero-trust-architecture.md mapping CDS's existing and in-flight contracts/rules to NIST SP 800-207's core tenets: every session/request authenticated and authorized (identity-broker #370 + auth enforcement #206), micro-segmentation (NetworkPolicy #75, service-mesh #776), encrypted transport everywhere (TLS #205/#577/#579/#580), continuous verification/logging (log-sink, #737's audit trail), least-privilege runtime (cli/k8s_security.py pod hardening).
  • Identify what, if anything, is still a genuine gap once the mapping is done (e.g. explicit deny-by-default default NetworkPolicy, workload identity/SPIFFE-style attestation) and file focused follow-ups rather than solving them inline here.
  • Feed the "Secured" tier definition in cds maturity (#769) from this mapping, so the CLI's own tier naming matches the documented ZTA framing instead of being defined independently.

Acceptance criteria

  • docs/zero-trust-architecture.md published, citing NIST SP 800-207 and cross-linking every contributing issue listed above.
  • Any newly identified gap is filed as its own issue, not bundled into this one.
  • docs/haven-parity-plan.md section 3.7 (maturity model) and section 9 (Dutch public-sector alignment) cross-link to this doc.
  • docs/roadmap.md links the new doc from the Kubernetes platform baseline entry.

References

Estimated effort: 2-3 hours (design and docs)

Dominant language
Python
Stars
8
Forks
12
Avg merge
12h 57m
Merged PRs (30d)
190

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from RonaldHensbergen/composable-data-stack

All issues in RonaldHensbergen/composable-data-stack

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.