On Пт, 16 дек 2022, Matthew Miller wrote:
On Thu, Dec 15, 2022 at 10:42:28AM +0200, Alexander Bokovoy wrote:
>However, this would be approximately one billion times easier if I didn't
>need to worry about the hard part of automating something with fasjson,
>which is keeping a kerberos ticket fresh from a keytab. (I'd love to run my
>whole thing as a function-as-a-service function.)
Why do you consider this as a 'hard thing'?
If you are using GSSAPI, e.g. python-gssapi, you can rely on automated
ticket acquisition provided by the GSSAPI library from MIT Kerberos.
export KRB5CCNAME=/path/to/ccache
export KRB5_CLIENT_KTNAME=/path/to/keytab
.. run your code ..
That's all.
Huh. All of the documentation I found suggested that there needed to be a
sidecar container ... and a bunch of complication. For example:
https://cloud.redhat.com/blog/kerberos-sidecar-container
Yeah, that's not really needed in a simple use case. I would also say
that this approach is outdated, does not use technology we already have
in RHEL and Fedora for years (gssproxy/GSSAPI) and also ignores our
standard Kerberos environment features provided by FreeIPA.
So, if I provide the keytab as a secret, set the above environment
variables, and use requests-gssapi, it should just work? (And, does it
matter where ccache points?)
Since I myself don't use a containerized deployment like you do, please
help me to help you by trying this configuration and reporting back what
you see.
Setting a particular ccache is helpful for containerized runs because
some ccache collection types do not support namespacing and will leak
your ccache content to the host and to other containers. Since you don't
control those components, it is better to be explicit in your
configuration. Using a tmpfs-based volume to point a ccache at is
probably a good idea too, it will be automatically recycled after
container instance is teared away.
--
/ Alexander Bokovoy
_______________________________________________
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
