OpenShift permissions for appowners

Hey folks!

In OpenShift, we have set permissions for the appowner role in this file, and we give the role to team members who are responsible for the application.

You can see in the file that the staging permissions are wider, they allow create, delete, update on most objects, when it’s forbidden in prod. I can see why we want to do that: to limit local tinkering with our prod deployments.

That said, I’m facing an issue: in Mirrormanager, we sometimes want to debug why a crawl isn’t working right, and for that we use “debug” pods created with oc debug. Our permissions don’t allow appowners to do that in prod because it’s lacking the create and delete permissions on pods objects. And in Mirrormanager’s case, we can’t do that on staging because the crawl jobs aren’t running in staging (to avoid crawling our mirrors twice).

Do you think it’d be fine security-wise if I added the create and delete permissions on pods to appowners in prod? Or should it be a per-project switch in the role maybe?

I think create and delete are pretty dangerous in production… but I
suppose app owners can already do a lot. I guess I would say if we do
allow that we shouldn’t allow it globally, only specific projects that
need to do debugging?

Whats the advantage in that case to running a debug pod vs just enabling
debugging in the application in the pod? ie, having a env var or
something to set to make it debug log?

if we do allow that we shouldn’t allow it globally, only specific projects that
need to do debugging?

Alright I’ll make the role a little bit more flexible

Whats the advantage in that case to running a debug pod vs just enabling
debugging in the application in the pod? ie, having a env var or
something to set to make it debug log?

For MirrorManager, the goal is to start debug pods with the pod definition of a cronjob, so there is no pod to oc rsh into.

if we do allow that we shouldn’t allow it globally, only specific projects that
need to do debugging?

Alright I’ll make the role a little bit more flexible

Sounds reasonable.

Whats the advantage in that case to running a debug pod vs just enabling
debugging in the application in the pod? ie, having a env var or
something to set to make it debug log?

For MirrorManager, the goal is to start debug pods with the pod definition of a cronjob, so there is no pod to oc rsh into.

Hum… ok.