Operator auth with serviceAccount and split mgmt and app realms #423
Conversation
ruromero
changed the title
|
The PR is missing the decision of whether to authenticate using the service account or the username/password |
|
Thanks @gaohoward for the missing bits. |
|
this is great :-) I am wondering about the two realms, it would be ideal to be able to use the service account for broker to broker comms, like a federation connection, but that will use the "activemq" realm. Afaik, the security manager uses a single realm "activemq" by default. It is configurable, but there is only one. with the security.properties approach - is there a merge option? That will bring its own potential problems too, but I think it may be necessary. ie: into the activemq realm we add the service account login module for use inter-broker and by management the other thought, separate, is that we do this just for the jolokia agent and always configure that for the operator. In that way we are locking down the broker and we deprecate the deployment of the web console war. |
Isn't federation configured with a specific credentials? https://access.redhat.com/documentation/en-us/red_hat_amq/2020.q4/html/configuring_amq_broker/assembly-br-configuring-addresses-and-queues_configuring#proc-br-configuring-upstream-address-federation_configuring
Yes, this security.properties file adds an additional login.config [1] file that will be appended to the first one available on the default location [0]. This allows users to customize the activemq realm and also provide additional management configurations.
I think, the jolokia agent is the only one using the management realm. |
ruromero
force-pushed
the
sa-login
branch
3 times, most recently
from
a12f43b
to
7122571
Compare
| bytes, err := sdkk8sutil.GetOperatorNamespace() | ||
| namespace := "local" | ||
| if err != nil { | ||
| clog.V(5).Info("Using --localOnly without --namespace, but unable to determine namespace") |
There was a problem hiding this comment.
I am not understanding this, I would have thought "default" would be the default. Who or what interprets "local"
There was a problem hiding this comment.
This is just a placeholder for parsing the k8s-roles.properties file when not running on k8s in case the sdkk8sutil.GetOperatorNamespace() fails to retrieve the ns. That would happen only if it is running locally and not connected to a k8s cluster but that case is very unlikely to happen so I can just replace it by "" to avoid misunderstandings.
yes, I am thinking future here, if the federation password could be a service account token, then that client would be authenticated with another broker against the "activemq" domain, ideally that too would have the service account login module configured. however if the CR has clustered = true, we would need to be able to authenticate broker to broker comms with a service account. Either the cluster/federation acceptor can use the management domain, or we need to amend/extend the activemq realm |
|
looking in more detail at this, I think we need a feature flag, otherwise all existing deployments will be restarted with the extra volume mount needing a stateful set update/refresh. and thinking more, maybe the flag is the presence of a -jaas-config extra mount. When external jaas config is specified the operator manages its own for the control plane, ie: the "management" realm |
|
and the management realm config should be in a secret rather than a config map. |
|
I am thinking to split this PR:
|
brusdev
force-pushed
the
main
branch
4 times, most recently
from
4450ca1
to
dc7da46
Compare
brusdev
force-pushed
the
main
branch
5 times, most recently
from
a9861a2
to
6ea4c00
Compare
Fix #417
Depends on
Based on the broker version, the operator will authenticate using the serviceAccount or the username/password. The operator will also configure different realms for management and application users.