Merge remote-tracking branch 'origin/dev/v2.1' into feat/verify-subcommand - #474
Conversation
validate is an offline check on a config file. verify is the runtime counterpart: it loads the config the way serve does (flags, SOCKGUARD_* environment, file) and then checks that what the config names is reachable right now, so an operator can tell a broken deployment from a broken policy. Five checks, one line each, reporting ok, fail or skip: - config: loads and validates the effective config structurally. - upstream: builds the endpoints (loading their TLS material), runs the same reachability probe serve runs at startup, asks the Docker API through the readiness probe internal/health issues, and resolves the engine flavor through the same GET /version probe. - listener: issues GET <health.path> against each effective listener. - tls: opens the cert, key and client CA each mutual-TLS listener names, the filesystem half of validation the admin API deliberately skips. - image-trust: reports whether image trust is configured and, when it uses keyless identities, whether the Sigstore trust root loads. A skip is a check that does not apply and never changes the exit code, so verify works before the proxy starts as well as against a running one; any fail exits non-zero, so it also works as a container healthcheck or a deploy gate. --json emits the same checks in the same order. --listen-socket and --upstream-socket override the config the way they do on serve. No new probe was written for any of it. Every check calls code the running proxy already calls; health.Monitor.Probe is a thin export of the check /health already runs, so the two cannot drift apart.
|
Deployment failed for project sockguard-website with the following error: Learn More: https://vercel.com/codeswhat?upgradeToPro=build-rate-limit |
biggest-littlest
left a comment
There was a problem hiding this comment.
Reviewed against the CHANGELOG entry and the diff; CI green outside the qlty/Vercel quota noise.
ALARGECOMPANY
left a comment
There was a problem hiding this comment.
Reviewed against the CHANGELOG entry and the diff; CI green outside the qlty/Vercel quota noise.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
📝 WalkthroughWalkthroughAdded the Suggested labels: ✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
sockguard validateis an offline check on a config file, so there's nothing that answers "is this deployment actually working right now."sockguard verifyis that: it loads the config the wayservedoes (flags,SOCKGUARD_*environment, file) and then checks that what the config names is reachable. Five checks, one line each, reporting ok, fail or skip.configloads and validates the effective config structurally.upstreambuilds the endpoints (loading their TLS material), runs the same reachability probeserveruns at startup, asks the Docker API through the readiness probeinternal/healthissues, and resolves the engine flavor through the sameGET /versionprobe.listenerissuesGET <health.path>against each effective listener.tlsopens the cert, key and client CA each mutual-TLS listener names, which is the filesystem half of validation the admin API deliberately skips.image-trustreports whether image trust is configured and, when it uses keyless identities, whether the Sigstore trust root loads. A skip is a check that doesn't apply and never changes the exit code, so verify is usable before the proxy starts as well as against a running one; any fail exits non-zero, so it works as a container healthcheck or a deploy gate too.--jsonemits the same checks in the same order for scripting. No new probe was written for any of it: every check calls code the running proxy already calls, andhealth.Monitor.Probeis a thin export of the check/healthalready runs so the two can't drift apart.TestRunVerifyChecksis the table, running against a fake Docker daemon and a fake sockguard on real unix sockets: both answering, the listener socket absent (skip), the listener answering 503 (fail), the upstream socket missing (fail), missing TLS material (fail), keyed-only image trust that must not touch the network (ok), keyless image trust whose trust root won't load (fail), and a config that doesn't validate, which skips every later check.TestRunVerifyJSONShapepins the--jsondocument: the top-level keys, and five checks in a fixed order each carrying a status from the three-value set.TestRunVerifyTextOutputListsEveryCheckandTestWriteVerifyTextReportsAFailingVerdictcover the default writer's passing and failing arms.TestVerifyTLSTargetsMirrorTheValidatorGatingpins which blocks verify opens against the gatingconfig.Validateuses, so the structural config check plus the tls check together cover everything the full validator would have dereferenced.TestVerifyImageTrustTargetsCoverProfilespins that a client profile's ownimage_trustblock is collected, not just the top-level one.TestRootRegistersVerifypins the subcommand and its flags onto the root command.CHANGELOG entry is under
### Added.✨ Added
sockguard verify.serveconfiguration flags,SOCKGUARD_*environment variables, and file handling.ok,fail, andskipstatuses.Monitor.Probefor one-shot upstream checks.Concerns
verifycannot widen Docker socket access beyond the configured default-deny proxy rules.serveutilities.