On 21.12.22 08:59, Alexander Bokovoy via FreeIPA-users wrote:
>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.
What we do is fetching the external (Active Directory) admin group for
a specific host from an external database and write it in a host's
class field. This field is used for an automembership rule that allows
(HBAC) all group members to access that particular host.
This concept could easily be customized to allow a single user only
and give it sudo permissions.
Yep, as one of examples of a custom use of IPA-provided attributes.
Adding Ranbir's usage as a default logic would break the one that your
organization developed.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland