Recent page reviews - #506
Conversation
Self-reviews and edits of pages I recently added i quickly to make sure they were in the 1.0.0-alpha1 release, but that I hadnt had the chance to test and review more closely. Signed-off-by: Rachael Graham <rachael.graham@solo.io>
| ## Credential injection | ||
|
|
||
| An egress rule can declare that the gateway attach a credential to a matching request, so that an agent reaches a protected service without ever holding the secret itself. A `hostnames` rule carries the effect, which names the header to set, an optional prefix such as `Bearer `, and a `substrate-secret://` reference that a registered credential provider resolves. | ||
| An egress rule can declare that the gateway attach a credential to a matching request, so that an agent reaches a protected service without ever holding the secret itself. A `hostnames` rule carries the effect, which names the header to set, an optional prefix such as `Bearer `, and an `ate-secret://` reference that a registered credential provider resolves. |
There was a problem hiding this comment.
is this really an ate secret?
There was a problem hiding this comment.
Yes. From the published chart (substrate 0.2.0-beta5), templates/k8s-credential-provider.yaml:17: "The credential provider: a gRPC service that resolves ate-secret:// URIs". substrate-secret:// appears nowhere in the chart.
|
From Claude: Blocking: substrate-runtime/networking-and-egress.md now states as default behavior that "the gateway terminates TLS, so hostname rules constrain encrypted traffic as well as cleartext" (top callout, "Traffic types", and "Policy generation"). From agent-substrate/substrate's own docs/egress-trust-bundle.md, this MITM/TLS-termination behavior is gated behind an experimental sdsmint install (--experimental-use-sdsmint) and explicitly not default — enabling it on a non-sdsmint install is documented as breaking the actor. Could you confirm whether kagent's bundled install turns this on by default? If not, I think this needs to go back to something closer to the old framing (opt-in gateway, deploy it if you need HTTPS enforcement), or at minimum name the prerequisite. Happy to push that revert myself once we agree on the right framing — let me know. Related: the new "Credential injection" section's claim that kagent auto-generates injection rules from apiKeySecret/headersFrom — I couldn't find the generating code in kagent-dev/kagent (it may be enterprise-only or just not indexed for me), so flagging as a "please double-check" rather than a hard blocker, especially since it's downstream of the same TLS-termination question. |
|
Checked against the chart kagent bundles —
Credential injection is OSS, not enterprise: |
Self-reviews and edits of pages I recently added i quickly to make sure they were in the 1.0.0-alpha1 release, but that I hadnt had the chance to test and review more closely.