oscerd opened a new pull request, #1915:
URL: https://github.com/apache/camel-spring-boot/pull/1915
Two shipped defaults in this starter are broader than the library it wraps.
### 1. The agent bound every interface, by classpath presence alone
```java
@ConditionalOnProperty(name = "camel.component.jolokia.enabled", havingValue
= "true", matchIfMissing = true)
...
setDefaultConfigValue("host", "0.0.0.0");
setDefaultConfigValue("autoStart", "true");
```
`matchIfMissing = true` means adding the starter is enough to start the
agent, and the bind address was hard
defaulted to all interfaces. There is no authenticator anywhere in the
starter, and TLS is configured only when
the Kubernetes service-account CA file exists on disk — so other deployment
shapes got a plain HTTP management
endpoint on every interface. The Jolokia JVM agent's own default is loopback.
`host` now defaults to `127.0.0.1`. Exposing it beyond the host is a
conscious step via
`camel.component.jolokia.server-config.host`.
### 2. The restrictor accepted every origin
`CamelRestrictor extends AllowAllRestrictor` and overrode the MBean-domain
checks but **not**
`isOriginAllowed`, so the permissive base-class behaviour applied. A page
the user happens to visit could drive
the agent — binding to loopback is no protection against that, which is why
this matters even after change 1.
Cross-origin browser requests are now rejected. A request carrying no
`Origin`/`Referer` header is not a
cross-origin browser request and is still allowed, so curl, Hawtio and the
Jolokia CLI are unaffected.
### What is deliberately *not* changed
The finding also proposed gating attribute-write and operation-invoke behind
an opt-in. **I did not do that**,
and the reason is worth stating:
- Managing Camel through Jolokia — starting and stopping routes from Hawtio
— is precisely what this starter
exists for (see CAMEL-21242). Denying operations by default would break
its primary use case.
- Jolokia instantiates the restrictor reflectively from the
`restrictorClass` config key and
`SpringJolokiaAgent` has no `setRestrictor`, so a
`camel.component.jolokia.*` flag could only reach it
through static mutable state.
- With the endpoint on loopback, invoking operations requires local access
to the host, which is a very
different risk profile from the remote case.
So the capability stays, and `usage.adoc` now says plainly that the
restrictor limits *which* MBeans are
reachable, not *what* may be done to them — where before it implied
otherwise. Users wanting stricter behaviour
can still supply their own `restrictorClass`, and `MyRestrictor extends
CamelRestrictor` remains a documented
extension point.
### Behaviour change
Both changes affect shipped defaults and need an upgrade-guide entry in
`apache/camel` — happy to open that.
Anyone relying on remote reachability sets
`camel.component.jolokia.server-config.host`; anyone driving the
agent from a browser page will now need an explicit restrictor.
Kubernetes deployments that reached the agent over the pod network are
affected: the docs note the host
property in both the intro and the k8s section.
### Tests
`CamelRestrictorTest` — 4 cases: cross-origin rejected (both strict modes),
no-origin allowed, MBean domain
limiting still works, and operations on the Camel domain still permitted.
The existing
`JolokiaComponentAutoConfigurationTest` host assertion is updated to
`127.0.0.1`.
Verified meaningful: against `main`, the host assertion and
`rejectsCrossOriginBrowserRequests` both fail
(`expected <false> but was <true>`); the two guard cases pass either way.
Module suite 21 tests green, root
reactor build green.
--
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]
