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