Api server backed resources missing permissions

[lulf]

We have an aggregated api server and have it deployed via OLM/CSV. I'm using openshift-install 0.16.1, and after installing the operator, the kube:admin user is getting unauthorized when trying to list api-server backed resources in the openshift-operators namespace or any namespace it has not created itself. CRDs work fine.

I'm not sure if this is an OpenShift 4 issue with the kube:admin user, or an OLM issue. Basically the kube:admin user is not granted the 'view' role in the openshift-operators namespace (or any namespace really), preventing it from listing the resources backed by the aggregated API server. Why this works for CRDs is beyond me.

[SamiSousa]

@ecordell I'm encountering this issue when using the EnMasse operator (referenced above)

[ecordell]

Sorry for the delay - is this still an issue? If so it's a bug that we should address.

[lulf]

Last I checked (~1 week ago), it was. If you look at the authentication flow here:

https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer/#authentication-flow

Where it fails is step 7. The response given from OpenShift master is that the user does not have access. If you craft a SubjectAccessReview with the kube:admin username (which is what the api server does), then you should get unauthorized.

We did see a similar issue on GKE using the provided admin user, which was resolved by ensuring the enmasse api server passes the 'X-Remote-Extra-' headers in the SubjectAccessReview call to the Kubernetes master. I was hoping this was also the cause for this issue, but it did not have an effect. I turned on debug logging to see what extra headers was set, and what I could see was something about scope: user:full. I'm not sure if this is some special OpenShift header.

It could be there is still an issue with api-server in enmasse, so I'd like to have a deeper look into that as well, but i fear we're a bit lost on how it is expected to work on the OpenShift side.

(CC @ctron as I'm on parental leave)

[ecordell]

I wanted to be extra sure that we were aggregating permissions correctly, so I updated a test that was checking this with just CRD-based operators to include aggregated apiservers as well: #856

To me it looks like we're correctly aggregating permission to installed apis to the admin role, verified with a SAR request in the test.

One thing that might be tripping you up - the only way OLM knows what "resource name" to use in ClusterRole is what's in the spec.apiservicedefinitions[].name field. If that doesn't match what should go in the resources list on the RBAC role, that would be the first thing I'd check.

(Or it's unrelated to this part, as you suggested)

[ecordell]

Since I think we've ruled this out as an OLM issue, closing. Please re-open if you have more information or if I've misunderstood.