-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shell-ui : Add users group mapping in shell UI config #3196
shell-ui : Add users group mapping in shell UI config #3196
Conversation
Hello jbwatenbergscality,My role is to assist you with the merge of this Status report is not available. |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list:
|
e6ab115
to
480e0d9
Compare
8b4553f
to
1b413e8
Compare
@bert-e after_pull_request=3181 |
480e0d9
to
df63277
Compare
1b413e8
to
abb9dec
Compare
df63277
to
04a7330
Compare
a57af98
to
b2d7dc9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👌 you may want to address usage of this new configuration in the same PR (defining a mapping for Dex users).
it('should return a merged array of groups when defined in OIDC claims and mapping ', () => { | ||
//E | ||
const oidcAndStaticGroups = ["group"]; | ||
const groups = getUserGroups({profile: {email: "test@test.com", groups: oidcAndStaticGroups}}, {'test@test.com': oidcAndStaticGroups}); | ||
//V | ||
expect(groups).toEqual(oidcAndStaticGroups); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this test case could be improved a bit, by making sure the input OIDC and mapped groups are different (otherwise we're not really testing the "merge" behaviour):
- have one case where OIDC groups are not set at all (to emulate Dex 😉)
- have another case where there are some duplicates which get discarded by this method
@@ -21,6 +21,8 @@ export type MenuItems = {[path: string]: TranslationAndGroups } | |||
|
|||
export type Options = { main: MenuItems, subLogin: MenuItems }; | |||
|
|||
export type UserGroupsMapping = {[email: string]: string[]}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Static mapping is fine for now I guess, maybe adding support for regular expressions could be useful in the future.
Anyway. This mapping would need to be defined from Salt (could be merged with user-provided values in UI CSC) by reading the Dex CSC, so we can always get the "platform-admin" (or whatever it's called) group to Dex static users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In practice, I think this simply means updating the salt/metalk8s/addons/ui/config/shell-ui-config.yaml.j2
template to:
#!jinja|yaml
{%- set dex_defaults = salt.slsutil.renderer('salt://metalk8s/addons/dex/config/dex.yaml.j2', saltenv=saltenv) %}
{%- set dex = salt.metalk8s_service_configuration.get_service_conf('metalk8s-auth', 'metalk8s-dex-config', dex_defaults) %}
# Defaults for shell UI configuration
apiVersion: addons.metalk8s.scality.com/v1alpha1
kind: ShellUIConfig
spec:
oidc:
providerUrl: "/oidc"
redirectUrl: "https://{{ grains.metalk8s.control_plane_ip }}:8443/"
clientId: "metalk8s-ui"
responseType: "id_token"
scopes: "openid profile email groups offline_access audience:server:client_id:oidc-auth-client"
userGroupsMapping:
{%- for user in dex.spec.config.staticPasswords | map(attribute='email') %}
{{ user }}: [admin]
{%- endfor %}
options:
main:
"https://{{ grains.metalk8s.control_plane_ip }}:8443/":
en: "Platform"
fr: "Plateforme"
"https://{{ grains.metalk8s.control_plane_ip }}:8443/alerts":
en: "Alerts"
fr: "Alertes"
subLogin:
"https://{{ grains.metalk8s.control_plane_ip }}:8443/docs":
en: "Documentation"
fr: "Documentation"
4c698b5
to
4faa805
Compare
b2d7dc9
to
6b9a18b
Compare
4faa805
to
a269acb
Compare
6b9a18b
to
8f49d08
Compare
40f51a0
to
8b33873
Compare
8f49d08
to
4fdd9b4
Compare
9ec3291
to
dc7625a
Compare
f6f77c4
to
c289959
Compare
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list:
The following options are set: after_pull_request |
505475e
to
7abbd99
Compare
7abbd99
to
6735163
Compare
.. parsed-literal:: | ||
|
||
root\@bootstrap $ kubectl exec -n kube-system -c salt-master \\ | ||
--kubeconfig /etc/kubernetes/admin.conf \\ | ||
salt-master-bootstrap -- salt-run state.sls \\ | ||
metalk8s.addons.ui.deployed saltenv=metalk8s-|version| | ||
|
||
.. parsed-literal:: | ||
|
||
root\@bootstrap $ kubectl exec -n kube-system -c salt-master \\ | ||
--kubeconfig /etc/kubernetes/admin.conf \\ | ||
salt-master-bootstrap -- salt-run state.sls \\ | ||
metalk8s.addons.prometheus-operator.deployed \\ | ||
saltenv=metalk8s-|version| | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can pass multiple SLS formulas to state.sls
, so the following should be enough:
.. parsed-literal::
root\@bootstrap $ STATES=$(printf ",metalk8s.addons.%s.deployed" \\
dex prometheus-operator ui)
root\@bootstrap $ kubectl exec -n kube-system -c salt-master \\
--kubeconfig /etc/kubernetes/admin.conf \\
salt-master-bootstrap -- salt-run state.sls \\
"${STATES:1}" saltenv=metalk8s-|version|
.. literalinclude:: ../../salt/metalk8s/addons/ui/config/metalk8s-shell-ui-config.yaml.j2 | ||
:language: yaml | ||
:lines: 3- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not keep this include? It's easier to keep things in-sync this way IMO.
I think keeping Jinja syntax in there isn't really a problem (it's somewhat readable), but if it is, we could use the .. jinja::
directive to render some of the templated values (such as the userGroupsMapping
). Not really straightforward though, since I guess we want to keep a placeholder for the control plane IP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had some doc build issues linked to yaml highlighting. Maybe using .. jinja::
directive could help solves this, I will try it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I will remove highlighting for now WDYT ?
"admin@metalk8s.invalid": | ||
- admin | ||
{%- for user in dex.spec.config.staticPasswords | map(attribute='email') %} | ||
"{{ user }}": [admin] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, IIUC, in practice all Dex static users have the admin
group mapped. Do we want another PR to filter MetalK8s pages based on this group? Also, to keep things clean, I would name this group metalk8s:admin
(it's configurable anyway).
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list:
The following reviewers are expecting changes from the author, or must review again: The following options are set: after_pull_request |
6735163
to
0c9d5d1
Compare
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list:
The following options are set: after_pull_request |
/approve |
In the queueThe changeset has received all authorizations and has been added to the The changeset will be merged in:
The following branches will NOT be impacted:
There is no action required on your side. You will be notified here once IMPORTANT Please do not attempt to modify this pull request.
If you need this pull request to be removed from the queue, please contact a The following options are set: approve, after_pull_request |
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue None. Goodbye jbwatenbergscality. |
Component:
shell-ui
Context:
In order to disable features in Metalk8s UI and Solutions UI according to user permissions we need an abstract way to define user groups independant from any OIDC provider capabilities.
Summary:
This PR add support for an
userGroupsMapping
property in shell ui configuration that allows static user groups configuration.Acceptance criteria:
Shell-UI should expose aggregated users groups to Metalk8s and solutions UIs.
Refs : #3159
Depends on : #3154 and #3181