[Ansible] #3.3 Ansible 기본 - 관리 노드 연결

in Study on Ansible
[Ansible] #3.3 Ansible 기본 - 관리 노드 연결

Ansible 에서 관리 노드 에 연결하는 방식을 알아보자.


1. 관리 노드 연결 개념

기본적으로 노드간의 연결은 SSH 를 사용한다.

1

현재 iac-control1 의 유저는 기본 유저인 vagrant 이다.
따라서 그대로 vagrant 유저로 SSH 연결을 시도한 것이다.
참고로 비밀번호를 물어본다면, 기본 PW인 vagrant 를 입력하면 된다.

다른 사용자로 연결하려면, @ 를 사용할 수 있다.

ssh ubuntu@192.168.56.21

ubuntu 사용자로 접속이 될까?
대답은 ‘No’ 다.
그 이유는, iac-node1 에는 ubuntu 라는 사용자가 없기 때문이다.

또한 위에서 봐서 알겠지만, 기본적인 SSH 인증 방법은 KEY 인증 이 아닌, PASSWORD 인증 이다.

사족으로 PuTTY 를 사용해서 Amazon Linux EC2 에 접속할때 ppk 를 사용해서 접속해본 경험이 있을텐데, 이런게 KEY 인증 이다.
EC2 에 접속한 뒤 설정을 풀어주면 PASSWORD 인증 방식으로 변경도 가능하겠지만, AWS 에서는 기본적으로 KEY 인증 을 사용한다.

sudo id

기본적으로 sudo 를 할 때 PW 를 묻지 않는다.
이를 Passwordless sudo 라고 한다.
이 설정은 /etc/sudoers.d/vagrant 에 있다.
vagrant 사용자이기 때문에 vagrant 파일이 있는 것이다.

파일 내부를 보자.

sudo cat /etc/sudoers.d/vagrant

8

NOPASSWD:ALL 설정이 되어 있으면, sudo 시 패스워드를 묻지 않는다.
만약에 ALL 만 남기고 해당 옵션을 지우면, 그때부터 sudo 를 사용할 때 PW 를 물어본다.
진짜 매번 물어보는건 아니고, 인증이 몇 분 정도는 유지되고 exit 하고 다시 접속하면 PW 를 묻는다.
물론 Default PW 는 ‘vagrant’ 다.

2. 연결 방법 지정

Ansible 제어 노드 는 관리 노드 에 접근하기 위해 기본적으로 OpenSSH 를 사용한다.

  • ssh(기본), WinRM, PSRP(Power Shell Remote Protocol), Local(자기 자신)
  • Docker, Docker-API , Kubectl, OC
  • network_cli
  • AWS Systems Manager(SSM) (이것을 이용해서도 ec2 인스턴스에 접근 가능)
ansible-doc -t connection -l

위 명령어를 입력하면 다양한 연결 방식들을 볼 수 있다.

proxyserver ansible_connection=local

인벤토리 에서 ansible_connection 를 다른 연결 방식으로 지정할 수 있다.
우리는 ssh 를 사용할 것인데다 기본이 ssh 이기 때문에, 별도로 지정하지 않아도 된다.

연결에 대한 Ansible 관련 명령 :

-c CONNECTION
--connection CONNECTION

이렇게도 옵션을 사용해서 지정할 수도 있다.

또한 플레이북 에서는 다음과 같이 지정할 수 있다.

- hosts : webservers
  connection : local

3. 관리 노드 연결 - SSH 인증 방식

SSH 인증 방식은 두 개로 나뉜다.

  • SSH 키 인증 (기본값)
  • SSH 패스워드 인증 : -k 또는 --ask-pass 옵션 사용

자 한 번 명령어로 접근해볼까 ?

ansible mgmt -m ping

2

접근 시 키가 없기 떄문에 인증이 불가능하여 접근이 거부된다.
하지만 ?

ansible mgmt -m ping --ask-pass

3

이렇게 --ask-pass 옵션을 사용하면 비밀번호를 입력받는다 !
이제 비밀번호를 입력하면 접속할 수 있다.

물론 이렇게 접근할 수도 있지만, 접근해야할 노드가 엄청나게 많아질 경우 일일이 패스워드를 입력하는건 사실상 불가능하다.
DevOps 로서 가장 중요한 덕목중 하나가 자동화 인 만큼, 이러한 대화형 형식을 사용하는 것은 바람직하지 않다.
그래서 기본값이 키 인증인 것이다.
패스워드 인증은 불가능하진 않겠지만 자동화하기 힘들고, 보안상 좋지 않다.
절대 사용하지 않도록 하자.

cat ~/.ansible.cfg

ask_pass 를 false 로 해놓았기 때문에 비밀번호를 물어보지 않는다.

keygen

ssh-keygen

4

키를 생성할 때 편의상 모두 비워두고 키를 생성하였다.

ls .ssh/
ssh-copy-id vagrant@192.168.56.21

5

id_rsa 는 프라이빗 키, id_rsa.pub 은 공개 키이다.
키를 복사한 후 ssh 로 접속하면, 비밀번호를 물어보지 않고 접속된다.

ansible mgmt -m ping

7

자 이제 접속이 안되었던 명령어도 제대로 작동이 된다.

4. 관리 노드 연결 - SSH 접속 사용자

지금의 제어 노드와 관리 노드는 모두 vagrant 사용자를 사용하고 있다.
따라서 사용자를 따로 지정하지 않아도 vagrant 로 접속한다.
그런데 만약 다른 사용자로 접속해야 할 경우, 그것을 지정해줘야 한다.

방법은 여러가지가 있다.
뒤에 -u 옵션으로 유저명을 붙이는 방법이 있다.
또한 .ansible.cfg 파일에서 remote_user 의 값을 바꿀 수 있다.
정리하면 아래와 같다.

SSH 접속 사용자 :

  • 현재 사용자(기본값)
  • 다른 사용자 : -u REMOTE_USER 또는 --user REMOTEUSER 옵션 사용
  • .ansible.cfg 파일에서 remote_user 변경

fingerprint

한 번이라도 접속을 하게 되면, ~/.ssh/known_hosts 파일에 호스트 키가 저장된다.

cat ~/.ssh/known_hosts

9

해당 값은 base 64 로 인코딩 되어 있기 때문에 곧바로 알아보기는 어렵지만, 일종의 지문이라고 생각하면 된다.
최초로 다른 시스템에 접속할 때, 항상 이러한 fingerprint 를 체크하게 된다(= 호스트 키 체킹).

이 파일을 한 번 지우고, ssh 연결을 해보자.

rm ~/.ssh/known_hosts
ssh 192.168.56.21

10

자 위와 같이 정말 연결할 것이냐고 묻고, yes 를 입력하면 접속된다.
이제 ~/.ssh/known_hosts 를 확인해보자.
분명히 이전에 지웠던 파일이 생성되었음을 확인할 수 있을 것이다.
node1 에서 exit 하여 control1 으로 다시 가야함을 잊지 말자.

exit
cat ~/.ssh/known_hosts

11

자 이제 다시 ~/.ssh/known_hosts 파일이 생겼음을 알았으며, 해당 파일은 fingerprint 를 수락했을 떄 생성되는 파일임을 알 수 있다.

정리하면 다음과 같다.

호스트 키 확인 :

  • Ansible 은 SSH 접속 대상에 대한 호스트 키 검사가 기본으로 활성화 되어 있음
  • 접속 대상에 대한 호스트 키는 ~/.ssh/known_hosts 파일에 있음
  • 한번이라도 접속한 적이 있으면 등록되어 있음

그런데 문제가 있다.
아무리 최초에 물어본다고 하지만, 이러한 대화형식이 있으면 자동화 에 방해가 된다.
어떻게 해결할 수 있을까?

ssh-keyscan 192.168.56.21

12

ssh-keyscan 을 사용하면, 미리 키를 스캔을 하는것이 가능하다.

내용을 보면, 암호화 방식은 크게 3가지이다.
빨강색은 rsa 알고리즘, 주황색은 ecdsa 알고리즘, ed25519 알고리즘으로 생성된 키이다.
즉, 우리는 방금 ssh-keyscan 으로 대표적인 암호화 방식으로 키를 모두 생성, 스캔했다.

만약에 암호화 방식을 지정해서 키를 생성하고 싶다면, -t CRYPTOGRAPHY 옵션을 지정하면 된다.

ssh-keyscan -t ssh-rsa 192.168.56.21

그러면 rsa 알고리즘으로만 암호화된 키를 생성, 스캔한다.

자, 스캔했다고 끝이 아니다.
스캔한 것은 말 그대로 스캔만 한거고, 이를 저장해야한다.

ssh-keyscan -t ssh-rsa 192.168.56.21 > ~/.ssh/known_hosts

이렇게 rsa 알고리즘으로 암호화된 키를 생성, 스캔한 결과를 ~/.ssh/known_hosts 라는 파일의 내용으로 저장한다.
여기까지 하면 이제 최초 접속을 하더라도, 이미 저장된 호스트 키가 있기 때문에 fingerprint 생성 여부를 묻지 않는다.

지금의 상황은 기존에 ~/.ssh/known_hosts 파일이 없다는 것이 전제이다.
만약 기존에 fingerprint 로 생성된 ~/.ssh/known_hosts 파일이 있다면, 당연하겠지만 위 명령어에서 > 를 >> 로 바꿔주어야 한다.

5. 관리 노드 연결 - 권한 상승

ansible mgmt -m command -a id

13

id 는 node1 에서 vagrant 사용자로 실행되었다.

ansible mgmt -m command -a id -b

14

이번에는 -b 옵션을 사용하였다.
-b 옵션은 --become 과 동일하다.
해당 옵션을 사용하면, 지정된 명령어를 권한 상승 하여 실행한다.

여기서 ~/.ansible.cfg 구성 파일을 보고 가자.

cat ~/.ansible.cfg

15

보면 become 이 false 로 되어있는 것을 알 수 있다.
이것은 기본적으로 권한 상승 이 되어있지 않는 상태로 명령을 실행함을 의미한다.

보통 리눅스 시스템 작업을 할 때 다음 명령어로 root 상태에서 작업을 진행하는 경우가 많다.

sudo -i

하지만 이러다가 실수를 해서 돌이킬 수 없는 상황이 발생한다면 ?
root 관리자는 permission 의 영향을 받지 않는 슈퍼 계정이다.
즉, 실행 권한이 없는 파일도 실행할 수 있고, 읽을 수 없는 파일도 읽을 수 있다는 뜻이다.
그러므로 root 는 제한적으로 사용되어야한다.
관리자 권한이 필요하다면, 그 때 sudo 를 붙여서 사용해야 한다는 뜻이다.
절대로 become 을 true 로 두고 작업하는 일이 없도록 하자.

권한 상승(Become) 방식 :

  • Passwordless sudo(기본값)
  • Password sudo : -K 또는 --ask-become-pass 옵션 사용

Passwordless sudo 설정 방법 :

  • /etc/sudoers.d/<USERNAME> 을 다음과 같이 변경
    • ALL=(ALL) NOPASSWD:ALL

우리는 현재 passwordless sudo 이기 때문에, become_ask_pass 를 false 로 둔다.
안그러면 sudo 를 쓸 때 마다 비밀번호를 물어보게 된다…
이 설정이 가장 노멀한 방식이다.

참고로, 뒤에 -K 를 붙이면 sudo 가 비밀번호를 물어본다.

ansible mgmt -m command -a id --become -K

16

우리는 passwordless sudo 를 사용하고 있기 때문에, sudo 에 비밀번호가 설정되어있지 않다.
따라서 BECOME password 로 공백을 치든, 아무거나 치든 통과된다.

추가로, command 모듈은 보통 last resort , 최후의 수단이라고 불린다.
command 모듈을 첫번째 수단으로 사용하지 말도록 하자.

© 2022. All rights reserved.