Why would you not use the service account token? On Wed, Jan 11, 2017 at 1:24 PM, Matt Wringe <[email protected]> wrote:
> We are also in a situation where we would like to have a client > certificate for the agent. > > Ideally this could have been something which would have been provided by > OpenShift (either through the oc commands, or via the system generated > certificates: https://github.com/openshift/origin/issues/10085) > > Is there any option to be able to do this nicely? Other than having to > modify the OpenShift code to generate the client certificate like it does > for other components? > > ----- Original Message ----- > > From: "Clayton Coleman" <[email protected]> > > To: "John Mazzitelli" <[email protected]> > > Cc: "users" <[email protected]> > > Sent: Wednesday, 11 January, 2017 11:26:12 AM > > Subject: Re: cluster-reader and secrets > > > > We would create a special role specifically for the agent. > > > > On Wed, Jan 11, 2017 at 10:19 AM, John Mazzitelli < [email protected] > > wrote: > > > > > > 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 > > > > > > _______________________________________________ > > users mailing list > > [email protected] > > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > > >
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
