{"id":2755,"date":"2024-07-26T14:19:25","date_gmt":"2024-07-26T14:19:25","guid":{"rendered":"https:\/\/blog.samarthya.me\/wps\/?p=2755"},"modified":"2024-07-26T18:55:21","modified_gmt":"2024-07-26T18:55:21","slug":"ansible-privilege-escalation","status":"publish","type":"post","link":"https:\/\/blog.samarthya.me\/wps\/2024\/07\/26\/ansible-privilege-escalation\/","title":{"rendered":"Privilege Escalation: How a `remote_user` and a `become_user` works"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

One of its Ansible’s features is the ability to execute tasks with elevated privileges, often necessary for managing system configurations. This process is known as privilege escalation. <\/p>\n\n\n\n

Let’s dive into the details of how privilege escalation works in Ansible<\/code>, how to configure it using different variables, and the best practices for secure and effective use.<\/p>\n\n\n\n

Understanding Privilege Escalation <\/h2>\n\n\n\n

Privilege escalation in Ansible<\/code> refers to the ability to run tasks with higher permissions than the user who initially connects to the remote system. This is crucial for operations that require root or administrator access, such as installing packages, modifying system configurations, or managing services.<\/p>\n\n\n\n

To see all configuration possibilities you can use the following command
ansible-config init --disabled -t all > ansible.cfg<\/code><\/p>Ansible documentation<\/cite><\/blockquote><\/figure>\n\n\n\n

Users in Ansible<\/code> Context<\/h3>\n\n\n\n
    \n
  • user<\/code>: This is the user account on the control machine running Ansible.<\/li>\n\n\n\n
  • remote_user<\/code>: This is the user account on the managed nodes that Ansible connects to via SSH.<\/li>\n\n\n\n
  • become_user<\/code>: This is the user account on the managed nodes to which Ansible escalates privileges.<\/li>\n<\/ul>\n\n\n\n

    Key Variables for Privilege Escalation<\/h3>\n\n\n\n

    Ansible uses several variables to control privilege escalation. Let’s explore each one:<\/p>\n\n\n\n

      \n
    1. become<\/code>: This boolean variable enables or disables privilege escalation.<\/li>\n\n\n\n
    2. become_method<\/code>: Specifies the privilege escalation method (e.g., sudo, su, pbrun).<\/li>\n\n\n\n
    3. become_user<\/code>: Defines the user to become for privilege escalation.<\/li>\n\n\n\n
    4. become_ask_pass<\/code>: Determines whether Ansible<\/code> should prompt for a password.<\/li>\n\n\n\n
    5. become_pass<\/code>: This defines the password for privilege escalation.<\/li>\n\n\n\n
    6. become_pass_file<\/code>: This specifies a file containing the password for privilege escalation.<\/li>\n\n\n\n
    7. become_flags<\/code>: This sets the flags to pass to the privilege escalation command.<\/li>\n<\/ol>\n\n\n\n

      Let’s look at how to configure each of these variables with examples.<\/p>\n\n\n\n

      1. become<\/h4>\n\n\n\n

      The become<\/code> variable is the master switch for privilege escalation. When set to true<\/code>, Ansible will attempt to escalate privileges for the specified tasks.<\/p>\n\n\n\n

      Example:<\/h5>\n\n\n\n
      - name: Install nginx\n  apt:\n    name: nginx\n    state: present\n  become: true<\/code><\/pre>\n\n\n\n
      2. become_method<\/h4>\n\n\n\n
      The become_method<\/code> variable specifies how Ansible should escalate privileges. Common values include:<\/p>\n\n\n\n
        \n
      • sudo<\/li>\n\n\n\n
      • su<\/li>\n\n\n\n
      • pbrun<\/li>\n\n\n\n
      • pfexec<\/li>\n\n\n\n
      • doas<\/li>\n\n\n\n
      • dzdo<\/li>\n\n\n\n
      • ksu<\/li>\n\n\n\n
      • runas<\/li>\n\n\n\n
      • pmrun<\/li>\n<\/ul>\n\n\n\n
        Example:<\/h5>\n\n\n\n
        - name: Restart nginx service\n  service:\n    name: nginx\n    state: restarted\n  become: true\n  become_method: sudo<\/code><\/pre>\n\n\n\n
        3. become_user<\/h4>\n\n\n\n
        The become_user<\/code> variable allows you to specify which user Ansible should become when escalating privileges. This is particularly useful when you need to perform actions as a specific system user.<\/p>\n\n\n\n
        Example:<\/h5>\n\n\n\n
        - name: Create a directory as www-data\n  file:\n    path: \/var\/www\/new_site\n    state: directory\n  become: true\n  become_user: www-data<\/code><\/pre>\n\n\n\n
        4. become_ask_pass<\/h4>\n\n\n\n
        When set to true<\/code>, become_ask_pass<\/code> prompts for a password for privilege escalation. This is useful when you can’t store the sudo password in plain text or when you need to enter it interactively.<\/p>\n\n\n\n
        Example:<\/h5>\n\n\n\n
        [privilege_escalation]\n# (boolean) Toggle to prompt for privilege escalation password.\nbecome_ask_pass=True<\/code><\/pre>\n\n\n\n
        Once it is set and when you execute a playbook you should expect a prompt<\/p>\n\n\n\n
        > ansible-playbook play-one.yml \nBECOME password: <\/code><\/pre>\n\n\n\n
        Combining Variables: Password and Password File Examples<\/h3>\n\n\n\n
        Let’s look at two common scenarios for handling passwords:<\/p>\n\n\n\n
        1. Interactive Password Prompt for the login user (SSH User, remote_user)<\/h4>\n\n\n\n
        Let’s configure ansible.cfg<\/code> with the required properties<\/p>\n\n\n\n
        # (boolean) This controls whether an Ansible playbook should prompt for a login password. If using SSH keys for authentication, you probably do not need to change this setting.\nask_pass=True\n\n# (string) Sets the login user for the target machines\n# When blank it uses the connection plugin's default, normally the user currently executing Ansible.\nremote_user=ruser<\/code><\/pre>\n\n\n\n
        - hosts: all\n  tasks:\n    - name: Run a command as root\n      command: whoami\n      register: who\n    - debug:\n        var: who.stdout<\/code><\/pre>\n\n\n\n
        Now when you run the playbook you should expect a password prompt<\/p>\n\n\n\n
        > ansible-playbook play-two.yml\nSSH password: \n\nPLAY [all] ***************************************************************************************************************************************************************************************************************************************************************************************************************************************************************\n\nTASK [Gathering Facts] ***************************************************************************************************************************************************************************************************************************************************************************************************************************************************\nok: [localhost]\n\nTASK [Run a command as root] *********************************************************************************************************************************************************************************************************************************************************************************************************************************************\nchanged: [localhost]\n\nTASK [debug] *************************************************************************************************************************************************************************************************************************************************************************************************************************************************************\nok: [localhost] => {\n    \"who.stdout\": \"ruser\"\n}\n\nPLAY RECAP ***************************************************************************************************************************************************************************************************************************************************************************************************************************************************************\nlocalhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   \n<\/code><\/pre>\n\n\n\n
        You can configure the password file as well<\/p>\n\n\n\n
        # (boolean) This controls whether an Ansible playbook should prompt for a login password. If using SSH keys for authentication, you probably do not need to change this setting.\nask_pass=False\n\n# (path) The password file to use for the connection plugin. --connection-password-file.\nconnection_password_file=.\/connection.yml<\/code><\/pre>\n\n\n\n
        I added the password information in the local directory and now if you run you should be prompted for password<\/p>\n\n\n\n
        > ansible-playbook play-two.yml\n\nPLAY [all] ***************************************************************************************************************************************************************************************************************************************************************************************************************************************************************\n\nTASK [Gathering Facts] ***************************************************************************************************************************************************************************************************************************************************************************************************************************************************\nok: [localhost]\n\nTASK [Run a command as root] *********************************************************************************************************************************************************************************************************************************************************************************************************************************************\nchanged: [localhost]\n\nTASK [debug] *************************************************************************************************************************************************************************************************************************************************************************************************************************************************************\nok: [localhost] => {\n    \"who.stdout\": \"ruser\"\n}\n\nPLAY RECAP ***************************************************************************************************************************************************************************************************************************************************************************************************************************************************************\nlocalhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   <\/code><\/pre>\n\n\n\n
        Combining with become user now.<\/p>\n\n\n\n
        - hosts: all\n  become: true\n  become_method: sudo\n  tasks:\n    - name: Run a command as root\n      command: whoami\n      register: who\n    - debug:\n        var: who.stdout<\/code><\/pre>\n\n\n\n
        Now when I run with the configuration already defined in sections above.<\/p>\n\n\n\n
        TASK [debug] *************************************************************************************************************************************************************************************************************************************************************************************************************************************************************\nok: [localhost] => {\n    \"who.stdout\": \"root\"\n}<\/code><\/pre>\n\n\n\n
        Who is the ssh login user can be defined in two ways<\/p>\n\n\n\n
          \n
        • remote_user<\/code>: Property in the ansible.cfg<\/li>\n\n\n\n
        • ansible_user<\/code>: Property in the inventory for each host.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
          One of its Ansible’s features is the ability to execute tasks with elevated privileges, often necessary for managing system configurations. This process is known as privilege escalation. Let’s dive into the details of how privilege escalation works in Ansible, how to configure it using different variables, and the best practices for secure and effective use. […]<\/p>\n","protected":false},"author":2,"featured_media":2760,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[299,34],"tags":[],"class_list":["post-2755","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ansible","category-technical"],"_links":{"self":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2755","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/comments?post=2755"}],"version-history":[{"count":12,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2755\/revisions"}],"predecessor-version":[{"id":2778,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2755\/revisions\/2778"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/media\/2760"}],"wp:attachment":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/media?parent=2755"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/categories?post=2755"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/tags?post=2755"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}