On Mon, Jun 12, 2017 at 12:20:38PM +0200, Christian Heimes via FreeIPA-users wrote: > On 2017-06-12 10:50, Florence Blanc-Renaud via FreeIPA-users wrote: > > Hi, > > > > the team is starting investigations regarding the deployment of IPA > > using Ansible, and we would like to get community feedback. Ansible > > already provides a few community-maintained Identity Modules [1] > > allowing to manage users, groups, hosts, hbac rules, roles, sudo rules, > > but in a first phase, we are focusing on IPA client installation. > > > > The command line ipa-client-install is configuring various components > > (hostname, NTP client, IPA client, SSSD, PAM and NSS, Kerberos client + > > host keytab, DNS, ssh, OpenLDAP client, NIS, automount, firefox prefs...) > > Because of this modularity, a possible strategy would be to provide an > > Ansible role for ipaclient, decomposing the installation into reusable > > Ansible parts (kerberos client role, OpenLDAP client etc). > > In order to avoid maintaining 2 different installation mechanisms, we > > could rewrite ipa-client-install so that it internally calls Ansible to > > perform the configuration. Note that this would include a new dependency > > on Ansible, and we need to make sure that this is acceptable, keeping in > > mind that we are not targeting only RHEL and Fedora but also other Linux > > distributions. > > > > Another strategy would be to have Ansible call the current > > ipa-client-install command, but the limitation is that this CLI is not > > idempotent. It exits on error when the host is already configured as an > > IPA client. > > A few community-provided IPA roles (client or server) are already using > > this approach. They can be found in Galaxy [2]. > Thanks for your summary, Flo. > > It sounds like we both agree that the second strategy (simply run > ipa-client-install and catch error) is not the best approach. The > simplistic variant has multiple issues. On the other hand > ipa-client-install does a lot of stuff. I don't think we can deliver a > full replacement in Ansible within the development phase of 4.6 or 4.7. > It may be more feasible to augment the ipa-client-install command and > expose installation steps as subcommands? A check or state subcommand > could be added to get the installation state. > > $ ipa-client-install check > $ ipa-client-install enroll > $ ipa-client-install dns > $ ipa-client-install openldap > $ ipa-client-install ssh-client > ... > > The subcommands and checker could be re-used by puppet, too. What do you > think? > > > My biggest concern is insecure enrollment with username and password. > Every playbook I known -- including my own one -- passes username and > password to the client machine. For Ansible automation, we should not > use admin credentials but rather push for OTP. To make OTP enrollment > work idempotent, multiple steps with extra checks are required. The OTP > approach eliminates the need to delegate GSSAPI to a client machine. > > Example: > > * A->C check if client is IPA enrolled > * A->I check if client has a host entry > * A->I create host entry > * A->I generate OTP for host entry > * A->C enroll client with OTP > > A: Ansible control machine > C: new client machine > I: IPA master > > Regards, > Christian > > > -- > Christian Heimes > Senior Software Engineer, Identity Management and Platform Security > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael > O'Neill, Eric Shander >
> _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Christian, I agree with your proposal. This is IMO the only viable way to support multiple high level approaches to FreeIPA client installation. With this architecture it's easy to keep consistent behaviour, add new instalation path and keep around the old and well known ipa-client-install with all its options. -- David Kupka
signature.asc
Description: PGP signature
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
