OK, so let me ask for suggestions. The use-case is as follows:
The Hawkular OpenShift Agent has one job - collect metrics from Jolokia and
Prometheus endpoints deployed within all pods in all projects on a node and
stores the metric data in the Hawkular-Metrics instance. As new pods are
deployed, and old pods are deleted, the agent automatically starts/stops its
collect-and-store for those pods. A pod that has metrics to be collected will
associate itself with a configmap that contains details to tell the agent what
to monitor. So, for example, a pod containing a WildFly server can associate
itself with a configmap that defines what JMX attributes to collect, what its
Jolokia port/path is, etc, etc - the agent (which has cluster-reader role)
detects when this pod comes online, the agent reads that pod's associated
configmap information, and thus knows what the pod wants monitored and starts
doing it as soon as the pod is deployed.
Most likely, the Jolokia endpoints are going to be secured, perhaps with
username/password credentials. Rather than force the pod to declare its
credentials in the clear within the configmap, we have it declare them by
referring to OpenShift secrets. So, for example, that WildFly pod can define in
its configmap the following:
endpoints:
- type: jolokia
port: 8080
credentials:
username: secret:my-os-secret-name/username
password: secret:my-os-secret-name/password
Assuming someone created that secret called "my-os-secret-name" and it has
"username" and "password" keys, the agent can look up "my-os-secret-name",
retrieve the username and password and thus be able to make authenticated http
requests to that jolokia endpoint.
But since cluster-reader does not have "get/secrets" permissions, the agent
needs some other role to do this. I could create a new cluster role that only
has "get/secrets" and assign it to the agent user. But I'm assuming this is not
ideal??
What other options are there to do this kind of thing? Is there a different way
pods can share credentials to a cluster-wide agent like this?
----- Original Message -----
> Correct, the cluster-reader role is intentionally non-escalating, so it
> does not have access to read secrets.
>
> Global read access to secrets is not typically something you'd give a
> read-only user.
>
> On Wed, Jan 11, 2017 at 9:33 AM, John Mazzitelli <[email protected]> wrote:
>
> > I'm looking for a cluster role that has "get" "secrets" enabled, and there
> > seems to be very few - system:node is one but it has other perms I do not
> > need. I assumed cluster-reader would be able to read secrets but that does
> > not seem to be the case. I was hoping I'm just doing something wrong, but I
> > figured ask here to confirm if cluster-reader really can NOT get secrets.
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
