Allow pushing user-allocation membership to Keycloak#249
Allow pushing user-allocation membership to Keycloak#249QuanMPhm wants to merge 1 commit intonerc-project:mainfrom
Conversation
src/coldfront_plugin_cloud/tests/functional/openshift/test_allocation.py
Outdated
Show resolved
Hide resolved
9a53156 to
d7da5c4
Compare
|
@knikolla Two more questions:
|
src/coldfront_plugin_cloud/tests/functional/openshift/test_allocation.py
Outdated
Show resolved
Hide resolved
d7da5c4 to
3b80589
Compare
|
@knikolla I've addressed your comments except one. Also, do you have responses to these questions? |
3b80589 to
cb1d628
Compare
|
@QuanMPhm please resolve conflicts. Are there any questions that I missed answering? |
a217f31 to
0358cb7
Compare
0358cb7 to
8fc4ea6
Compare
knikolla
left a comment
There was a problem hiding this comment.
Did a quick first pass and provided some comments.
Also this needs to be possible configurable via a setting.
|
@QuanMPhm Actually, another thought, do you think it would make sense to implement this in the Keycloak plugin? https://github.com/nerc-project/coldfront-plugin-keycloak It could listen to signals in the same way that the cloud plugin listens to signals. It already has a keycloak client implemented. And there is nothing in pushing users to a Keycloak group that is specific to either OpenShift or OpenStack. |
|
@knikolla I see that it does make sense to seperate the Keycloak functionality from the rest of the plugin. It makes sense to me. I forgot that repo existed. There would need to be some overhaul to add integration and unit tests to |
For now let's keep it here (as not to frontload the work) and we can easily split it out later if needed. Perhaps try implementing it here via signals so as to keep it loosely coupled so that if we need to split it later it doesn't require a lot of uncoupling. |
|
@knikolla @larsks I have a question about the Coldfront Keycloak PR. I know we previously decided to represent user-membership to an allocation by adding them to a Keycloak group with the same name as the |
See my comment here #249 (comment) |
96e371c to
97d7220
Compare
knikolla
left a comment
There was a problem hiding this comment.
Quick first pass for direction feedback.
97d7220 to
151aea2
Compare
knikolla
left a comment
There was a problem hiding this comment.
Looking much better. Almost there.
A follow-up to this (after we merge the validate_allocations refactor) should investigate how to cleanly implement this in validate_allocations too.
| CloudResourceAttribute(name=RESOURCE_PROJECT_DOMAIN), | ||
| CloudResourceAttribute(name=RESOURCE_ROLE), | ||
| CloudResourceAttribute(name=RESOURCE_QUOTA_RESOURCES), | ||
| CloudResourceAttribute(name=RESOURCE_KEYSTONE_GROUP_TEMPLATE), |
Actually... I would make it a whole separate CLI command. |
A Keycloak admin client has been added When `activate_allocation` is called, the user is added to a Keycloak group named using a format string defined in the allocation's resource attribute "Format String for Keystone Group Names" If the user does not already exist in Keycloak, the case is ignored for now Keycloak integration is optional, toggled by setting the env var "KEYCLOAK_BASE_URL" Authentication to Keycloak is done via client credentials grant When `deactivate_allocation` is called, the user is removed from the Keycloak group New functional test added for Keycloak integration A comment in `validate_allocations` has been updated to reflect the more restrictive validation behavior, where users on cluster projects will be removed if they are not part of the Coldfront allocation (rather than if they are not registered on Coldfront at all).
151aea2 to
d3087ea
Compare
|
@knikolla I've allowed the group name template string to accept any allocation attribute. Further documentation is in the docstring for the function |
|
@naved001 would appreciate a pass from you. |
knikolla
left a comment
There was a problem hiding this comment.
Had some more time to think about how to expose enabling/disable the feature.
| attributes.RESOURCE_KEYCLOAK_GROUP_TEMPLATE | ||
| ) | ||
| if group_name_template is None: | ||
| logger.warning( |
There was a problem hiding this comment.
I had some more time to think about this. Instead of logging a warning, log an info message here, this way the presence of the Keycloak Group Template Resource Attribute can act as a flag for enabling the feature for each specific Resource individually.
Therefore also switch the order so that the group template is parsed before you look up the user.
Keycloak enabled but no group name template specified for resource <>. Skipping addition to Keycloak group.
| attributes.RESOURCE_KEYCLOAK_GROUP_TEMPLATE | ||
| ) | ||
| if group_name_template is None: | ||
| logger.warning( |
There was a problem hiding this comment.
Same comment as from addition.
Closes nerc-project/operations#948. More details in the commit message
There are still some questions I have below, so this is still a draft for now.