feat: add skip namespace validation option for RBAC filters#572
feat: add skip namespace validation option for RBAC filters#572sleeyax wants to merge 2 commits into
Conversation
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #572 +/- ##
==========================================
- Coverage 46.56% 46.47% -0.10%
==========================================
Files 69 69
Lines 3930 3938 +8
==========================================
Hits 1830 1830
- Misses 1794 1802 +8
Partials 306 306 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Any update on this? I apologize for opening this PR without creating an issue first. Would appreciate it if you could let me know if this is something that could potentially be merged or solved. |
|
Hi @sleeyax We can potentially do it I'm a little concerned not to check at all. Debating whether something like this is better If you have get permissions on configmaps or serviceaccounts inside your target namespace, you can make a Get() call for a dummy name that you know does not exist (e.g., "exist-check-dummy"). The API server's response will reveal the truth:404 Not Found (Namespace does not exist): If the error message reads "namespaces 'target-ns' not found", the namespace is completely missing from the cluster. 404 Not Found (Namespace exists, resource doesn't): But this seems a bit fickle as well |
|
Thanks for your response. That probably works too in my case. Could you provide a concrete example for me to check?
Just wanted to clarify that in my implementation in this PR it's an opt-in option only. If you don't specify it, the namespaces are still checked. |
What this PR does / why we need it?
Split from #563.
Currently, there's a hard-coded validation check in the code to verify that the supplied namespaces exist. However, clusters with limited permissions may not have the permission to list all namespaces. I added a flag to optionally disable this check for such cases.
PR Checklist
GitHub Issue
Not applicable (I think). Feel free to create one retroactively.