Re: [SSSD-users] rocks cluster user mgmt

[Nordgren, Bryce L -FS]

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_Auth.... 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(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.
>
>  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.

rocks cluster user mgmt

[Dmitri Pal]

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_Auth.... 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(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.
> >
> > 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.

rocks cluster user mgmt

[Nordgren, Bryce L -FS]

>  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?
>  
https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/2014-September/06...

I don't even know if they're thinking about Rocks 7 yet, but can see if
there's any interest.




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.

rocks cluster user mgmt

[Nordgren, Bryce L -FS]

>  -----Original Message-----
>  From: sssd-users-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
>  bounces(a)lists.fedorahosted.org] On Behalf Of Nordgren, Bryce L -FS
>  Sent: Thursday, September 25, 2014 4:13 PM
>  To: dpal(a)redhat.com; End-user discussions about the System Security
>  Services Daemon
>  Subject: Re: [SSSD-users] rocks cluster user mgmt
>
>  > 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?
>  
I guess a fundamental question is: how would a FreeIPA/sssd compute cluster handle a
"batch job/queue submission workflow"? For instance, I submit my job now, with
my active ticket. It runs tomorrow, when ticket is expired. Some available GSSAPI
integration hooks in "Son of Grid Engine" are here :
http://arc.liv.ac.uk/repos/hg/sge/source/security/gss/doc/gss_customer.html
What's missing and how would the queueing system need to interact with FreeIPA/sssd?

Interesting conference proceeding from 2001. A little dated, but you can see how they
guided some GSSAPI/Kerberos development in the 2000's.
http://www.sc2001.org/papers/pap.pap192.pdf

Bryce





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.

rocks cluster user mgmt

[Dmitri Pal]

On 09/29/2014 09:54 PM, Nordgren, Bryce L -FS wrote:
> > -----Original Message-----
> > From: sssd-users-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
> > bounces(a)lists.fedorahosted.org] On Behalf Of Nordgren, Bryce L -FS
> > Sent: Thursday, September 25, 2014 4:13 PM
> > To: dpal(a)redhat.com; End-user discussions about the System Security
> > Services Daemon
> > Subject: Re: [SSSD-users] rocks cluster user mgmt
> >
> >> 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?
>  I guess a fundamental question is: how would a FreeIPA/sssd compute cluster handle a
> "batch job/queue submission workflow"? For instance, I submit my job now, with
> my active ticket. It runs tomorrow, when ticket is expired. Some available GSSAPI
> integration hooks in "Son of Grid Engine" are here :
> http://arc.liv.ac.uk/repos/hg/sge/source/security/gss/doc/gss_customer.html
>  What's missing and how would the queueing system need to interact with FreeIPA/sssd?
If I read it right the solution sends TGT around. It does not help when 
TGT would expire before the job is run.
I think GSS proxy is the solution that you want to consider in this case.
You might want to consider some constrained delegation i.e. s4u2proxy 
and s4u2self for this use case.


>  Interesting conference proceeding from 2001. A little dated, but you can see how they
> guided some GSSAPI/Kerberos development in the 2000's.
> http://www.sc2001.org/papers/pap.pap192.pdf
>
>  Bryce
>
>
>
>
>
>  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. 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

rocks cluster user mgmt

[Nordgren, Bryce L -FS]

>  > I guess a fundamental question is: how would a FreeIPA/sssd
> compute
>  > cluster handle a "batch job/queue submission workflow"? For instance,
>  > I submit my job now, with my active ticket. It runs tomorrow, when
>  > ticket is expired. Some available GSSAPI integration hooks in "Son of
>  > Grid Engine" are here :
>  > http://arc.liv.ac.uk/repos/hg/sge/source/security/gss/doc/gss_customer
>  > .html What's missing and how would the queueing system need to
>  > interact with FreeIPA/sssd?
>
>  If I read it right the solution sends TGT around. It does not help when TGT
>  would expire before the job is run.
>  I think GSS proxy is the solution that you want to consider in this case.
>  You might want to consider some constrained delegation i.e. s4u2proxy and
>  s4u2self for this use case.
>  
I agree that it looks like it's sending TGT around, and this exposes the user to the
possibility that the TGT will expire before the job runs.

If I understand GSS proxy right, I provide a keytab with my password in it so that it can
get a TGT as me whenever it wants. The keytab may not be human readable, but it is
directly usable by kinit. This seems too much like typing my passwd into a plain text
file.

I also don't understand how s4u2proxy can be considered "constrained"
delegation, or even really delegation: "The client has no control over whether a
service can delegate on behalf of the user. The client does not request delegation nor
does it pass a forwardable TGT to the service. The client cannot detect that delegation
will be, or has been, performed. If local policy allows the service to perform S4U2proxy
delegation, this delegation is performed solely at the discretion of the service." It
sounds more like identity appropriation to me. Like "su - <username>" by
root.

Of the two, I suspect I'd prefer s4u2proxy if: a] s4u2proxy can acquire a forwardable
TGT; and b] the only thing which can impersonate me is the queue master.

In any case, this is a band-aid, as jobs may run longer than a TGT is valid (say a week or
more).

What if gss-proxy were given a proxy certificate (RFC3820) instead of a keytab file?
PKINIT to the KDC to maintain the TGT. Plusses are that long running jobs could always
have a current TGT. Minuses: same issues as a keytab file; anyone with the proxy can be
me. OTOH, dogtag's secure store could be set up only to release the proxy certificate
to authenticated Kerberos principles (e.g., the gss-proxy services). I'm sort of
liking that. We'd just have to make sure that part of the queue submission process is
the issuing of a proxy certificate for the queue manager to act as me. Users could be sent
a warning if their proxy certificate is going to expire and instructions on how to extend
the proxy. Also want to check to make sure this can be done without fiddling with the
queue manager's internals.




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.

rocks cluster user mgmt

[Dmitri Pal]

On 10/03/2014 06:32 PM, Nordgren, Bryce L -FS wrote:
> >> I guess a fundamental question is: how would a FreeIPA/sssd
> compute
> >> cluster handle a "batch job/queue submission workflow"? For instance,
> >> I submit my job now, with my active ticket. It runs tomorrow, when
> >> ticket is expired. Some available GSSAPI integration hooks in "Son of
> >> Grid Engine" are here :
> >> http://arc.liv.ac.uk/repos/hg/sge/source/security/gss/doc/gss_customer
> >> .html What's missing and how would the queueing system need to
> >> interact with FreeIPA/sssd?
> > If I read it right the solution sends TGT around. It does not help when TGT
> > would expire before the job is run.
> > I think GSS proxy is the solution that you want to consider in this case.
> > You might want to consider some constrained delegation i.e. s4u2proxy and
> > s4u2self for this use case.
>  I agree that it looks like it's sending TGT around, and this exposes the user to the
> possibility that the TGT will expire before the job runs.
>
>  If I understand GSS proxy right, I provide a keytab with my password in it so that it can
> get a TGT as me whenever it wants. The keytab may not be human readable, but it is
> directly usable by kinit. This seems too much like typing my passwd into a plain text
> file. 
You do not give it "your" keytab. It has its own.

>  I also don't understand how s4u2proxy can be considered "constrained"
> delegation, or even really delegation: "The client has no control over whether a
> service can delegate on behalf of the user. The client does not request delegation nor
> does it pass a forwardable TGT to the service. The client cannot detect that delegation
> will be, or has been, performed. If local policy allows the service to perform S4U2proxy
> delegation, this delegation is performed solely at the discretion of the service." It
> sounds more like identity appropriation to me. Like "su - <username>" by
> root. 
No. This is not how it works. S4U2proxy running on service A takes your 
ticket that you sent to service A and asks KDC can I get a ticket to 
service B for this user on user behalf. It is constrained in the terms 
of KDC having all the policies to define the rules which services set A 
can impersonate which users talking to services B. It is constrained by 
these relationships. It is not wild west.

>  Of the two, I suspect I'd prefer s4u2proxy if: a] s4u2proxy can acquire a forwardable
> TGT; and b] the only thing which can impersonate me is the queue master. 
GSS proxy
can be configured to do s4u2proxy and AFAIR it can change the 
user if configured to do so. It has been built for this use case in mind 
Simo would know more.

>  In any case, this is a band-aid, as jobs may run longer than a TGT is valid (say a week
> or more).
>
>  What if gss-proxy were given a proxy certificate (RFC3820) instead of a keytab file?
> PKINIT to the KDC to maintain the TGT. Plusses are that long running jobs could always
> have a current TGT. Minuses: same issues as a keytab file; anyone with the proxy can be
> me. OTOH, dogtag's secure store could be set up only to release the proxy certificate
> to authenticated Kerberos principles (e.g., the gss-proxy services). I'm sort of
> liking that. We'd just have to make sure that part of the queue submission process is
> the issuing of a proxy certificate for the queue manager to act as me. Users could be sent
> a warning if their proxy certificate is going to expire and instructions on how to extend
> the proxy. Also want to check to make sure this can be done without fiddling with the
> queue manager's internals. 
The certificate or keytab are not different from each other so I really 
do not see a point here. Everything that you describe can be done just 
using a keytab.

>  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. 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

rocks cluster user mgmt

[Nordgren, Bryce L -FS]

>  > If I understand GSS proxy right, I provide a keytab with my
> password in it so
>  that it can get a TGT as me whenever it wants. The keytab may not be human
>  readable, but it is directly usable by kinit. This seems too much like typing my
>  passwd into a plain text file.
>
>  You do not give it "your" keytab. It has its own.
>  
Ah. I had to give k5start a keytab with my encrypted password in it. It doesn't have
its own Kerberos identity. How does gss-proxy authenticate as me, then?

>  > I also don't understand how s4u2proxy can be considered
> "constrained"
>  delegation, or even really delegation: "The client has no control over
>  whether a service can delegate on behalf of the user. The client does not
>  request delegation nor does it pass a forwardable TGT to the service. The
>  client cannot detect that delegation will be, or has been, performed. If local
>  policy allows the service to perform S4U2proxy delegation, this delegation is
>  performed solely at the discretion of the service." It sounds more like
>  identity appropriation to me. Like "su - <username>" by root.
>
>  No. This is not how it works. S4U2proxy running on service A takes your ticket
>  that you sent to service A and asks KDC can I get a ticket to service B for this
>  user on user behalf. It is constrained in the terms of KDC having all the
>  policies to define the rules which services set A can impersonate which users
>  talking to services B. It is constrained by these relationships. It is not wild
>  west.
>  
Wouldn't my service ticket expire at the same time my TGT does? How does this help me
make sure my ticket stays valid for the life of my long lived process?

The part in quotes was from the Microsoft website explaining how s4u2proxy works. Bullet
#1 (not quoted), seems to say the opposite of the above. The verbatim quote is from the
fourth bullet point, here:

http://msdn.microsoft.com/en-us/library/cc246079.aspx

I would be very happy to learn that this is a mistake, but their page is clear to the
point of being emphatic.

>  The certificate or keytab are not different from each other so I
> really
>  do not see a point here. Everything that you describe can be done just
>  using a keytab.
>  
Ah, so we're back to "what's in the keytab?" If it's gss-proxy's
keytab, what does it have to do with me? How does my identity get delegated?

In any case, keytabs are long term secrets (for users or services), and proxy certificates
are not. If I'm going to give something access to my identity, I don't want to be
giving it my long term secret (password), but I do want to give it _something_! It's
also my understanding that DogTag is set up to securely store certificates, controlling
their release to authorized parties. I am not aware of a similar service for keytabs.




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.

rocks cluster user mgmt

[Dmitri Pal]

On 10/03/2014 07:23 PM, Nordgren, Bryce L -FS wrote:
> >> If I understand GSS proxy right, I provide a keytab with my password in it so
> > that it can get a TGT as me whenever it wants. The keytab may not be human
> > readable, but it is directly usable by kinit. This seems too much like typing my
> > passwd into a plain text file.
> >
> > You do not give it "your" keytab. It has its own.
>  Ah. I had to give k5start a keytab with my encrypted password in it. It doesn't have
> its own Kerberos identity. How does gss-proxy authenticate as me, then?
>
> >> I also don't understand how s4u2proxy can be considered
> "constrained"
> > delegation, or even really delegation: "The client has no control over
> > whether a service can delegate on behalf of the user. The client does not
> > request delegation nor does it pass a forwardable TGT to the service. The
> > client cannot detect that delegation will be, or has been, performed. If local
> > policy allows the service to perform S4U2proxy delegation, this delegation is
> > performed solely at the discretion of the service." It sounds more like
> > identity appropriation to me. Like "su - <username>" by root.
> >
> > No. This is not how it works. S4U2proxy running on service A takes your ticket
> > that you sent to service A and asks KDC can I get a ticket to service B for this
> > user on user behalf. It is constrained in the terms of KDC having all the
> > policies to define the rules which services set A can impersonate which users
> > talking to services B. It is constrained by these relationships. It is not wild
> > west.
>  Wouldn't my service ticket expire at the same time my TGT does? How does this help me
> make sure my ticket stays valid for the life of my long lived process?
>
>  The part in quotes was from the Microsoft website explaining how s4u2proxy works. Bullet
> #1 (not quoted), seems to say the opposite of the above. The verbatim quote is from the
> fourth bullet point, here:
>
>  http://msdn.microsoft.com/en-us/library/cc246079.aspx
>
>  I would be very happy to learn that this is a mistake, but their page is clear to the
> point of being emphatic. 
First they talk about S4u2proxy and s4u2self at the same time on the 
same page and it might be a bit confusing.
S4u2proxy works as i described. S4u2self allows a service A to acquire a 
ticket on user's behalf  for itself. This is controlled by central 
policy. Which services can do that for which users.
If them this service can use s4u2proxy then it can impersonate user but 
only for the purposes of working with service B and not in general. User 
does not provide any keys for that.

Yes client does not have any control. It is totally abstracted from the 
client by service A. The whole intent is that the control is between 
configuration of service A and policies on the KDC and client does not 
need to know anything. AMO it is big win not a problem.

> > The certificate or keytab are not different from each other so I
> really
> > do not see a point here. Everything that you describe can be done just
> > using a keytab.
>  Ah, so we're back to "what's in the keytab?" If it's
> gss-proxy's keytab, what does it have to do with me? How does my identity get
> delegated? 
What I was trying to say is that whether you give some one your keytab 
or your pki pair it really does not matter. Then they have them and they 
can do kinit or pkinit on your behalf that would result in the TGT.

In case of S4U you do not give the service the end user keys at all. 
Instead you craft policies on the server side who can impersonate whom 
and for what purpose.
So if you have a controlled environment and there is a job manager that 
is trusted to run the jobs it can also be trusted to get user tickets.
So if you do not have a user ticket or it expired it can do s4u2self and 
then s4u2proxy and launch the job with a fresh ticket.

IPA can manage s4u2proxy but it is not exposed in the UI [1]. I do not 
recall what is the state of the policy management related to su2self. 
may be it is time to file a ticket.

[1] https://fedorahosted.org/freeipa/ticket/3644
>  In any case, keytabs are long term secrets (for users or services), and proxy
> certificates are not. If I'm going to give something access to my identity, I
> don't want to be giving it my long term secret (password), but I do want to give it
> _something_! It's also my understanding that DogTag is set up to securely store
> certificates, controlling their release to authorized parties. I am not aware of a similar
> service for keytabs.
>
>
>
>
>  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. 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

rocks cluster user mgmt

[Nordgren, Bryce L -FS]

>  > I would be very happy to learn that this is a mistake, but their
> page is clear
>  to the point of being emphatic.
>
>  First they talk about S4u2proxy and s4u2self at the same time on the same
>  page and it might be a bit confusing.
>  S4u2proxy works as i described. S4u2self allows a service A to acquire a ticket
>  on user's behalf  for itself. This is controlled by central policy. Which services
>  can do that for which users.
>  If them this service can use s4u2proxy then it can impersonate user but only
>  for the purposes of working with service B and not in general. User does not
>  provide any keys for that.
>
>  Yes client does not have any control. It is totally abstracted from the client by
>  service A. The whole intent is that the control is between configuration of
>  service A and policies on the KDC and client does not need to know anything.
>  AMO it is big win not a problem.
>  
OK, so the default rocks config is that authentication to the compute nodes is handled via
ssh key, and the queue master has access to everyone's private key by virtue of being
a privileged process on the head node.

This proposed situation is functionally similar in that the KDC would be configured to
allow the queue manager to impersonate users as necessary in order to start jobs. The
impersonation can take the form of a forwardable TGT (I hope) which can be used to start
jobs via ssh across the cluster, providing each node access to data on shared
filesystems.

The main improvement is that long term secrets are better protected (publishing home
directories containing private keys to the cluster via NFS w/sec=sys vs. a single
unpublished keytab which unlocks all identities.)

As I understand it put_cred will need to be rewritten to support S4U mechanisms, in case
the job has been queued long enough that the tgt has expired.

A remaining question is "what prevents the tgt/service tickets from expiring during a
running job causing my process to lose access to my shared filesystem"? Would each
compute node need to be running a service which can s4u2self/proxy? Is that service
gss-proxy?

A second barrage of questions: when I was experimenting with PKINIT, the MIT Kerberos KDC
would not issue a TGT unless the user existed in its local database, and the local
database needed to have principals in the local realm. Can you S4U2self/proxy to
impersonate a non-local user without actually creating a cross-realm principal in the
local KDC (e.g., client principal is user/AD.EXAMPLE.COM(a)LOCAL.EXAMPLE.COM)? Can you
S4U2self/proxy to impersonate a user where the user's realm is not local (e.g.
user(a)AD.EXAMPLE.COM)?  The latter is ideal, and maybe necessary to avoid a messy
many-to-one principal to identity mapping (not to mention a fundamental overhaul of
sssd's concept of "domains".)

>  What I was trying to say is that whether you give some one your
> keytab or
>  your pki pair it really does not matter. Then they have them and they can do
>  kinit or pkinit on your behalf that would result in the TGT.
>  
My apologies for obfuscating the difference with my ignorance.

I fear I misspoke when I assumed that one could use the proxy certificate (PC) to PKINIT.
The subject of the PC is a kind of "augmented" user subject (issuer+single
common name element per proxy). [1] A PC is also forbidden to have a
"subjectAltName" [1], which is required by a PKINIT-able kx509 certificate. I
think these PCs are for use with 'GSI-enabled OpenSSH' [2] which is available in
EPEL and Fedora. Kerberos can't use them, but potentially an S4U enabled gateway
service could.

An RFC3280 Proxy Certificate does not expose your private key. The derived keypair (which
is given to the service but which is not exposed to you) is designed to be more similar to
a longish-lived proxiable service ticket than a password/keytab due to its limited
lifetime and embedded constraints. The proxy certificate should spell out the constraints
on the delegation using publicly documented policy languages, whereas providing a keytab
is unconstrained. (The "catch" is that there are no currently defined languages
in the IANA registry [3].) S4U constraints are KDC implementation specific and
not-communicate-able between clusters within a grid (and I suspect they are not embodied
in the ticket either). I do not believe there is a means to translate standardized
constraints in the PC (assuming a policy language is developed) to the Kerberos ticketing
system. For that matter, I do not believe I have seen evidence that Kerberos tickets have
a mechanism to refer to a vocabulary to express constraints. If a gateway were to exist,
it would have to restrict itself to requesting proxiable service tickets for the
particular services delegated in the PC. (Or grant a TGT for the special
"inheritAll" value.)

The question is: Is constraint really necessary, or is delegation all that is required?
The most common use case may be to execute your job as you...Constraining things may just
lead to problems...

The downside, of course, is that a PC is not a Kerberos ticket and doesn't provide
access to a Kerberos-protected NFS export, even when it allows you to login and execute
code. Also, translating from GSI certificates to local identities is a big blank spot on
my mental map. Here there be dragons. Fundamentally I don't want to learn anything
new, I want cluster user management to leverage the same set of tools the rest of my
machines do. :) Like FreeIPA+views/sssd. Add a gateway if you join a grid.

[1] http://www.ietf.org/rfc/rfc3820.txt
[2] http://grid.ncsa.illinois.edu/ssh/
[3] https://www.ietf.org/assignments/proxy-languages/proxy-languages.xml

Thanks,
Bryce




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.

rocks cluster user mgmt

[Nordgren, Bryce L -FS]

More tidbits:

"Globus toolkit 6" implements the grid security infrastructure. [1] It includes
a modified version of openssh (which accepts PKI certificates) and a per-machine
DN-to-local-user mapping file. RPMs have been released for Fedora 19/20 and RHEL/Centos
5,6,7.

As I understand it, grid logins are via proxy certificates which are derived from your
end-entity-certificate and have a limited life. These are managed by myproxy, which can
leverage Kerberos authentication on local identities to control release of keys [2].

Positing a cluster using FreeIPA/sssd for local user management, which is running
GSI-enabled openssh, would sssd have an opportunity to map DNs to local users (and
potentially centralize this mapping by referring to an LDAP server)? Likewise, would sssd
have an opportunity to obtain a Kerberos ticket for the local user via S4Uself/proxy based
on a successful PKI authentication?

Sorry for having this trickle in slowly. I'm playing catchup here.

Bryce

[1] http://toolkit.globus.org/toolkit/docs/6.0/admin/quickstart/#quickstart
[2] http://grid.ncsa.illinois.edu/myproxy/pam.html#krb5




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.

rocks cluster user mgmt

[Dmitri Pal]

On 10/04/2014 06:17 PM, Nordgren, Bryce L -FS wrote:
> >> I would be very happy to learn that this is a mistake, but
> their page is clear
> > to the point of being emphatic.
> >
> > First they talk about S4u2proxy and s4u2self at the same time on the same
> > page and it might be a bit confusing.
> > S4u2proxy works as i described. S4u2self allows a service A to acquire a ticket
> > on user's behalf  for itself. This is controlled by central policy. Which
> services
> > can do that for which users.
> > If them this service can use s4u2proxy then it can impersonate user but only
> > for the purposes of working with service B and not in general. User does not
> > provide any keys for that.
> >
> > Yes client does not have any control. It is totally abstracted from the client by
> > service A. The whole intent is that the control is between configuration of
> > service A and policies on the KDC and client does not need to know anything.
> > AMO it is big win not a problem.
>  OK, so the default rocks config is that authentication to the compute nodes is handled
> via ssh key, and the queue master has access to everyone's private key by virtue of
> being a privileged process on the head node. 
IN case of S4U2self/proxy you do not need to give the master private 
keys to impersonate people. You just need to have a policy saying that 
it can impersonate using its own key. That is the difference.

>  This proposed situation is functionally similar in that the KDC would be configured to
> allow the queue manager to impersonate users as necessary in order to start jobs. The
> impersonation can take the form of a forwardable TGT (I hope) which can be used to start
> jobs via ssh across the cluster, providing each node access to data on shared filesystems.
With S4U2 the TGT is not forwarded. When TGT is forwarded them the 
impersonation is unconstrained. With S4U2 the delegation is constrained 
to impersonate only in relation to the specified target services and not 
anything else.


>  The main improvement is that long term secrets are better protected (publishing home
> directories containing private keys to the cluster via NFS w/sec=sys vs. a single
> unpublished keytab which unlocks all identities.)
>
>  As I understand it put_cred will need to be rewritten to support S4U mechanisms, in case
> the job has been queued long enough that the tgt has expired. 
I think so.

>  A remaining question is "what prevents the tgt/service tickets from expiring during
> a running job causing my process to lose access to my shared filesystem"? Would each
> compute node need to be running a service which can s4u2self/proxy? Is that service
> gss-proxy? 
There are two parts.
First of all gss-proxy helps you with privilege separation and s4u2 part.
Second the kerberos library itself is now capable of acquiring the 
ticket on demand as needed. So even if there is no ticket available 
because it expired the service would be able to conjure one on demand.

>  A second barrage of questions: when I was experimenting with PKINIT, the MIT Kerberos KDC
> would not issue a TGT unless the user existed in its local database, and the local
> database needed to have principals in the local realm. Can you S4U2self/proxy to
> impersonate a non-local user without actually creating a cross-realm principal in the
> local KDC (e.g., client principal is user/AD.EXAMPLE.COM(a)LOCAL.EXAMPLE.COM)? Can you
> S4U2self/proxy to impersonate a user where the user's realm is not local (e.g.
> user(a)AD.EXAMPLE.COM)?  The latter is ideal, and maybe necessary to avoid a messy
> many-to-one principal to identity mapping (not to mention a fundamental overhaul of
> sssd's concept of "domains".) 
I do not think it can. However with some sort of SAML bridging between 
realms it might be able to in future.

For example you have an instance of a service that does file operations 
on your behalf. The file operations are kerberized. The service is a web 
service.
You have user U in realm A and corresponding user in realm B. Realm A is 
the home user realm (AD) and B is the service realm (in this case NFS 
storage realm but OpenStack can be another example).
User hits web interface of the service; service redirects user to IdP; 
IdP is in realm A; it uses kerberos ticket in realm A for IdP to 
authenticate user; IdP creates and assertion and redirects back to 
service; service takes assertion, maps it to account in realm B and does 
s4u2self/proxy on user behalf. No the operation can be complete in realm B.





> > What I was trying to say is that whether you give some one your keytab or
> > your pki pair it really does not matter. Then they have them and they can do
> > kinit or pkinit on your behalf that would result in the TGT.
>  My apologies for obfuscating the difference with my ignorance.
>
>  I fear I misspoke when I assumed that one could use the proxy certificate (PC) to PKINIT.
> The subject of the PC is a kind of "augmented" user subject (issuer+single
> common name element per proxy). [1] A PC is also forbidden to have a
> "subjectAltName" [1], which is required by a PKINIT-able kx509 certificate. I
> think these PCs are for use with 'GSI-enabled OpenSSH' [2] which is available in
> EPEL and Fedora. Kerberos can't use them, but potentially an S4U enabled gateway
> service could.
>
>  An RFC3280 Proxy Certificate does not expose your private key. The derived keypair (which
> is given to the service but which is not exposed to you) is designed to be more similar to
> a longish-lived proxiable service ticket than a password/keytab due to its limited
> lifetime and embedded constraints. The proxy certificate should spell out the constraints
> on the delegation using publicly documented policy languages, whereas providing a keytab
> is unconstrained. (The "catch" is that there are no currently defined languages
> in the IANA registry [3].) S4U constraints are KDC implementation specific and
> not-communicate-able between clusters within a grid (and I suspect they are not embodied
> in the ticket either). I do not believe there is a means to translate standardized
> constraints in the PC (assuming a policy language is developed) to the Kerberos ticketing
> system. For that matter, I do not believe I have seen evidence that Kerberos tickets have
> a mechanism to refer to a vocabulary to express constraints. If a gateway were to exist,
> it would have to restrict itself to requesting proxiable service tickets for the
> particular services delegated in the PC. (Or grant a TGT for the special
> "inheritAll" value.)
>
>  The question is: Is constraint really necessary, or is delegation all that is required?
> The most common use case may be to execute your job as you...Constraining things may just
> lead to problems...
>
>  The downside, of course, is that a PC is not a Kerberos ticket and doesn't provide
> access to a Kerberos-protected NFS export, even when it allows you to login and execute
> code. Also, translating from GSI certificates to local identities is a big blank spot on
> my mental map. Here there be dragons. Fundamentally I don't want to learn anything
> new, I want cluster user management to leverage the same set of tools the rest of my
> machines do. :) Like FreeIPA+views/sssd. Add a gateway if you join a grid.
>
>  [1] http://www.ietf.org/rfc/rfc3820.txt
>  [2] http://grid.ncsa.illinois.edu/ssh/
>  [3] https://www.ietf.org/assignments/proxy-languages/proxy-languages.xml
>
>  Thanks,
>  Bryce
>
>
>
>
>  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. 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.