1:59 a.m.
On ti, 20 joulu 2022, Ranbir wrote:
On Tue, 2022-12-20 at 08:22 +0200, Alexander Bokovoy via
FreeIPA-users
wrote:
> FreeIPA does not provide generation capabilities in itself. These
> things
> are specific to individual deployments and their logic is impossible
> to
> automate in a generic way without exposing some kind of a general
> purpose language to express it. So we aren't going to implement this
> when all you can do is to use ansible-freeipa to define your logic
> and
> actions already.
I don't understand why it would be so hard. I'll try to explain better
how it might work.
1. 700 users get workstations
2. we put all users into a "workstation" user group
3. an HBAC rule "allow_workstation" is created for the "workstation"
user group to login using the Services sshd, sudo, su, and su-l,
as well as an HBAC Service Group called gnome
4. In the host records for each of the workstations, we select which
user is the "admin" for that workstation.
5. IPA creates internally a Sudo rule for the user and workstation
pair that gives that user "admin" control (i.e. all commands
allowed as root/anyone)
That's it. freeipa would be doing on its own and tracking internally
what we would have to do anyway via ansible or the web UI. Nothing
fancy or complicated. Why would this be difficult to support within
freeipa? I apologize if this is a dumb question. :P
This is not a dumb question, of course. ;) What you describe above is
pretty much what I said is a configuration specific to an individual
deployment. Can you implement an automation in FreeIPA for your use
case? Yes. Should it be implemented by FreeIPA upstream project? I would
say 'no'.
FreeIPA management middleware provides a pluggable core that can be
extended with plugins. Most of functionality you see in IPA CLI or
access over Web UI is provided by the plugins in IPA management
middleware. These plugins can be added externally, in absolute majority
of cases they do not require modifications of IPA core itself.
The plugins need to be written in Python. You can find some examples at
my github account: https://github.com/abbra. A plugin can also amend
actions of other plugins. This means you can add some sort of a plugin
that is run when an action is being done on a different object.
This gives a lot of flexibility that can be used to implement whatever
logic you want to create. However, there is no magic: someone have to
write down the steps to be performed and logically connect them to
actions that would trigger the operation in question.
A description of your requirements above cannot be connected to a
particular action. It looks like you have at least:
- add a user to 'workstation' user group
- select a user as an admin of the workstation
as two definitive actions to be performed before the rest of rules be
created. A workstation is a host but we have no concept of ownership of
hosts for users. There is a machine ownership by other machines ('ipa
host-add-managedby' command), but there is no way to tell that a
particular user 'owns' this machine in the host entry.
Hence, you cannot simply connect a user to machine and then trigger some
action. You would probably need to add some attribute in IPA to hold
this relationship 'user -> machine' which means a new plugin would need
to be created, new LDAP attribute allocated to store it, new commands
added to manage it, etc.
As I said, this all can be done. We did something similar when
integrating FleetCommander desktop management tool with FreeIPA and
SSSD: https://github.com/abbra/freeipa-desktop-profile, design document
is https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Featu...
This was to be able to provide an integrated solution which covered a
specific use case and spanned GNOME, FleetCommander, SSSD, FreeIPA, and
few other projects.
In the case of the FleetCommander's integration we did not need to
automatically create additional HBAC and SUDO rules. Those can be
created as a part of the plugin flow, of course, using internal IPA API.
Most of the API details are now published at
https://freeipa.readthedocs.io/en/latest/api/index.html but for writing
plugins you need to read FreeIPA's source code as well.
However, I do not think this should be part of IPA itself.
FleetCommander plugin, for example, is maintained separately without any
problems. There are other plugins written by different people and
different organizations and not all of them are known to FreeIPA
developers -- we only get to know about stuff that being published
somewhere and asked about on these mailing lists or in an issue tracker.
Now, if you have no people at your organization to implement a plugin to
provide an integrated solution, you can write down the logic you need to
create all additional rules in ansible-freeipa playbooks. This gives a
better way to preserve the logic for administrators and run these
playbooks whenever you need to add a new user. This would be a part of
the life-cycle management flow which typically includes a lot of other
operations, often beyond FreeIPA itself.
Some background info: we have many hundreds of workstations we want
to
bring into our new IPA deployment and new ones are being added all of
the time. I don't want to use local sudo rules and I also don't want to
create sudo rules approaching 1000 in number. Both are dumb solutions,
even with ansible.
You do realize that in order to use SUDO to limit access on the machine
itself, you would need to create SUDO rules anyway, do you? It doesn't
matter where they exist, locally or centrally in IPA, the rules would
need to exist and be maintained. A move of responsibility between who
owns the rules and who creates/removes them does not change the fact
that SUDO requires rules to exist to apply.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland