[
https://issues.apache.org/jira/browse/ARTEMIS-5700?focusedWorklogId=986706&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-986706
]
ASF GitHub Bot logged work on ARTEMIS-5700:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 10/Oct/25 11:48
Start Date: 10/Oct/25 11:48
Worklog Time Spent: 10m
Work Description: grgrzybek commented on code in PR #5963:
URL: https://github.com/apache/activemq-artemis/pull/5963#discussion_r2419670796
##########
artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/kubernetes/client/KubernetesClientImpl.java:
##########
@@ -147,8 +165,9 @@ private String buildJsonRequest(String clientToken) {
.build().toString();
}
- private SSLContext buildSSLContext() throws Exception {
+ private static SSLContext buildSSLContext() throws Exception {
SSLContext ctx = SSLContext.getInstance("TLS");
Review Comment:
To satisfy paranoic scanners, I'd switch to `TLSv1.2` at least. `TLS` is
effectively `SSLv3`.
Issue Time Tracking
-------------------
Worklog Id: (was: 986706)
Time Spent: 20m (was: 10m)
> KubernetesLoginModule doesn't control HttpClient instances
> ----------------------------------------------------------
>
> Key: ARTEMIS-5700
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5700
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Grzegorz Grzybek
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After some heap dump analysis, I realized that a scenario where
> {{org.apache.activemq.artemis.spi.core.security.jaas.KubernetesLoginModule}}
> is used as JAAS login module is inefficient.
> JAAS' LoginContext _instantiates_ the login modules on each {{lc.login()}}
> and we have:
> {code:java}
> public KubernetesLoginModule(KubernetesClient client) {
> this.client = client;
> }
> public KubernetesLoginModule() {
> this(new KubernetesClientImpl());
> }
> {code}
> {{org.apache.activemq.artemis.spi.core.security.jaas.kubernetes.client.KubernetesClientImpl}}
> calls this in {{getTokenReview()}}:
> {code:java}
> HttpClient client = HttpClient.newBuilder().sslContext(ctx).build();
> HttpRequest request = HttpRequest.newBuilder(apiUri)
> .header("Authorization", "Bearer " + authToken)
> .header("Accept", "application/json; charset=utf-8")
> .POST(HttpRequest.BodyPublishers.ofString(jsonRequest)).build();
> logger.debug("Submit TokenReview request to Kubernetes API");
> try {
> HttpResponse<String> response = client.send(request,
> BodyHandlers.ofString());
> if (response.statusCode() == HTTP_CREATED) {
> logger.debug("Received valid TokenReview response");
> return TokenReview.fromJsonString(response.body());
> }
> logger.error("Unable to retrieve a valid TokenReview. Received StatusCode:
> {}. Body: {}",
> response.statusCode(), response.body());
> } catch (IOException | InterruptedException e) {
> logger.error("Unable to request ReviewToken", e);
> }
> return tokenReview;
> {code}
> The point is that {{jdk.internal.net.http.HttpClientImpl}} is not closeable
> and is supposed to be reused.
> {{jdk.internal.net.http.AuthenticationFilter#caches}} holds the weak map of
> clients, but without GC the number of instances will grow unnecessarily.
> Also creation of HttpClient is not negligible when doing token reviews so
> often.
> ----
> I'm just finishing big Jolokia changes related to JAAS and authentication and
> may at some point review JAAS usage in AMQ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
