Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 35. Using Ansible to configure HBAC and sudo rules in IdM

Configure host-based access control (HBAC) and sudo rules in Identity Management (IdM) to restrict which users can access specific hosts and run privileged commands, enforcing security policies across your IdM environment.

Specifically, use HBAC to define policies that restrict access to hosts based on the following:

  • The user attempting to log in and this user’s groups
  • The host that a user is trying to access and the host groups to which that host belongs
  • The service that is being used to access a host

Configure sudo rules to allow a user to run programs as another user, with different privileges, for example root privileges. In IdM, you can manage sudo rules centrally. You can define sudo rules based on user groups, host groups and command groups, as well as individual users, hosts and commands.

Complete this procedure to ensure the presence of the following HBAC and sudo rules for IdM users:

  • jane can only access host client01.idm.example.com.
  • john can only access host client02.idm.example.com.
  • Members of the admins group, which includes the default admin user as well as the regular alice user, can access any IdM host.

  • Members of the admins group can run sudo with the following commands on any IdM host:

    • /usr/sbin/reboot
    • /usr/bin/less
    • /usr/sbin/setenforce

The following diagram represents the desired configuration described above:

Figure 35.1. IdM HBAC and SUDO rules diagram

An image of IdM users and hosts showing different types of host access and sudo privileges for different users
NOTE
The procedure illustrates the use of an action group that simplifies the use of modules with module_defaults. You can set default values to be applied to all modules of the collection used in a playbook by using the action_group named freeipa.ansible_freeipa.modules. In the example, the IdM administrator password is defined in this way.

Prerequisites

  • On the control node:

    • You are using Ansible version 2.15 or later.
    • You have installed the ansible-freeipa package.
    • The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
    • The example assumes that the secret.yml Ansible vault stores your ipaadmin_password and that you have access to a file that stores the password protecting the secret.yml file.
  • The target node, that is the node on which the freeipa.ansible_freeipa module is executed, is part of the IdM domain as an IdM client, server or replica.
  • The users jane, john and alice exist in IdM. Passwords are configured for these accounts.

Procedure

  1. Create your Ansible playbook file add-hbac-and-sudo-rules-to-idm.yml with the following content: 

    ---
- name: Playbook to manage IPA HBAC and SUDO rules
  hosts: ipaserver
  become: false
  gather_facts: false

  vars_files:
  - /home/<user_name>/MyPlaybooks/secret.yml

  module_defaults:
    group/freeipa.ansible_freeipa.modules:
      ipaadmin_password: "{{ ipaadmin_password }}"

  tasks:
  - name: HBAC Rule for Jane - can log in to client01
    freeipa.ansible_freeipa.ipahbacrule: # Creates the rule
      name: Jane_rule
      hbacsvc:
      - sshd
      - login
      host: # Host name
      - client01.idm.example.com
      user:
      - jane

  - name: HBAC Rule for John - can log in to client02
    freeipa.ansible_freeipa.ipahbacrule: # Creates the rule
      name: john_rule
      hbacsvc:
      - sshd
      - login
      host: # Host name
      - client02.idm.example.com
      user:
      - john

  - name: Add user member alice to group admins
    freeipa.ansible_freeipa.ipagroup:
      name: admins
      action: member
      user:
      - alice

  - name: HBAC Rule for IdM administrators
    freeipa.ansible_freeipa.ipahbacrule: # Rule to allow admins full access
      name: admin_access # Rule name
      servicecat: all # All services
      hostcat: all # All hosts
      group: # User group
      - admins

    - name: Add reboot command to SUDO
      freeipa.ansible_freeipa.ipasudocmd:
        name: /usr/sbin/reboot
        state: present
    - name: Add less command to SUDO
      freeipa.ansible_freeipa.ipasudocmd:
        name: /usr/bin/less
        state: present
    - name: Add setenforce command to SUDO
      freeipa.ansible_freeipa.ipasudocmd:
        name: /usr/sbin/setenforce
        state: present

  - name: Create a SUDO command group
    freeipa.ansible_freeipa.ipasudocmdgroup:
      name: cmd_grp_1
      description: "Group of important commands"
      sudocmd:
      - /usr/sbin/setenforce
      - /usr/bin/less
      - /usr/sbin/reboot
      action: sudocmdgroup
      state: present

  - name: Create a SUDO rule with a SUDO command group
    freeipa.ansible_freeipa.ipasudorule:
      name: sudo_rule_1
      allow_sudocmdgroup:
      - cmd_grp_1
      group: admins
      state: present

  - name: Disable allow_all HBAC Rule
    freeipa.ansible_freeipa.ipahbacrule: # Rule to allow admins full access
      name: allow_all # Rule name
      state: disabled # Disables rule to allow everyone the ability to login

  2. Run the playbook: 

    $ ansible-playbook --vault-password-file=password_file -i inventory add-hbac-and-sudo-rules-to-idm.yml

Verification

  1. Connect to client01 as the jane user: 

    ~]$ ssh jane@client01
Password:

Last login: Fri Aug 11 15:32:18 2023 from 192.168.122.1
[jane@client01 ~]$

    The output verifies that jane has logged in to client01.

  2. Try to connect to client02 as the jane user: 

    ~]$ ssh jane@client02
Password:
Connection closed by 192.168.122.47 port 22

    The output verifies that jane cannot log in to client02.

  3. Connect to client02 as the alice user: 

    ~]$ ssh alice@client02
Password:

Last login: Fri Aug 10 16:13:43 2023 from 192.168.122.1

    The output verifies that alice has logged in to client02.

  4. Try to view the contents of the /etc/sssd/sssd.conf file using less without invoking the superuser privileges: 

    [alice@client02 ~]$ less /etc/sssd/sssd.conf
/etc/sssd/sssd.conf: Permission denied

    The attempt fails as the file is not readable by anyone except the owner of the file, which is root.

  5. Invoke the root privileges to view the contents of the /etc/sssd/sssd.conf file using less: 

    [alice@client02 ~]$ sudo less /etc/sssd/sssd.conf
[sudo] password for alice:

[domain/idm.example.com]

id_provider = ipa
ipa_server_mode = True
[...]

    The output verifies that alice can execute the less command on the /etc/sssd/sssd.conf file.

Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red HatTorna in cima