operator: hardening follow-ups from the #429 security review
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Read the #429 security review, the operator config docs and code section list, operations.md, chart defaults, and deploy manifests. Trace renewal state in the identity Secret and the signer response path, then inspect the invite enrollment flow. The issue lists the expected behavior for each follow-up; completion means implementing those changes and adding suitable coverage across the affected operator and deployment areas.
Written by the indexing model from the issue text.
Description
Follow-up hardening from the security review of #429. None of these weakens a trust check that existed before #429, and each is Low or below. #429 itself takes the RBAC narrowing, the full identity check for a site with no signer, and the cert-manager renewal evidence.
Renewal can stop through a config edit
Anyone who can edit the operator config can stop renewal. They can set rotation Disabled, remove signerEndpoint, change site.name, or delete the ConfigMap. Each shows on RotationOnSchedule or Accepted, and a deleted ConfigMap logs at info only. The site then fails when its certificate expires.
- Emit a Warning Event when an identity that was renewing loses its signer.
- Document an alert on the existing site identity expiry gauge.
- State in operations.md that write access to the operator config controls renewal.
An older operator ignores a newer config section
An older operator ignores an unknown top-level section and applies the rest, with a Warning Event and a metric. That is correct for most sections. A section whose absence weakens security, such as a future trust or membership section, must bump version instead, because the operator refuses an unknown version. Write that rule into the operator config docs and next to the section list in the code.
The signer host allowlist fails open
GRID_SIGNER_HOSTS unset admits any host. The operator warns at startup, and the chart derives the allowlist from enrollment.url, but the deploy manifests set nothing. A bare host in the list also admits any port. TLS verification still bounds the impact: no token or key leaves without a verified signer.
- Render host:port in the chart default.
- Set GRID_SIGNER_HOSTS in the deploy manifests, or document it.
- Consider refusing to start when the config names a signerEndpoint and the allowlist is unset.
A stale pending renewal key is not tied to its certificate
Renewal stores a pending key and CSR in the identity Secret before it sends. If something outside the operator replaces the certificate and key but leaves the pending fields, the next renewal sends the old pending CSR. Store the fingerprint of the certificate the pending key belongs to, and discard pending fields whose fingerprint does not match.
Signer error text reaches a condition message
Error details from the signer's response body can land in a condition message. Bound the text and reduce it to the status code and a short reason.
Spent invite Secret
The site's invite Secret is never deleted after enrollment. The signer has already spent the token, so this is hygiene: delete the Secret or mark it spent once the operator stores the identity.
- Dominant language
- Rust
- Stars
- 10
- Forks
- 24
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 138
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from praxis-proxy/grid
-
bug priority/high triage/accepted
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
praxis-proxy/grid#412 ·
Maintainers usually reply within 1 day
-
docs(gateway): memory sizing for prefix affinity capacityPossibly taken @valeriiashapoval claimed this 4 days ago. Opengood first issue priority/low triage/accepted
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
praxis-proxy/grid#406 · 1 assignee ·
Maintainers usually reply within 1 day
-
priority/low triage/accepted
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
praxis-proxy/grid#200 ·
Maintainers usually reply within 1 day
-
triage/needs-triage
Difficulty 3/5 1-2 days Newbie friendliness 68/100
praxis-proxy/grid#454 ·
Maintainers usually reply within 1 day
-
triage/needs-triage
Difficulty 4/5 3-5 days Newbie friendliness 35/100
praxis-proxy/grid#448 ·
Maintainers usually reply within 1 day
All issues in praxis-proxy/grid
Similar issues
-
desktop documentation
Difficulty 1/5 Under an hour Newbie friendliness 90/100
vfarcic/dot-agent-deck#2008 ·
Maintainers usually reply within 1 day
-
needs triage
Difficulty 1/5 Under an hour Newbie friendliness 85/100
pbakaus/impeccable#1210 ·
Maintainers usually reply within 1 day
-
area: ci priority: P4 ready-for-agent
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
shep-pm/shep#1249 · 1 comment ·
Maintainers usually reply within 1 day
-
L: javascript
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
dependabot/dependabot-core#16744 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
nautechsystems/nautilus_trader#5486 · 1 comment ·
Maintainers usually reply within 1 day