[SSSD-users] rocks cluster user mgmt

Dmitri Pal dpal at redhat.com
Thu Sep 25 19:44:54 UTC 2014


On 09/25/2014 02:44 PM, Nordgren, Bryce L -FS wrote:
> This is kind of a tangent, as we're moving off into discussing authentication solutions for rocks, so I renamed the thread.
>
>> Wouldn't using constrained delegation (s4u2proxy) + HBAC would be a better
>> solution for this use case?
>> Then you do not need to manage SSH keys. You would need to define which
>> hosts are allowed to be "gateways" and make sure it is complemented by
>> corresponding HBAC policies.
> Proud to say that's a question for the rocks developers. This rocks user is not going to be retooling anything. Guidance on how to join the cluster to AD is here: https://wiki.rocksclusters.org/wiki/index.php/Configuring_Windows_AD_Authentication. It involves samba, winbind, and setting up Kerberos, then syncing those files to all the compute nodes. The headnode is joined to AD, but I don't think the compute nodes are (they don't have a presence on the network AD can see, so what would their host/fqdn at AD.REALM be?) I don't see them setting up a KDC on the headnode. Long story short, I think the headnode will kinit to AD, jobs are still run by using SSH key, and compute nodes have the option of allowing users to authenticate via SSH key or kinit, but SSO shouldn't work. (haven't tried it, tho so I may have missed something)
>
> A likely first step would be to run IdM on the headnode (or a dedicated service node) to manage all the compute nodes, import the AD users via trust and get SSO working. At this stage, you'll figure out if there's issues with people's favorite clustering filesystem, queue manager, or the MPI libraries. Worry about constraints and such later on....if they were to attempt it at all.
>
> Unless HBAC is a lot more dynamic than I think it is, it's unlikely to be useful. The rules would really need to be under control of the queueing system, since that is the entity which dispatches jobs to the cluster.
>
> My understanding, though, is that the HPC/grid computing world is pretty heavily invested in PKI rather than Kerberos technologies. (RFC3820 for history and status)
>
>
>> IdM allows to do it now and latest Fedora/RHEL/CentOS should be able to do
>> it now.
>> IdM does not expose the management of the delegation yet (but it can be
>> done using LDAP modify, ugly but possible) but this is being added in 4.1.
>>
>> https://fedorahosted.org/freeipa/ticket/3644
> Current Rocks is based on CentOS/RHEL 5 and 6. It may be when they retool for CentOS/RHEL 7 they will consider it, but I certainly can't speak for them.
>
>
>
>
>
>
> This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
The configs do not talk about SSSD at all. This area definitely requires 
some face lift.
I wounder if they are aware about SSSD and IdM? Any chance someone can 
ask them to consider SSSD and IdM using SSO as you described above?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



More information about the sssd-users mailing list