소개
관리형 노드에 대한 액세스는 Ansible 자동화의 기초입니다. 실제 환경에서 Ansible 은 일반적으로 SSH 를 통해 연결하며 관리 작업을 위해 권한 상승 (privilege escalation) 을 사용합니다.
이 실습에서는 rhce_node라는 일회용 관리형 사용자를 생성합니다. SSH 키를 생성하고 해당 사용자에 대해 인증하며, 인벤토리 액세스를 구성하고 일반 SSH 실행 및 become 액세스를 모두 검증합니다.
SSH 실습 프로젝트 생성
이 단계에서는 프로젝트 디렉터리를 생성하고 SSH 기반 액세스를 위한 Ansible 기본 설정을 구성합니다. 관리형 계정은 이미 존재하지만, 아직 사용자의 키를 신뢰하지 않는 상태입니다.
프로젝트를 생성하고 해당 디렉터리로 이동합니다.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,keys,playbooks}
cd rhce-ansible
ansible.cfg 파일을 생성합니다.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
interpreter_python = auto_silent
EOF
이 프로젝트는 실습 후반부에 127.0.0.1에 대한 실제 SSH 연결을 사용합니다. keys 디렉터리는 실습용 키 쌍을 일반 ~/.ssh 파일과 분리하여 보관하며, host_key_checking = False 설정은 제어된 로컬 실습 중에 대화형 프롬프트가 나타나는 것을 방지합니다.
SSH 키 쌍 생성
이 단계에서는 Ed25519 SSH 키 쌍을 생성합니다. 개인 키 (private key) 는 keys/rhce_ed25519에 유지되며, 공개 키 (public key) 는 관리형 계정에 안전하게 설치할 수 있습니다. -N '' 옵션은 실습 자동화를 위해 암호 (passphrase) 가 없는 키를 생성합니다.
이 단계의 명령을 실행하기 전에 Ansible 프로젝트 디렉터리로 돌아오십시오. 이렇게 하면 LabEx 가 각 단계를 개별적으로 실행하더라도 명령이 안정적으로 유지됩니다.
cd /home/labex/project/rhce-ansible
키 쌍을 생성합니다.
ssh-keygen -t ed25519 -f keys/rhce_ed25519 -N '' -C rhce-ansible-lab
이 명령은 두 개의 파일을 생성합니다. keys/rhce_ed25519는 개인 키이므로 반드시 비공개로 유지해야 하며, keys/rhce_ed25519.pub는 관리형 사용자의 계정에 설치할 수 있는 공개 키입니다.
공개 키를 확인합니다.
cat keys/rhce_ed25519.pub
공개 키 라인은 ssh-ed25519로 시작하고 rhce-ansible-lab이라는 주석으로 끝나야 합니다. 개인 키가 아닌 이 공개 키를 authorized_keys에 복사하게 됩니다.
관리형 사용자에 대한 키 인증
이 단계에서는 일회용 관리형 사용자를 위한 공개 키를 설치합니다. labex 사용자에 대한 LabEx SSH 액세스를 변경하는 것이 아니라, 이번 실습을 위해 rhce_node를 준비하는 과정입니다.
이 단계의 명령을 실행하기 전에 Ansible 프로젝트 디렉터리로 돌아오십시오.
cd /home/labex/project/rhce-ansible
관리형 사용자의 .ssh 디렉터리를 생성합니다.
sudo mkdir -p /home/rhce_node/.ssh
SSH 는 사용자의 .ssh 디렉터리에서 신뢰할 수 있는 공개 키를 찾습니다. 해당 디렉터리가 다른 사용자의 홈 디렉터리 아래에 있으므로 여기서 sudo가 필요합니다.
공개 키를 authorized_keys로 설치합니다.
sudo cp keys/rhce_ed25519.pub /home/rhce_node/.ssh/authorized_keys
소유권과 권한을 수정합니다. SSH 는 디렉터리나 파일의 권한이 너무 개방되어 있으면 키 사용을 거부합니다.
sudo chown -R rhce_node:rhce_node /home/rhce_node/.ssh
sudo chmod 700 /home/rhce_node/.ssh
sudo chmod 600 /home/rhce_node/.ssh/authorized_keys
권한 값은 의도적으로 설정되었습니다. 700은 rhce_node만 .ssh 디렉터리에 액세스할 수 있게 하며, 600은 해당 사용자만 authorized_keys를 읽거나 쓸 수 있게 합니다. 이러한 검사는 로그인 정보가 실수로 노출되는 것을 방지합니다.
SSH 액세스를 위한 인벤토리 구성
이 단계에서는 Ansible 이 로컬 호스트에서 SSH 를 통해 관리형 사용자에 연결하는 방법을 알려주는 인벤토리 항목을 생성합니다.
이 단계의 명령을 실행하기 전에 Ansible 프로젝트 디렉터리로 돌아오십시오.
cd /home/labex/project/rhce-ansible
인벤토리 파일을 작성합니다.
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_host=127.0.0.1 ansible_user=rhce_node ansible_ssh_private_key_file=/home/labex/project/rhce-ansible/keys/rhce_ed25519
EOF
이 인벤토리 라인은 Ansible 이름과 연결 세부 정보를 구분합니다. node1은 인벤토리 별칭이며, ansible_host는 연결할 주소, ansible_user는 원격 계정, ansible_ssh_private_key_file은 개인 키를 가리킵니다.
Ansible 을 사용하기 전에 SSH 를 직접 테스트합니다.
ssh -i keys/rhce_ed25519 -o StrictHostKeyChecking=no rhce_node@127.0.0.1 'whoami'
명령 결과로 rhce_node가 출력되어야 합니다.
SSH 를 직접 테스트하면 나중에 Ansible 이 실패할 경우 문제의 범위를 좁힐 수 있습니다. 직접 SSH 로그인이 불가능하다면 Ansible 모듈을 문제 해결하기 전에 키, 소유권, 권한 또는 인벤토리 연결 값을 먼저 수정하십시오.
Ansible Ping 및 Become 검증
이 단계에서는 Ansible 연결성과 권한 상승을 테스트합니다. -b 옵션은 become을 의미하며, Ansible 이 관리자 권한으로 모듈을 실행하도록 요청합니다.
이 단계의 명령을 실행하기 전에 Ansible 프로젝트 디렉터리로 돌아오십시오.
cd /home/labex/project/rhce-ansible
SSH 를 통해 Ansible ping 모듈을 실행합니다.
ansible managed -m ansible.builtin.ping
이번에는 ping 모듈이 로컬 연결 바로가기를 사용하지 않습니다. Ansible 은 rhce_node로 연결하여 작은 모듈을 전송하고, Python 으로 실행한 뒤 pong을 반환해야 합니다.
권한 상승을 사용하여 명령을 실행합니다. id -u 명령은 root 로 실행될 때 0을 출력합니다.
ansible managed -b -m ansible.builtin.command -a 'id -u'
-b 플래그는 이 명령에 대해 become을 활성화합니다. 결과에 0이 포함되어 있다면 관리형 사용자가 실습을 위해 생성된 sudoers 규칙을 통해 권한을 상승시킬 수 있음을 증명합니다.
Ansible become 을 사용하여 root 소유의 증명 파일을 작성합니다.
ansible managed -b -m ansible.builtin.copy -a 'content=become_ready dest=/etc/rhce-ansible-become.txt mode=0644'
/etc 아래에 파일을 작성하려면 관리자 권한이 필요하므로, 이 마지막 명령은 단순한 연결성 이상의 것을 증명합니다. 이는 Ansible 이 SSH 를 통해 연결할 수 있을 뿐만 아니라, 요청 시 권한이 필요한 시스템 변경을 수행할 수 있음을 확인시켜 줍니다.
요약
SSH 키 쌍을 생성하고, 일회용 관리형 사용자에 대해 인증하며, SSH 기반 인벤토리 액세스를 구성하고, Ansible become을 사용하여 권한 상승을 검증했습니다.
