how bad would it be if we allowed all systems in communishift to get read-only access to fasjson?
I want to sync group membership to Discourse. See one idea for this here: https://pagure.io/fedora-infrastructure/issue/10952
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.)
I get why we require authentication, but since this info is open to anyone who authenticates, it's only one part of our protection. And it occured to me that one needs a FAS account to create something in Communishift anyway. Unless I am missing something (and I might be)... that really offers basically the same protection. So..... would it be possible to just allow-list connections coming from the Communishift nodes?
On 15/12/2022 00:09, Matthew Miller wrote:
I want to sync group membership to Discourse. See one idea for this here: https://pagure.io/fedora-infrastructure/issue/10952
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.)
I get why we require authentication, but since this info is open to anyone who authenticates, it's only one part of our protection. And it occured to me that one needs a FAS account to create something in Communishift anyway. Unless I am missing something (and I might be)... that really offers basically the same protection. So..... would it be possible to just allow-list connections coming from the Communishift nodes?
Well, you know that real data (users/groups/rbac rules/etc) are stored in IPA itself, which isn't reachable directly, reason why fasjson was created. But because fasjson itself doesn't store any credentials, it's just an "application proxy" that will just do the query for you/your app, reason why it needs a kerberos ticket.
That's why all infra services (Fedora and CentOS ones) have a service keytab to query fasjson (and so reflect users/groups membership at various levels)
Trying to open "anonymous" requests through fasjson.fedoraproject.org would then mean that fasjson would need to have a built-in logic about which info it can query and with local kerberos keytab to itself then reach IPA .. I'll let Aurelien comment on that one but iirc that's what they wanted to avoid when they designed fasjson (not store anything ensuring that all ACL checks are done at IPA level and no logic/acl/rbac rule to create in fasjson app itself)
On Thu, Dec 15, 2022 at 07:45:07AM +0100, Fabian Arrotin wrote:
Well, you know that real data (users/groups/rbac rules/etc) are stored in IPA itself, which isn't reachable directly, reason why fasjson was created. But because fasjson itself doesn't store any credentials, it's just an "application proxy" that will just do the query for you/your app, reason why it needs a kerberos ticket.
Ah, thanks. That's definitely a crucial thing I was missing.
On ke, 14 joulu 2022, Matthew Miller wrote:
I want to sync group membership to Discourse. See one idea for this here: https://pagure.io/fedora-infrastructure/issue/10952
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.
fasjson_client documentation gives a way how to configure gssproxy for essentially the same. It may be an overkill for the containers though. https://fasjson-client.readthedocs.io/en/latest/usage.html#authentication
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
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?)
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.
On Fri, Dec 16, 2022 at 11:40:25AM +0200, Alexander Bokovoy wrote:
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.
This does seem to work -- details tk.
infrastructure@lists.fedoraproject.org
-
Alexander Bokovoy -
Fabian Arrotin -
Matthew Miller