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.

[ryanjbaxter]

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 think we need to do more than just document this because if the RBAC is set to a specific resource the user of Spring Cloud K8S has no way of modifying the metadata.name selector. I think we would at the very least have to create a configuration property that instructs spring cloud k8s to set the selector when the user has specified a specific resource.

[FlorianSchaetz]

Not an expert, but what about something like this...

• We can assume that, if an app had the config module on its classpath, it is supposed to actually read a ConfigMap and/or Secret.
• For this, LIST is basically required
• So, if the LIST fails with a 401, why not do a fallback with the metadata.name selector for all possible ConfigMaps?
• Only if all the fallback possibilities fail, log a WARN or fail (if fail-fast is enabled) with a good message indicating the potential error source ("Could not LIST ConfigMap resources: Unauthorized. Please check your RBAC configurations to allow LIST for at least one of the potential ConfigMaps.")
• If it doesn't fail, just log DEBUG for the failed possibilities so that if someone is missing configurations, they can see in the log what failed, if needed
• This would require the user to either at least give LIST privileges to ConfigMap OR disable the feature explicitly, if they know there will be no ConfigMaps.

[ryanjbaxter]

I think that is a good approach!

[wind57]

There are issue with this approach that needs further thinking imho. For example:

• LIST is indeed required, atm. In the future, we will support getting individual configmaps, by name: https://github.com/spring-cloud/spring-cloud-kubernetes/issues/1681 . This is because not all users are happy reading everything in the namespace.

• We also support searches by labels, and those are places where the code will need to change also.

• We support searches "with profile enabled", so you we can look for configmaps "myApp", but also "myApp-dev" or "myApp-k8s", depending on the active profile. So users will need to add multiple resourceNames, for profile based sources.

There are some other points also... The good news, is that some time ago, we have isolated the code in such a manner that what you are requesting is not that complicated to achieve.

I can give it a try, but only after everything that is targeted for the next major is merged; simply because there are many changes in those PRs that are related to this one. So once that is done, I can give it a shot.

@ryanjbaxter can you add the enhancement label please?