Brandon, I appreciate the work to implement the admin dashboard, and the user impersonation capability. Nice presentation last month in SLC!
I do not understand how to implement the OOD_ADMIN_GROUP definition.
Are you or others able to provide guidance? I’m tempted to update the nginx configuration, either the pun_custom_env, or the pun_custom_env_declarations, but only because we don’t use capitalized variables in the other configuration files – not exactly the best reasoning, but that’s where I am.
I’ll explicitly mention @brandonbiggs to see if he has any clarification to add, but looking at the code this variable is only used in the routes initializer, meaning that setting it in your dashboard .env should do the trick. If you are unsure, you can always modify the initializer like so to make sure you are getting the expected value
# config/initializers/routes.rb
# Add Custom OOD routes
ActiveSupport.on_load(:after_initialize) do
# Admin Portal routes
Rails.logger.info "Checking to add routes..."
Rails.logger.info "OOD_ADMIN_GROUP: #{ENV['OOD_ADMIN_GROUP']}"
# if CurrentUser.group_names.include?(ENV['OOD_ADMIN_GROUP'])
# Rails.logger.info "Admin group found. Adding admin routes."
# Rails.application.routes.append do
# get "/admin", to: "admin#index"
# post "/admin/update_impersonation", to: "admin#update_impersonation"
# end
# Rails.application.reload_routes!
# else
# Rails.logger.info "Admin group not found, /admin route not added"
# end
# Rails.application.reload_routes!
end
Make sure you touch tmp/restart.txt from the dashboard directory, and you should be able to search the logs and find that section. I’ll also note that I had to change the line immediately after, since as written it was checking if the user was a member of the literal group named OOD_ADMIN_GROUP instead of accessing the value from the environment with ENV['OOD_ADMIN_GROUP'].
Thanks, Braeden – I’ll also call out to @brandonbiggs
I like that mod to just test the variable definition. I’ve implemented that.
Problem 1. However, there is no information as yet accumulating in the /var/log/ood-impersonation.log
And just to be clear – so far my account is not presented with the admin dashboard feature. I suppose these two statements are consistent. But the lack of entries in the log file suggests I’ve messed up something more fundamental than setting the OOD_ADMIN_GROUP variable.
Problem 2. Setting the OOD_ADMIN_GROUP variable. Following your reasoning, I’ve also tried defining OOD_ADMIN_GROUP in the ../dashboard/env file, along with the specified variables
What code triggers the loading of the index.html.erb from user_impersonation_dashboard, rather than the standard UI?
Does this result from having /etc/ood/config/apps/dashboard/views/index.html.erb; and if a person has login group matching ‘OOD_ADMIN_GROUP’, then this view prevails?
It appears that the initializers and views supporting user_impersonation_dashboard are meant to coexist with already established views and initializers under ../apps/dashboard/.
I’m pretty sure I do have the problem that ‘OOD_ADMIN_GROUP’ is not defined properly. Most recently, I’ve tried defining this within nginx_stage.yml, within ‘pun_custom_env’.
The puzzle remains as to why I see no output generated in /var/log/ood-impersonation.log’
Brandon and his team did an amazing job with the impersonation interface and it works like a charm. I made a pull request here that could clear up a few things for you @emily.dragowsky.
EDIT:
Let me also add that we ONLY use it on our Dev server. This way, we mitigate all risk of breaking logins since the custom mapping script is local to each OOD server. If things go south, it only affects our Dev instance which is only accessible by my team.
Hi, Sean – I’ve reviewed the updates to the method that you suggest. Where to define ‘OOD_ADMIN_GROUP’ remains unclear to me. Happy to hear from anyone on this.
I also really appreciate the development of this approach by Brandon – I’m very excited to implement the impersonation, and share it with my local team.
Comments on the pull-request:
– I do agree that the placement of the files supporting the impersonation is better approached through your suggestions – I found that the cp -r .. approach can lead to overrighting (as the warning in the primary documentation points out).
– I do question why a permission of 777 is needed for the map regex file:
/opt/ood/ood_auth_map/bin/ood_auth_map.regex
– Back to OOD_ADMIN_GROUP — what is the relation between the OOD_ADMIN_GROUP and the ‘service accounts’? My interpretation was that OOD_ADMIN_GROUP was a a linux group that didn’t require creating a new set of identities through ‘service accounts’.
[We do actually already have service accounts defined that support accounting our use of ‘sudo’ to elevate privileges.]
I defined the OOD_ADMIN_GROUP variable in /etc/ood/config/apps/dashboard/env:
OOD_ADMIN_GROUP=your_admin_group
Once you have all of files in place, you can always check your /var/log/ondemand-nginx/${USER}/error.log log to verify if the variable is in effect. You will either see:
INFO "Admin group not found, /admin route not added"
or
INFO "Admin group found. Adding admin routes."
Addressing your comments:
Permissions: the mapping regex file gets modified every time by the admin users. You could experiment by making the file owned by whatever group is OOD_ADMIN_GROUP and giving it 770 permissions, but I vaguely recall that most of these files need to have root:root ownership…
The OOD_ADMIN_GROUP is just a POSIX group where the admin users are members. My understanding is that they used the service account approach to protect your original user from being locked out. The roles are like this:
Original user (admin): accesses the impersonation dashboard and fills out the form. Has complete control over the impersonation, and can revert the service account back to itself.
Service account (non-admin): actually becomes the impersonated user.
I am able now to confirm that the group is recognized
INFO “Admin group found. Adding admin routes.”
The logging is still not taking place to /var/log/ood-impersonation.log, so it would appear that the admin route is not being successfully invoked.
However, I am clearly not understanding the role of the service accounts. I’m signed in after identifying my ordinary university account. While we do have service accounts, they are only used within our cluster – they are not identified to the campus identity management for use as signin to OnDemand servers.
Now, proceeding as though having the service accounts is a ‘best practice’, rather than a requirement, I find that the admin view is not accessible. I have the extended view for the impersonation at
/etc/ood/config/apps/dashboard/views/index.html.erb
When I attempt to access admin capability by editing the url https://ondemand01.case.edu/pun/sys/dashboard/admin
You can set the pattern to be whatever you want. If you look at the mapping regex script, you’ll see where you can set the pattern and declare who the authorized users are. The service accounts do not need to be in OOD_ADMIN_GROUP, only the regular accounts.
Of course you don’t have to follow this approach at all. If you already have a service account that you can use for testing, you can simply hard-code that name in the mapping script and it will work just fine while you develop a longer-term strategy.
Note that you will have to log in to OOD with both your regular user and the service account.
The time consuming step here will be adapting our authentication to accept the service accounts. The default method runs through campus SSO, so I can look whether there is greater flexibility than I am aware, or if using CAS we fork the method such that the service accounts authenticate within our HPC ldap, where we have control over the naming structure.
I will try to not lose track of this in the coming days…
Hi Em: I requested guest accounts for my team with our own pattern (think oodservice${user}@school.edu). Then we just made those users on the cluster and it all worked as expected with our Google SSO!