On 01/11/2017 01:41 AM, John Mazzitelli wrote:
There is one problem with this. I need to add a cluster role to the
agent to read secrets (I need verb "get" on resource "secrets" - for
testing, I am using the "system:node" role since that is one of the few that has
that permission - we'd really want a cluster role that only has
"get"/"secrets" - we don't need all the perms that
"system:node" provides - we'd have to create our role if need be).
We also use secrets on Hawkular APM, and I don't remember having to
create specific cluster roles. I believe that, as long as the secret
lives in the same "application" as the consumer of the secret, there's
no need for an extra role.
I'm not sure the way we are doing can be also done for the HOSA, but
here's an overview on how we use secrets for APM:
We create the secret, and the values here should be base64 encoded:
https://github.com/jboss-dockerfiles/hawkular-apm/blob/master/openshift-t...
We specify that we want this secret to be a volume:
https://github.com/jboss-dockerfiles/hawkular-apm/blob/master/openshift-t...
And we mount this volume into the container:
https://github.com/jboss-dockerfiles/hawkular-apm/blob/master/openshift-t...
We have a standalone-wrapper.sh, which then tries to find the admin's
username and password the server should create. One of the possibilities
is reading the client secret values:
https://github.com/jboss-dockerfiles/hawkular-apm/blob/master/hawkular-ap...
- Juca.