[PR #1622] Modkit OoP requirments and draft design

[orivaris]

🔗 Mirrored PR cyberfabric/cyberware-rust#1622 | Author: MikeFalcon77 | Opened: 2026-04-26T20:32:42Z | Status: closed (not merged)
GitHub API does not allow setting PR author or timestamps — attribution preserved here.

---

---

[orivaris]

coderabbitai[bot] commented on 2026-04-26T20:33:05Z:

---

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 811b12db-c59b-4b1b-ba14-9012451d6234

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[orivaris]

codacy-production[bot] commented on 2026-04-26T20:34:32Z:

---

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[orivaris]

MikeFalcon77 commented on 2026-05-20T11:33:49Z:

---

Let's continue here: #3436

[orivaris]

nonameffh reviewed docs/arch/modkit/ADR/0002-cpt-cf-adr-auth-edge-only.md line 40 on 2026-05-11T20:13:29Z:

---

I cannot agree that internal transport must necessarily be considered secure - it depends on a security model. Furthermore, the current wording implies that any subsystem capable of establishing a TCP connection with the OoP module can issue an arbitrary SecurityContext (any subject_id, any tenant) without any restrictions, which could lead to privilege escalation.

[orivaris]

nonameffh reviewed docs/arch/modkit/ADR/0008-cpt-cf-adr-internal-module-auth.md line 48 on 2026-05-11T20:42:38Z:

---

I would suggest to extend profile-specific mechanisms by JWT authentication, service-to-service calls can be also done using JWT with specific subject type and id ("application","some-uuid") (this can be also covered by AuthZ resolver) for operators that don't want to support yet another authentication or mix of multiple authentication schemas (multiple K8s)

[orivaris]

nonameffh reviewed docs/arch/modkit/DESIGN.md line 585 on 2026-05-11T20:47:25Z:

---

The validation order is not specified: must the module first validate InternalCredential and then trust x-secctx-bin.

[orivaris]

nonameffh reviewed docs/arch/modkit/ADR/0007-cpt-cf-adr-eventual-readiness.md line 54 on 2026-05-11T20:53:07Z:

---

The enablement of these endpoints should be configurable. In our company probes, metrics and any other debugging endpoints live on a separate port that's not exposed through K8s Service resources.

[orivaris]

nonameffh reviewed docs/arch/modkit/ADR/0007-cpt-cf-adr-eventual-readiness.md line 58 on 2026-05-11T21:07:38Z:

---

This ADR covers only inital phase, what about readiness management for graceful shutdown (readiness→false before shutting down the service), dependency failures, graceful degradation? Readiness isn't a simple "all dependencies are up" - it should represent "this instance can really handle a request" (for example, DB connection alive, we're not in shutdown, Redis isn't alive but we can handle that according to the graceful degradation model -> we're ready to handle requests)

[orivaris]

nonameffh reviewed docs/arch/modkit/ADR/0007-cpt-cf-adr-eventual-readiness.md line 120 on 2026-05-11T21:11:07Z:

---

For startup gate we can use also K8s startupProbe

[orivaris]

nonameffh reviewed docs/arch/modkit/DESIGN.md line 322 on 2026-05-11T21:13:33Z:

---

How the drain order is organized, especially for the case when ModuleA depends on ModuleB and to properly drain in-flight jobs it needs ModuleB to be drained after ModuleA?

[orivaris]

striped-zebra-dev reviewed docs/arch/modkit/PRD.md line 232 on 2026-05-14T13:58:43Z:

---

How do we validate that a particular serialized security context is a derivative of a particular token?
We can discuss some solutions.
In any case that must be a security consideration.

[orivaris]

striped-zebra-dev reviewed docs/arch/modkit/PRD.md line 234 on 2026-05-14T14:01:38Z:

---

If attacker has a token (any token, like a user's one) it can create a fake security context (above the user level) pass both to the modkit_security::encode_bin and it will pass the validation.

[orivaris]

striped-zebra-dev reviewed docs/arch/modkit/PRD.md line 491 on 2026-05-14T14:27:21Z:

---

Sounds like DMZ

[orivaris]

striped-zebra-dev reviewed docs/arch/modkit/DESIGN.md line 306 on 2026-05-14T14:35:24Z:

---

Well-known case: https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot
It is quite common to register your own readiness check, for example your service needs some time to bootstrap from a remote source or build up some cache from the db before it can start serving traffic.

[orivaris]

striped-zebra-dev reviewed docs/arch/modkit/DESIGN.md line 415 on 2026-05-14T14:54:00Z:

---

I believe we could utilize Rust type system and avoid three &str params.

[orivaris]

striped-zebra-dev reviewed docs/arch/modkit/DESIGN.md line 441 on 2026-05-14T15:11:10Z:

---

I found it quite unexpected section, it is not really clear when we generate this client and how we use that.
All CyberWare modules bind by SDK usage, so it is not clear where those generated HTTP clients take place.

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/ADR/0002-cpt-cf-adr-auth-edge-only.md line 40 on 2026-05-20T11:01:54Z:

---

addressed in #3436

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/ADR/0008-cpt-cf-adr-internal-module-auth.md line 48 on 2026-05-20T11:02:18Z:

---

addressed in #3436

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/DESIGN.md line 585 on 2026-05-20T11:02:32Z:

---

addressed in #3436

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/ADR/0007-cpt-cf-adr-eventual-readiness.md line 54 on 2026-05-20T11:02:49Z:

---

addressed in #3436

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/ADR/0007-cpt-cf-adr-eventual-readiness.md line 58 on 2026-05-20T11:03:36Z:

---

addressed in #3436

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/ADR/0007-cpt-cf-adr-eventual-readiness.md line 120 on 2026-05-20T11:03:45Z:

---

addressed in #3436

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/DESIGN.md line 322 on 2026-05-20T11:03:54Z:

---

addressed in #3436

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/PRD.md line 232 on 2026-05-20T11:26:31Z:

---

Closed at the connection level via mTLS (ADR-0002 + ADR-0008): peer identity is validated during the TLS handshake before x-secctx-bin is even read from the socket. Any non-ModKit peer will fail at the handshake stage.

Inside the trust domain, for example a compromised ModKit module, additional protection is provided by subject_type AuthZ rules: an application: subject has a narrow scope, typically limited to directory.* system calls.

signed-secctx (HMAC over a shared secret or JWT-claim binding) is NOT implemented yet. This is a design decision for the next iteration. The current setup protects against external attackers via mTLS, but does NOT protect against a malicious module with a valid certificate.

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/PRD.md line 491 on 2026-05-20T11:28:25Z:

---

called it DMZ :)

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/PRD.md line 234 on 2026-05-20T11:30:41Z:

---

mTLS at the connection level (see ADR-0002/0008 update) - now any non-ModKit peer fails during the handshake. Plain TCP listeners are forbidden.

What is NOT covered yet and requires a separate design decision: signed/bound secctx. Options: (a) HMAC using a secret from Flight Control, (b) JWT-claim binding to the bearer token, (c) relying on mTLS as the primary defense and explicitly narrowing the threat model.

This is a PRD-level security choice, so I’m moving it into a separate PR instead of patching it ad hoc here.

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/DESIGN.md line 306 on 2026-05-20T11:31:16Z:

---

I've extended this ADR

[orivaris]

MikeFalcon77 reviewed docs/arch/modkit/DESIGN.md line 441 on 2026-05-20T11:33:02Z:

---

It will be covered by another design (modkit contracts)
See: #3437