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:
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(a)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.
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?
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.