Include --field-selector=metadata.name=<configmap> in list query

[FlorianSchaetz]

Is your feature request related to a problem? Please describe.

When using the ConfigMap feature, I want to restrict permissions in K8s as much as possible, for example by using a rule like...

  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    verbs: [ "list", "get", "watch" ]
    resourceNames: [ "<my_app_name" ]

This would allow only minimal access. Unfortunately, according to the K8s documentation...

If you restrict list or watch by resourceName, clients must include a metadata.name field selector in their list or watch request that matches the specified resourceName in order to be authorized. For example, kubectl get configmaps --field-selector=metadata.name=my-configmap

Describe the solution you'd like

Adding this somehow to the filter get query could help minimizing access rights there.

Describe alternatives you've considered

Obviously it would also be possible to add separate rules for list and get/watch:

  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    verbs: [ "list" ]
  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    verbs: [ "get", "watch" ]
    resourceNames: [ "<my_app_name" ]

but that is of course less verbose. Alternatively it would also be nice to just include the specific rights that need to be set in the documentation and refer to this limitation also.

[ryanjbaxter]

Thanks for opening the issue.

Since we are not adding the field-selector are you getting an error?

Can you provide a sample that reproduces the issue?

[FlorianSchaetz]

Of course, the sample is here:

https://github.com/FlorianSchaetz/k8slist

Error see stacktrace.txt. Since the reload functionality is marked as deprecated, it probably is pointless discussing that the same thing applies to the "watch" verb, which can also not be limited by resource name currently for spring cloud kubernetes to work.

stacktace.txt

[ryanjbaxter]

Could you provide the omitted frames in the stacktrace so I can see exactly where the exception is originating from in our code?

[FlorianSchaetz]

Attached, honestly no clue why it was shorter on my other try...

stacktace.txt

[wind57]

let me get the issue straight a bit please. So, because you use :

...
resourceNames: [ "<my_app_name" ]

but, we do not use field-selector with the same resourceName later on, the requests fails. correct?

The documentation usually says something along the lines of "you need proper RBAC for this to work" and yes, its loose on purpose. At least this is how I usually think about it, because we can't know the requirements of each deployment.

But your issue undercovers an interesting situation, that basically says: you set the RBAC, we will make sure it works later on. And we break that promise. Also, I agree that we either document this much more tightly or somehow make it work with that limitation.

I'd like to think about it more when I'm done with a different issue I'm working on. Thank you for raising this.

[FlorianSchaetz]

Just to clarify: I am currently going through the CKAD material and on the way I also play around with things that may come helpful in my actual work, which lead me to playing around with Spring Cloud Kubernetes. And by pure chance I also decided to play around with tightening the access as far as possible, because it seemed reasonable for a pod to only have access to specific ConfigMaps / Secrets, not all of them, thus the limit for the given resourceName - while initially frustrating, it was fun finally finding the place in the documentation to tell me what went wrong. So I am far from an expert, just a curious beginner (in this topic).

But, to my understanding, this is correct. The request fails because, when limiting the service account to the specific resource names, you would have to send the field-selector to do list/watch. At least that's how I read the documentation.

Thanks for taking care. While obviously making it work with list/watch being limited to the given resourceName, documenting the required access rights that the module needs to work correctly would probably also help a lot already.