On Аўт, 18 лют 2025, Clement Bouvier via FreeIPA-users wrote:
Hello everyone,
I am hitting a current problem because I might misunderstand how to
work different functionnality present on freeIPA.
As an administrator with an user account on freeipa, I can operate with
ansible on different enrolled freeipa hosts in using my kerberos ticket
and using GSSAPIAuthentication with the ssh client. I usually use the
ansible collection freeipa.ansible_freeipa and an admin kerberos ticket
with an GSSAPI authentication on ssh without problem.
However as an administrator, now I would like that my ansible playbook
run inside a pipeline environment in which I would inject a keytab for
authenticating the playbook as a service on IPA. The pipeline is
running on a host not enrolled on the freeIPA domain.
The typical usecase would be that this ansible "service" (this word
might be uncorrect) can enroll an IPA client on a IPA domain.
So I would expect to create a IPA service (let's name it for this
example "ansible" with the principal ansible/[email protected])
not attached to any host. I would expect to create a keytab for this
service and this keytab would be injected in the pipeline task.
I even add this service in a group admin and create a HBAC rule where
the admins group can login on ipaservers with sshd.
Based on this usecase, I got the problem that my service
ansible/mypipeline.test cannot get any ssh connection on a ipaserver in
using the GSSAPI authentication with the ssh client.
I scanned the forum threads like this one:
https://lists.fedorahosted.org/archives/list/[email protected]/thread/44Z4ANXQYKRNTEVNL35BK27X7Q67RVDQ/#44Z4ANXQYKRNTEVNL35BK27X7Q67RVDQ
where the capacity of a FreeIPA service are illustrated (service not
attached to any host and can be added as member of a group).
I would image that the ssh connection with a service cannot work or it
is not supported. Is it the case? The alternative way would be to
create a IPA user named "ansible", request a keytab for this user and
consumme this keytab in my pipeline?
There are two separate actions here:
- login to a system over SSH: requires a valid POSIX user on the target
system (e.g. 'ansible' account)
- authentication against IPA API, does not require a valid POSIX user
anywhere.
You are trying to mix them up in a single usage. I don't think this is
a good approach, generally speaking. I'd suggest to decouple these two
operations, if you can:
- use 'ansible' user to login over SSH and authenticate it with whatever
means you have. SSH keys would work just fine, there is no need to
keep a password in the system for it. Authenticating 'ansible' user
with GSSAPI has a side-effect that you wouldn't obtain a Kerberos
ticket on the target system anyway, unless you delegate credentials.
The latter is not a secure and suggested operation.
- use 'ansible/mypipeline.test' principal to administrate access to IPA
API.
The benefit of this split is that you have a very clear separation of
duties. A possession of 'ansible' account cannot lead to compromise of
the ansible/mypipeline.test principal.
I can be more explicit with an example that I have in my lab but
currently I think that my problem is more on my understanding on the
IPA concepts and how to apply them to my workflow, so what why I am not
so explicit right now.
This is not so much 'IPA concepts'. You are dealing with two separate
realms here: POSIX environment which you access over SSH and an
application-specific endpoints, which you happen to access over IPA API.
They have different requirements. Both can be satisfied with the same
account in IPA, thanks to POSIX properties of IPA users, but it is not
neccessary.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
