Reduce Namespace Permissions #3563
Conversation
andrewballantyne
force-pushed
the
update-namespace-permissions
branch
from
506bd49 to
8ddce5b
Compare
andrewballantyne
force-pushed
the
update-namespace-permissions
branch
from
8ddce5b to
4ed20a4
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3563 +/- ##
==========================================
- Coverage 85.53% 85.41% -0.13%
==========================================
Files 1378 1378
Lines 31244 31315 +71
Branches 8738 8761 +23
==========================================
+ Hits 26724 26747 +23
- Misses 4520 4568 +48 see 11 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Gkrumbach07 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@andrewballantyne How is the listing of data science projects in the GUI handled now that namespaces list is not part of the dashboard serviceaccount anymore? Is this achieved via openshift api calls now, what you call pass-through calls? And with the rights of the logged-in user for the central namespace and all data science projects namespaces instead of the dashboard serviceaccount? If yes, then the user in the dashboard admin group would need more privileges on all relevant namespaces, Admin to be specific. I am trying to understand the new Auth CR in relation to operator v2 and dahboard in ODH, but cannot find it. Maybe I am also missing something in the docs. Unclear to me what the operator does and what dashboard and what the logged-in dashboard user |
|
@shalberd hey, let me try to answer some of your inquires...
Nothing was ever listed like this by our service account. If you have access to seeing "all" the data science projects, that's because your user had K8s permissions to do so. This has not changed, your user is your user. The Service Account does the following:
This trimmed the permissions the service account had but never used. Should have no impact what so ever unless you were logging into the service account to do stuff.
Our Projects API has always been used through the "pass-through API" directly to K8s using your user's token.
There are no changes planned today to "remove access" to features already accessed. The Auth Resource moves the ownership of the group configs away from the Dashboard and into the hands of the Operator (aka Platform). Platform will grant access to these groups what they need to do to do their role, effectively shifting our product admins (aka ODH Admins) away from using the service account over time... this will be a slow process. In the end, our In the end the goal will be simply more of a granular check of your admin permissions -- eg. If you want a partial admin (say a Notebook images only admin) you'd be able to craft a role and a binding for that user to do that functionality and get the UI to show up. This is and will be done through SelfSubjectAccessReview (SSAR) checks on the admin pages themselves. Again, this will happen over time and it's unclear what priority this tech debt will be given. Let me know if you have any other questions. |
https://issues.redhat.com/browse/RHOAIENG-16822
Description
Reduces permissions for the SA around Namespaces. Removed deprecated/unused code to assist with the permissions reduction.
We only PATCH namespaces for model serving today.
How Has This Been Tested?
On a cluster, should be fine to just deploy it with the DSC DevFlag as the code that is removed was never called.
Test Impact
None
Request review criteria:
Self checklist (all need to be checked):
If you have UI changes:
After the PR is posted & before it merges:
main