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.