Become 및 Sudo를 사용하여 Ansible 권한 에스컬레이션 오류 해결

Ansible은 구성 관리, 애플리케이션 배포 및 서버 플릿 전반의 작업 오케스트레이션을 간소화하는 강력한 자동화 엔진입니다. 그러나 신규 및 숙련된 사용자가 직면하는 가장 흔한 문제 중 하나는 권한 에스컬레이션 오류를 처리하는 것입니다. 이러한 문제는 Ansible이 패키지 설치, 시스템 파일 수정 또는 서비스 관리와 같이 높은 권한을 요구하는 작업을 수행하려고 할 때 종종 "권한 거부" 메시지로 나타납니다.

이 포괄적인 가이드는 Ansible의 become 메커니즘의 복잡한 부분, sudo와의 통합을 통한 권한 에스컬레이션 방법, 그리고 관련 인증 문제를 진단하고 해결하기 위한 실행 가능한 단계를 안내합니다. 이러한 설정을 이해하고 올바르게 구성함으로써 대상 시스템의 접근 요구 사항에 관계없이 Ansible 플레이북이 원활하고 안전하게 실행되도록 할 수 있습니다.

Ansible의 become 메커니즘 이해

핵심적으로 Ansible은 일반적으로 SSH를 통해 대상 호스트에 연결하고 원격 사용자로 명령을 실행하여 작동합니다. 그러나 많은 관리 작업은 높은 권한(예: Linux 시스템의 root 접근 권한)을 요구합니다. 이때 Ansible의 become 기능이 작동합니다. become 메커니즘을 통해 Ansible은 다른 사용자, 일반적으로 root가 되어 높은 권한으로 특정 작업이나 전체 플레이를 실행할 수 있습니다.

become이 필요한 이유

모든 Ansible 작업을 root 사용자로 직접 실행하는 것은 일반적으로 좋지 않은 보안 관행입니다. 대신, 원격 호스트에 일반적인 비특권 사용자(종종 ansible_user라고 불림)로 연결한 다음, become을 사용하여 필요한 작업에 대해 임시로 권한을 에스컬레이션합니다. 이는 최소 권한 원칙을 준수하여 보안 침해의 잠재적 영향을 최소화합니다.

become 메서드

Ansible은 여러 권한 에스컬레이션 메서드를 지원하며, 각 메서드는 다른 시스템 유틸리티에 해당합니다. 특히 Linux/Unix 시스템에서 가장 일반적이고 널리 사용되는 메서드는 sudo (Substitute User Do)입니다. 다른 메서드로는 su, pbrun, doas 등이 있지만, 이 가이드에서는 sudo의 보편성 때문에 주로 sudo에 초점을 맞출 것입니다.

Ansible에서 become 설정 구성

Ansible은 전역 구성부터 작업별 재정의까지 become 설정을 구성하는 여러 가지 방법을 제공합니다. 이러한 범위를 이해하는 것은 효과적인 권한 관리에 중요합니다.

1. ansible.cfg의 전역 구성

많은 플레이북에 걸쳐 일반적인 사용 사례의 경우, ansible.cfg 파일에서 기본 become 매개변수를 설정할 수 있습니다. 이 파일은 일반적으로 Ansible을 실행하는 디렉토리, 즉 ~/.ansible.cfg 또는 /etc/ansible/ansible.cfg에서 찾을 수 있습니다.

# ansible.cfg
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False ; Ansible이 암호를 묻도록 하려면 True로 설정

• become=True: 모든 플레이에 대해 기본적으로 권한 에스컬레이션을 활성화합니다.
• become_method=sudo: sudo를 권한 에스컬레이션 메서드로 지정합니다.
• become_user=root: root를 대상으로 될 사용자로 지정합니다.
• become_ask_pass=False: Ansible이 become 암호를 물어야 하는지 여부를 제어합니다. 다른 방법을 통해 암호를 제공하지 않는 경우 True로 설정합니다.

2. 플레이북 내 플레이 또는 작업별 구성

더 세부적인 제어를 위해 become 설정은 플레이 수준(해당 플레이의 모든 작업에 영향을 미침) 또는 개별 작업 수준에서 플레이북 내에 직접 정의될 수 있습니다.

플레이 수준 구성:

---
- name: Install Nginx with elevated privileges
  hosts: webservers
  become: yes          # 이 플레이의 모든 작업에 대해 become 활성화
  become_user: root
  become_method: sudo

  tasks:
    - name: Ensure Nginx is installed
      ansible.builtin.apt:
        name: nginx
        state: present
      # 이 작업은 sudo를 통해 root로 실행됩니다

    - name: Copy Nginx configuration
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # 이 작업도 sudo를 통해 root로 실행됩니다

작업 수준 구성:

---
- name: Manage files as different users
  hosts: all

  tasks:
    - name: Create a file as the ansible_user (default)
      ansible.builtin.file:
        path: /tmp/unprivileged_file.txt
        state: touch
        mode: '0644'

    - name: Create a root-owned file using become
      ansible.builtin.file:
        path: /root/privileged_file.txt
        state: touch
        mode: '0600'
      become: yes          # 이 작업만 become을 사용합니다
      become_user: root
      become_method: sudo

3. 인벤토리 변수를 통해

become 설정은 Ansible 인벤토리에서도 정의할 수 있으며, 이를 통해 다른 호스트 또는 그룹에 대해 다른 권한 에스컬레이션 전략을 지정할 수 있습니다.

hosts.ini 예시:

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com

[all:vars]
ansible_user=devops_user
ansible_become=true
ansible_become_method=sudo
ansible_become_user=root

여기서 ansible_become, ansible_become_method, ansible_become_user는 become 설정에 해당하는 인벤토리 변수입니다. 이들은 all:vars 수준, 그룹 수준 또는 호스트 수준에서 설정할 수 있습니다.

4. ansible-playbook CLI 인수를 사용하여

빠른 재정의 또는 대화형 실행을 위해 명령줄을 통해 become 매개변수를 직접 전달할 수 있습니다:

• --become 또는 -b: become을 활성화합니다.
• --become-method <METHOD>: become 메서드를 지정합니다 (예: sudo).
• --become-user <USER>: 대상 사용자를 지정합니다 (예: root).
• --ask-become-pass 또는 -K: 실행 중 become 암호를 묻습니다. 이는 테스트에는 유용하지만 일반적으로 자동화에는 적합하지 않습니다.

예시:

ansible-playbook my_playbook.yml --become --become-user root --ask-become-pass

become 사용자를 위한 sudo 권한 확인

Ansible에서 become을 올바르게 구성하는 것은 절반의 작업일 뿐입니다. Ansible이 연결하는 사용자(ansible_user)는 become_user가 되기 위해 대상 호스트에 필요한 sudo 권한을 반드시 가지고 있어야 합니다. 이 설정은 /etc/sudoers 파일 또는 /etc/sudoers.d/ 아래의 파일에서 대상 호스트에 구성됩니다.

sudoers 구성

sudoers 파일은 누가 어떤 명령을 누구의 권한으로 실행할 수 있는지 정의합니다. Ansible 연결 사용자(이 예에서는 devops_user)가 암호 프롬프트 없이 모든 명령을 모든 사용자로 실행할 수 있도록 허용하는 일반적인 항목은 다음과 같습니다:

# /etc/sudoers.d/devops
devops_user ALL=(ALL) NOPASSWD: ALL

설명:

• devops_user: Ansible이 연결하는 사용자 이름 (ansible_user).
• ALL: 이 사용자는 모든 터미널에서 명령을 실행할 수 있습니다.
• (ALL): 이 사용자는 모든 사용자로 명령을 실행할 수 있습니다.
• NOPASSWD:: sudo 작업에 암호가 필요하지 않음을 지정합니다.
• ALL: 이 사용자는 모든 명령을 실행할 수 있습니다.

경고: NOPASSWD: ALL을 부여하면 ansible_user에게 암호 없이 무제한적인 root 접근 권한이 부여되어 심각한 보안 위험이 될 수 있습니다. 정말 필요한 경우에만 사용하고 ansible_user의 자격 증명이 매우 안전한지 확인하십시오. 더 엄격한 보안을 위해 사용자가 실행할 수 있는 정확한 명령 또는 명령 세트를 지정할 수 있습니다.

sudo 접근 확인

플레이북을 실행하기 전에 ansible_user가 대상 호스트에서 sudo 접근 권한을 가지고 있는지 수동으로 확인할 수 있습니다. ansible_user로 호스트에 SSH로 접속하여 다음을 실행하십시오:

# 암호 없이 root로 sudo할 수 있는지 확인
sudo -n whoami

# 암호가 필요한 경우, 프롬프트가 나타납니다. 간단한 명령으로 테스트:
sudo whoami

# 현재 사용자의 sudo 권한 나열:
sudo -l

# 특정 사용자(예: devops_user)의 sudo 권한 나열:
sudo -l -U devops_user

sudo -n whoami가 암호 프롬프트 없이 root를 반환하면 NOPASSWD 구성이 올바를 가능성이 높습니다. 암호를 묻는다면 sudoers 항목에 NOPASSWD가 누락되었거나 잘못 구성되었을 수 있습니다.

권한 에스컬레이션 오류 진단

Ansible은 일반적으로 유익한 오류 메시지를 제공하지만, 권한 관련 문제는 때때로 모호할 수 있습니다. 다음은 일반적인 오류와 그 해결책입니다:

1. "permission denied" 또는