-
Notifications
You must be signed in to change notification settings - Fork 283
Conversation
+1 on switching this preview PR into a real one (it's even fixing a CVE, see this article for details). Unsure if the Keycloak operator needs to run as privileged container already, or not (in order to be apply clusterwide settings). In any case weaking |
Converting this into a "real" Pull Request. |
ef3be75
to
8c0d4fc
Compare
Signed-off-by: Sebastian Laskawiec <slaskawi@redhat.com>
8c0d4fc
to
bae5f1a
Compare
Just in case, here's the build: https://travis-ci.org/github/keycloak/keycloak-operator/builds/680493735 |
@stianst @abstractj @hmlnarik @mhajas @iankko @pb82 @davidffrench May I ask for a review? This should be a quick one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR @slaskawi! I tried slaskawi/keycloak-operator:cleanup
and it works as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving based on @mhajas 's approval
KEYCLOAK-13974
A long while ago, we discussed permissions issue in our Keycloak Container (link1link2). The outcome of the discussion is that a binary just needs to be owned by a
root
group and we don't really need any extra user.I'm not sure if this is the best moment, but perhaps we should do a permission clean up in our Dockerfile here as well? WDYT @stianst @abstractj @douglaspalmer @iankko @davidffrench ? If you think that's a good idea, I'll convert it into a proper Pull Request.
The image might be tested using:
slaskawi/keycloak-operator:cleanup