oscerd commented on code in PR #27053:
URL: https://github.com/apache/camel/pull/27053#discussion_r4144948767
##########
components/camel-spiffe/src/main/java/org/apache/camel/component/spiffe/SpiffeProducer.java:
##########
@@ -52,8 +52,17 @@ public void process(Exchange exchange) throws Exception {
private void fetchX509Svid(WorkloadApiClient client, Exchange exchange)
throws Exception {
X509Svid svid = client.fetchX509Context().getDefaultSvid();
Message message = getMessageForResponse(exchange);
- message.setBody(svid);
+ // the identity is always available through the headers, so a route
that only needs it can avoid the key
message.setHeader(SpiffeConstants.SPIFFE_ID,
svid.getSpiffeId().toString());
+ message.setHeader(SpiffeConstants.EXPIRY,
svid.getLeaf().getNotAfter());
+ switch (getEndpoint().getConfiguration().getX509Response()) {
+ // the full SVID carries the private key; the chain does not; id
leaves the body untouched
+ case svid -> message.setBody(svid);
+ case chain -> message.setBody(svid.getChain());
+ case id -> {
+ // leave the body untouched: the identity is exposed through
the headers only
+ }
+ }
Review Comment:
Added the `default -> throw new IllegalArgumentException("Unsupported
x509Response: " + ...)` branch as suggested, so the inner switch now fails loud
on an unhandled `SpiffeX509Response` value instead of silently leaving the body
unset — consistent with the outer operation switch. Thanks!
_Claude Code on behalf of oscerd_
##########
components/camel-spiffe/src/main/java/org/apache/camel/component/spiffe/SpiffeConfiguration.java:
##########
@@ -54,6 +57,22 @@ public void setOperation(SpiffeOperation operation) {
this.operation = operation;
}
+ public SpiffeX509Response getX509Response() {
+ return x509Response;
+ }
+
+ /**
+ * What the {@code fetchX509Svid} operation returns in the message body.
+ * <p/>
+ * Defaults to {@code svid}: the whole {@code X509Svid}, which carries the
<em>private key</em>. A route that only
+ * needs its identity - to log it, route on it, or set a header - can
choose {@code chain} (the X.509 certificate
+ * chain without the key) or {@code id} (the body is left untouched) and
never handle key material. The SPIFFE ID
+ * and expiry are exposed through the {@code CamelSpiffeId} and {@code
CamelSpiffeExpiry} headers in every case.
Review Comment:
Fixed. Corrected `CamelSpiffeId` to `CamelSpiffeSpiffeId` (`HEADER_PREFIX +
"SpiffeId"`) in the `setX509Response` javadoc and in `SpiffeX509Response`'s
class javadoc, and regenerated `spiffe.json` (component + catalog) and the DSL
builder descriptions from the corrected source via a full-reactor build, so the
wrong name is gone from the generated files too.
_Claude Code on behalf of oscerd_
##########
components/camel-spiffe/src/main/java/org/apache/camel/component/spiffe/SpiffeConfiguration.java:
##########
@@ -28,6 +28,9 @@ public class SpiffeConfiguration implements Cloneable {
@UriParam(defaultValue = "fetchX509Svid")
private SpiffeOperation operation = SpiffeOperation.fetchX509Svid;
+ @UriParam(label = "producer,security", defaultValue = "svid")
+ private SpiffeX509Response x509Response = SpiffeX509Response.svid;
Review Comment:
Good point — changed. The default is now `chain`: the body carries the
certificate chain (no private key) unless a route opts in with
`x509Response=svid`, which follows the "denied unless opted in" rule for
security-relevant defaults. I picked `chain` over `id` as the default because
it still delivers the workload's certificate — usable for inspection or a trust
decision — while keeping the key off the message; `id` would leave the body
untouched and force every route to read the headers. Since camel-spiffe is new
in 4.23 and unreleased, no released behaviour changes and there is no
upgrade-guide entry.
Also added an explicit `fetchX509SvidSvidReturnsTheFullSvid` test for the
opt-in key path, and the no-arg `fetchX509Svid` test now asserts the `chain`
default (revert-to-red verified: mutating the default back to `svid` fails that
test alone).
_Claude Code on behalf of oscerd_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
