Ho_use

[Kubernetes] Kubestronaut 후기

IMyoungho — Fri, 27 Sep 2024 20:43:13 +0900

오랜만에 포스팅을 하네요!
드디어 미루고 미뤘던 Kubernetes 자격증을 모두 취득했습니다. 한국에서는 18번째일 것으로 예상됩니다.

Kubestronaut Program

Rocket-power your Kubernetes skills. The Kubestronaut program recognises community leaders who have consistently invested in their ongoing education and grown their skill level with Kubernetes.

www.cncf.io

단순히 가고 싶었던 회사의 우대사항이어서 처음 알게되고, 찾아보니 마크가 멋진 것 같아서 뭐하는데 쓰는건지 알아봤다가,
오토힐링이나 Desired state를 따르는 형태가 신기하기도 하고 앞으로 많이 사용 할 것 같아서 시작했던 kubernetes 자격증을
모두 취득하다니 감회가 새롭네요ㅎㅎ 원래는 자격증에 대해 거부감도 있었는데 시험의 반이상이 hands on인 것도 한몫을 한 것 같습니다.

하나라도 만료되면 Kubestronaut가 불가한데 기존에 취득했던 CKA, CKAD, CKS가 모두 올해말부터 만료되어서 추석을 맞아 급하게 진행했습니다. 아깝잖아요..ㅠ

이왕 자격증 취득을 시작한거 Kubestronaut로 끝을 봐야겠단 생각을 했는데 올해초에 이직을 하면서 여유가 없었고(핑계)
알아보니 KCNA, KCSA는 필기시험이라고 하길래 준비가 어렵지 않을 것 같아서 바로 질렀습니다..ㅎㅎ
집에 오면 졸려서.. 출퇴근시간에 지하철에서 아이패드로 준비했습니다(기존에 kubernetes를 이것저것 다뤄보셨을수록 난이도는 내려갑니다)

* 준비 및 난이도

기존에 CKA, CKS까지 가지고 계신분들은 영어 해석만 잘하신다면 KCNA는 큰어려움 없이 취득할 수 있을 것 같습니다. 추가적으로 보안을 업으로하고계신분들이라면 KCSA도 어려움없이 취득할 것 같습니다.

KCNA에서 준비할 내용을 굳이 찝어본다면, CNCF 관련 문제가 나오는데 모르면 그냥 찍어야하는 문제라..(예를 들어 약어에 대한 의미를 모르면..) 한번씩 만이라도 쓰윽 보면서 이런게있구나 하면 좋을 것 같습니다. + 추가적으로는 kubernetes만 써보셨다면 ArgoCD나 Prometheus, Grafana, GitOps 등이 언제, 어떠한 필요에 의해 사용되는지라도 알고 가셔야 할 것 같습니다(시간이 있으시다면 직접 구축해보시는 걸 추천합니다. 어처피 이중에 적어도 하나는 실무에서 만나게 되실겁니다ㅎㅎ)

KCSA의 경우는 보안쪽으로 집중되어있는 시험이기 때문에 kubernetes 보안 관련 리소스나 정책, 인증과 인가, 그리고 주요 컴포넌트나 Admission Control 등의 동작 순서나 과정 등을 알고 있으면 좋고 추가적으로 기본적인 보안 관련 용어에 대한 알고 있으면 좋을 것 같습니다. 저의 경우에는 보안을 업으로 하고있어서 그런지 많이 들어본 용어들도 있었고, CIS Benchmark 분석(?)도 해봐서 그런지 대부분이 이미 직접 해봤던 것들이라 막상 시험이 엄청 어렵게 느껴지진 않았습니다.

따라서 난이도는 CKAD < (KCNA, CKA, KCSA) < CKS 인 것 같습니다. 가운데 세 개는 사람마다 체감이 달라서 뭉틍그려놨습니다. 너무 어렵게 생각하실 필요는 없을 것 같아요!

자격증이 하나도 없으시다면 CKA부터 따시고 바로 CKAD, CKS까지 하신뒤 맘편하게 필기 자격증을 취득하시는게 좋을 것 같습니다. 어처피 자격증이 중요한게 아니라 내 것으로 만드는게 중요하다고 생각하기때문에 hands on 시험이 더 도움이 될 것 같습니다. 필기시험은 그냥 내가 알고 있는 개념을 확인하는 용도(?)로 응시한다 라고 생각하시면 좋을 것 같아요.

* 후기

필기 자격증인 KCNA, KCSA는 합격하자마자 메일로 합불을 알려줍니다. 메일을 열기전부터 'Congratulations'가 보이면 합격입니다. 자격증 5개를 모두 합격을 하게되면 마지막 자격증 취득 후, 몇 분내로 kubestronaut가 되었다고 메일로 알려줍니다.

저의 경우, 이 다음에 어떻게 해야하는지 몰라서 여기저기 뒤적거리다가 cncf github를 발견하고 직접 제 프로필과 사진을 PR로 올려놓고 기다렸는데.. 그렇게하는게 아니더군요.. 뭔가 이상했지만 엔지니어들에게 이정도는 바랄 수 있다고 생각했던 것 같아요;;ㅎ

그냥 가만히 있으면 며칠내로 안내메일과 함께 구글폼을 보내줍니다. 메일에서 안내해주는데로 구글 폼을 작성해서 제출하면되고, 이때 자켓 사이즈 선택과 자켓을 받을 주소를 입력하게됩니다(언제오려나..)

참고로 구글폼으로 제출한 사진과 프로필은 제일위에 첨부해놓은 사이트에 업로드됩니다(메일 안내상 매주 금요일 또는 주말에 일괄적으로 업데이트를 하시는 것 같아요). 제출사진의 용량과 크기를 꼭 맞춰주세요 올리시는 분이 굉장히 강조하시는 것 같더라구요..

- Kubestronaut 자켓(방수기능도 있는거같아요..ㅎㅎ)

이상으로 후기 끝입니다! 추가적으로 궁금하신게 있으시다면 댓글 부탁드립니다.

[Ansible] 보안설정/모니터링 자동화, Semaphore (스터디 4주차)

IMyoungho — Tue, 13 Feb 2024 14:02:42 +0900

벌써 이번 Gasida Ansible 스터디의 마지막 주차이다. 이번주 주제는 보안설정/모니터링 자동화, Semaphore이다. 보안설정과 관련된 내용은 전직장에서 진행했던 인프라 취약점진단과 연관이 크기때문에 굉장히 친숙했다.

인프라 취약점 진단을 업으로 하시거나 취약점을 조치하는 인프라 담당자, 개발자, 보안담당자 등 관련이 있는 분들은 모든 진단 항목에 사용하는 것은 쉽지 않지만 자신이 처한 환경에서 Ansible 활용이 가능한 선까지는 충분히 편리함을 맛볼 수 있을 것이라고 생각한다.

개인적으로는 대부분의 기업이 SSH Port는 mgmt로 열어놓았을 가능성이 있으므로 어느정도 활용이 가능할 것이라고 생각한다. 특히 나의 보안 컨설팅 경험상 보안팀의 규모가 작은 기업일수록 소수의 인원이 반복작업으로 인해 공수를 많이 뺏기기 때문에 조치라던지 보안설정 등의 대비가 미흡한 경우가 많다. 따라서 Ansible를 이용하여 한번만 잘 만들어 놓는다면 큰 시간적 이득을 볼 것 같다.

Semaphore

- semaphore란 코드관리와 여러사람이 같이 ansible을 관리할 때 사용할 수 있는 오픈소스이다.

Introduction - Semaphore Docs

Semaphore is written in pure Go and available for Windows, macOS and Linux (x64, ARM, ARM64). Semaphore is an open-source project with concise and high-quality code.

docs.semui.co

- semaphore 구축방법

wget https://github.com/ansible-semaphore/semaphore/releases/download/v2.9.45/semaphore_2.9.45_linux_amd64.deb
sudo dpkg -i semaphore_2.9.45_linux_amd64.deb

How to Get Slack Webhook URL | Svix Resoures

Webhooks in Slack offer an easy and direct way to communicate real-time information to Slack from third-party applications. By following these steps you will be able to obtain the Webhook URL for Slack notifications. Let's get started!

www.svix.com

=> 설치 시, Slack 알람과 Slack webhook URL을 등록해주었다. 등록 시, 해당 channel에서 incomming-wehbook이 설정된 것을 확인할 수 있었다(slack wehbook 설정은 위의 URl 참고)

semaphore service --config=./config.json

=> 또한 설정이 완료되면 config.json 파일이 생성되며 해당 파일을 통해 seamphare를 실행해주면 된다.

=> 3000번 포트로 semaphore가 실행중인 것을 확인할 수 있었고 위에서 생성한 계정으로 접속하면 된다.

- project & key 생성

=> project를 생성하고 난 뒤 key store에서 key를 생성해준다. ssh key를 이용할 계정명과 private key값을 복사해주면 된다. key생성에는 3가지 종류가 존재하는데 위와같이 SSH key와 login password, 그리고 none type이 존재한다. none type은 보통 public github 등의 주소를 사용할때와 같이 굳이 나의 인증이 필요없는 경우 종종 사용하게되는 type이다. 스터디에서 진행한 실습에 추가로 git key도 등록해주었다.

- local path뿐만아니라 git repo로도 진행해보고싶어서 별도로 추가를 해주었다. 따라서 git ssh key와 repo를 생성했다.

=> facts와 users Task 모두 정상적으로 성공하게 되었다.

- users task에 변수를 추가해서 진행해보았다(이번엔 local repo 이용)

=> 기존의 cloudneta 뿐만아니라 aws계정까지 생성된 것을 확인할 수 있었다.

# 스터디 도전과제

[+] 해당 도전과제는 모두 동일한 ansible.cfg와 inventory를 사용

cat <<EOT> ansible.cfg
[defaults]
inventory = ./inventory
remote_user = ubuntu
ask_pass = false

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false
EOT

cat <<EOT> inventory
[tnode]
tnode1
tnode2
tnode3
EOT

# 도전과제1

* 최신 Linux 보안 가이드를 검색하여 '계정관리 혹은 파일 디렉터리 관리'에 대한 설정확인 및 보안 설정 플레이북을 작성해보자.

[ 주요정보통신기반시설 U-01 ] root 계정 원격접속제한을 playbook으로 생성

---

- hosts: tnode2
  tasks:
    - name: Check PermitRootLogin Options
      ansible.builtin.shell: cat /etc/ssh/sshd_config | grep -i '^PermitRootLogin' | awk '{print $2}'
      register: permit_root_login_result

    - name: Process based on PermitRootLogin setting
      ansible.builtin.debug:
        msg: "PermitRootLogin is yes"
      when: permit_root_login_result.stdout == "yes"

    - name: Process based on PermitRootLogin setting
      ansible.builtin.debug:
        msg: "PermitRootLogin is no"
      when: permit_root_login_result.stdout == "no"

    - name: Change PermitRootLogin
      ansible.builtin.shell: sed -i 's/^PermitRootLogin yes$/PermitRootLogin no/' /etc/ssh/sshd_config; (cat /etc/ssh/sshd_config | egrep -i '^PermitRootLogin')
      register: result_option
      notify:
        - Print option
        - Service Restart
      when: permit_root_login_result.stdout == "yes" 

  handlers:    
    - name: Print option
      ansible.builtin.debug:
        msg: "After changing option: {{ result_option.stdout_lines }}"

    - name: Service Restart
      ansible.builtin.service:
        name: "sshd"
        state: restarted

=> PermitRootLogin이 no로 변경되었으며 ssh service가 재시작되어 정상 패스워드를 입력해도 root로 로그인할 수 없게 되었다.

# 도전과제2

* 12.1의 수집 결과를 날짜와 시간이 포함된 log 파일 이름으로 저장되게 하고, Crontab을 활용하여 30분 마다 반복 실행 될 수 있게 설정해보자.

[참고] cron의 일정표현을 빠르고 편리하게 확인할 수 있는 페이지

Crontab.guru - The cron schedule expression generator

crontab.guru

- 12.1 수집용 playbook 내용(monitoring_facts.yml)

---
- hosts: tnode
  become: true 
  vars:
    log_directory: /var/log/daily_check

  tasks:
    - name: Print system info
      ansible.builtin.debug:
        msg:
        - "################ Start #####################"
        - "Date: {{ ansible_facts.date_time.date }} {{ ansible_facts.date_time.time }}" 
        - "HostName: {{ ansible_facts.hostname }}"
        - "OS: {{ ansible_facts.distribution }}"
        - "OS Version: {{ ansible_facts.distribution_version }}"
        - "OS Kernel: {{ ansible_facts.kernel }}"
        - "CPU Cores: {{ ansible_facts.processor_vcpus }}"
        - "Memory: {{ ansible_facts.memory_mb.real }}"
        - "Interfaces: {{ ansible_facts.interfaces }}"
        - "IPv4: {{ ansible_facts.all_ipv4_addresses }}"
        - "Devices: {{ ansible_facts.mounts }}"
        - "################# End #######################" 
      register: result

    - name: Create log directory
      ansible.builtin.file:
        path: "{{ log_directory }}"
        state: directory
        mode: '0755'
    
    - name: Print logs to log file
      ansible.builtin.shell: |
        echo "{{ item }}" >> "{{ log_directory }}"/$(date '+%Y%m%d_%H%M').logs
      loop: "{{ result.msg }}"

=> 날짜와 시간이름으로 .log파일 생성되도록 수정 진행

- crontab 진행용 playbook 생성(test.yml)

---

- name: Schedule playbook execution with cron
  hosts: localhost
  become: true 
  tasks:
    - name: Add entry to crontab test
      ansible.builtin.cron:
        name: "Run Ansible playbook every 2 minutes"
        minute: "*/1"
        user: "ubuntu"
        job: "ansible-playbook -i /home/ubuntu/my-ansible/test2/inventory /home/ubuntu/my-ansible/test2/monitoring_facts.yml > error.log"
      notify:
        - Service Restart

  handlers:    
    - name: Service Restart
      ansible.builtin.service:
        name: "cron"
        state: restarted

=> 테스트를 위해 30분이아닌 1분으로 적용, playbook 진행 시, 로그확인을 위해 error.log에 저장되도록 하여서 디버깅을 진행

- crontab 파일 확인(vi로 수정하도록 실행)

export VISUAL=vim; crontab -e

=> 상단에 해당내용이 존재하는지 확인, 없다면 작성해주자.

- playbook 진행

ansible-playbook test.yml

=> 1분뒤 생성되는 error.log파일을 통해 디버깅이 가능하다.

- 로그파일 생성 확인

 for i in {1..3}; do echo ">> tnode$i <<"; ssh tnode$i ls /var/log/daily_check; echo; done

=> 잘동작하는 것을 볼 수 있었다.

# 도전과제3

* 12.2 플레이북에 대상 노드에 ifconfig ens5 정보를 ifconfig.log 파일로 수집 할수 있게 태스크를 추가해보자.

- playbook 생성(monitoring_system.yml)

---

- hosts: tnode
  vars_files: vars_packages.yml

  tasks:
    - name: Install packages on RedHat
      ansible.builtin.dnf:
        name: "{{ item }}"
        state: present
      loop: "{{ packages }}"
      when: ansible_facts.os_family == "RedHat"

    - name: Install packages on Ubuntu
      ansible.builtin.apt:
        name: "{{ item }}"
        state: present
      loop: "{{ packages }}"
      when: ansible_facts.os_family == "Debian"

    - name: Create log directory
      ansible.builtin.file:
        path: "{{ log_directory }}"
        state: directory

    - name: Monitoring ifconfig
      ansible.builtin.shell: |
        {{ item }} >> {{ log_directory }}/ifconfig.log
      loop:
        - ifconfig ens5

- var_packages.yml

---

log_directory: /home/ubuntu/logs
packages:
  - net-tools

=> ifconfig의 경우 net-tools에 속해있으므로 해당 package가 설치될 수 있도록 작성한다(둘다 같음)

- playbook 실행

ansible-playbook monitoring_system.yml

- 생성된 로그파일 ifconfig.log 확인

for i in {1..3}; do echo ">> tnode$i <<"; ssh tnode$i cat logs/ifconfig.log; echo; done

# 도전과제4(수정필요)

* 12.3 앤서블 갤럭시에서 ‘elasticsearch’ 롤을 검색하여 es와 kibana를 tnode2에 설치 후 접속해보자.

Ansible Galaxy

galaxy.ansible.com

ansible-galaxy role install -p test4/ geerlingguy.java
ansible-galaxy role install -p test4/ geerlingguy.elasticsearch
ansible-galaxy role install -p test4/ geerlingguy.kibana

=> 우선 원하는 경로에 elasticsearch role을 설치해주자. 해당 role 이용에는 geerlingguy.java도 사용되므로 설치해주자.

- playbook 정보(test.yml)

- hosts: tnode2
  roles:
    - geerlingguy.java
    - geerlingguy.elasticsearch
    - geerlingguy.kibana

- 외부 접속 허용을 위해 defaults/main.yml의 아래의 내용 수정

=> localhost -> 0.0.0.0으로 수정

- playbook 실행

ansible-playbook test.yml

=> tnode2에 정상적으로 elasticsearch service가 구동중인 것을 확인할 수 있었다.

# 도전과제5

* Ansible로 AWS EC2를 생성해보자 → 책 18챕터-4 혹은 구글링

- Ansible을 통해 AWS 자원에 대해서도 관리가 가능하다.

- AWS SDK(Software Development Kit) 설치 - boto3(python용)

개발자 도구 - AWS에서의 구축을 위한 SDK 및 프로그래밍 도구 키트

닫기 피드백을 제공해 주셔서 감사합니다. 피드백은 AWS 경험을 개선하는 데 도움이 됩니다. 피드백에 대한 자세한 정보를 제공하려면 아래의 피드백 단추를 클릭하세요.

aws.amazon.com

Code Examples - Boto3 1.34.39 documentation

Previous A Sample Tutorial

boto3.amazonaws.com

- python & boto3 설치 진행

sudo apt install python3-pip && sudo pip3 install boto3

- 변수파일 생성(vars.yml)

---

vm_name: test-server
image_id: ami-0382ac14e5f06eb95
instance_type: t3.medium
key_name: k8s-ho
security_group: sg-0d51cf0c124a82c80
region_name: ap-northeast-2
vpc_subnet_id: subnet-0877b12ded9efc29d

- playbook 파일 생성(test.yml)

amazon.aws.ec2_instance module – Create & manage EC2 instances — Ansible Documentation

session_token aliases: aws_session_token, security_token, aws_security_token, access_token string

docs.ansible.com

---

- hosts: localhost
  vars_files: vars.yml
  
  tasks:
    - name: Create ec2 vm
      amazon.aws.ec2_instance:
        name: "{{ vm_name }}"
        image_id: "{{ image_id }}"
        instance_type: "{{ instance_type }}"
        key_name: "{{ key_name }}"
        security_group: "{{ security_group }}"
        network:
          assign_public_ip: true
        region: "{{ region_name }}"
        vpc_subnet_id: "{{ vpc_subnet_id }}"
      register: vm_info

    - name: Print vm information
      ansible.builtin.debug:
        var: vm_info

=> 기존예제는 실행이 안되어서 ansible 예제를 확인해보니 vpc_subnet_id가 없어 추가해주었다.

- ansible-playbook을 통해 생성된 EC2 확인

=> 위에서 설정한대로 생성된 것을 확인할 수 있었다.

[Ansible] 시스템 구축 및 환경 설정 자동화(스터디 3주차)

IMyoungho — Wed, 31 Jan 2024 12:00:34 +0900

3주차는 지금까지 배운 Ansible의 anisble-galaxy, playbook, role, module 등을 이용해 직접 환경구축 및 테스트를 진행했다.

따라서 이번 포스팅에서는 별도로 개념이 추가된 것이 아니므로 활용에 관련된 도전과제만 작성해보았다.

# 도전과제1

* ansible-vault 사용시, AWS SecretManager를 활용해보기

- 우선 ansible-vault create를 통해 암호화할 파일(user_secrert.yml)을 생성한다.

- 나의 경우 파일 암호화에 쓰일 패스워드를 'Password123'으로 했다.

# user_secret.yml
---

user_info:
  - userid: "ansible"
    userpw: "ansiblePw1"
  - userid: "stack"
    userpw: "stackPw1"

=> 해당 파일이 ansible-vault에 의해 암호화 된 것을 확인할 수 있었다.

- Playbook 생성

---

- hosts: all

  # vault로 사용자 계정 관련 변수가 정의된 파일을 임포트하여 사용
  vars_files:
    - user_secret.yml

  tasks:
  # loop 문을 사용하여 user_info의 userid와 userpw 사용
  - name: Create user
    ansible.builtin.user:
      name: "{{ item.userid }}"
      password: "{{ item.userpw | password_hash('sha512', 'mysecret') }}"
      state: present
      shell: /bin/bash
    loop: "{{ user_info }}"

=> 위에서 암호화한 파일의 user id,pw 정보로 계정을 생성하는 Playbook이다.

- ansible-vault encrypt 파일 사용 시, playbook 실행방법

ansible-playbook create-user.yaml --ask-vault-pass

=> 해당 방법은 파일암호화에 사용된 패스워드를 입력하는 옵션인 '--ask-vault-pass'를 사용한 것이다. 하지만 이 방법은 파이프라인 구성이나 자동화 스트립트 등에 사용 시에는 제약이 따라온다. 이를 해결하는 방법은 '--vault-password-file' 옵션을 통해 파일 암호화에 사용된 패스워드를 파일에 작성하여 사용하는 것이다.

AWS Secret Manager

- 하지만 '--vault-password-file' 을 사용하는 방법 역시, 해당 복호화 키 파일의 유출 가능성이 존재하므로 안전한 저장소에서 관리하는 것이 더욱 좋다. 그래서 사용할 수 있는 방법중 하나가 바로 AWS Secret Manager이다.

- aws secretmanager를 통한 secret 생성

cat  << EOF > secret.json
{
    "password": "Password123"
}
EOF

aws secretsmanager create-secret --name  secret-file --secret-string file://secret.json --region ap-northeast-2

=> secret.json에 암호화에 사용될 Key-value 값을 작성한 뒤 해당파일을 인자로 create-secret을 진행하였다.

- 존재하는 Secret name 확인

aws secretsmanager list-secrets --region ap-northeast-2 | jq -r .SecretList[].Name

=> aws-cli나 GUI를 통해 내가 저장한 Secret value를 확인할 수 있었다. 이제 해당 secret을 암호화키로 사용해보자.

- aws secretmanager value 사용

aws secretsmanager get-secret-value --secret-id secret-file --region ap-northeast-2 | jq -r '.SecretString | fromjson | .password'

cat > get-secret.sh << EOF
#!/bin/bash
aws secretsmanager get-secret-value --secret-id secret-file --region ap-northeast-2 | jq -r '.SecretString | fromjson | .password'
EOF

chmod +x get-secrets.sh

ansible-playbook  create-user.yaml --vault-password-file ./get-secret.sh

=> shellscript를 파일로 작성해서 --vault-password-file 인자로 넣어주는 방법 외에 다른 여러 방법으로 시도해보았지만 내가 못하는건지 안되는 것 같다(아시는분 댓글 부탁드립니다)

- 계정 생성 확인

for i in {1..3}; do ssh ubuntu@tnode$i tail -n 2 /etc/passwd; echo;done

=> 정상적으로 생성된 것을 확인할 수 있었다.

# 도전과제2

* Lookups 플러그인을 활용한 playbook를 직접 작성

Lookups — Ansible Documentation

Lookups Lookup plugins retrieve data from outside sources such as files, databases, key/value stores, APIs, and other services. Like all templating, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a look

docs.ansible.com

=> lookup 플러그인은 playbook 내에서 외부 소스(file, db, key/value stores, APIs 등)에 접근하여 그 내용을 playbook내로 가져와서 사용할 수 있게 해주는 역할을 한다(Jinja2 템플릿 언어에 대한 Ansible 전용 확장 기능)

- 랜덤패스워드(문자,숫자,특수문자 3가지조합 + 10자리)를 가진 계정을 생성하는 playbook

---
- hosts: all
  tasks:
    - name: Generate and encrypt password
      set_fact:
        encrypted_password: "{{ lookup('ansible.builtin.password', '/home/ubuntu/my-ansible/pw.txt', chars=['ascii_letters', 'digits', 'punctuation'], length=10) | password_hash('sha512') }}"

    - name: Create user with encrypted password
      ansible.builtin.user:
        name: tmp_user
        comment: temp user
        shell: /bin/bash
        state: present # 삭제시 absent 사용
        password: "{{ encrypted_password }}"
      register: user_creation_result

    - name: Show generated password
      debug:
        var: user_creation_result.ansible_facts.user_password

=> playbook 내에 작성한 것과 같이 10자리의 랜덤패스워드가로 tmp_user가 생성되었고 해당 패스워드는 pw.txt 파일에서 확인할 수 있었다.

# 도전과제 3

* Ubuntu 와 CentOS에 apache http를 설치하는 playbook을 작성(롤/템플릿 사용은 편한대로)

=> centos에도 제대로 동작되는지 확인하기 위해 tnode4를 centos를 생성해주고 /etc/hosts와 inventory 파일에 내용을 추가해주었다. 해당 AMI의 경우 AWS marketplace를 통해 생성했다(실습 후 marketplace 구독취소를 해주었다)

# Roles(apache.http) 생성 및 정보

ansible-galaxy init --init-path ./roles apache.http

- handlers/main.yml

---
# handlers file for apache.http

- name: Start httpd 
  ansible.builtin.service:
    name: httpd
    state: started

- tasks/main.yml

---
# tasks file for apache.http

- name: Import playbook
  ansible.builtin.include_tasks:
    file: "{{ ansible_facts.distribution }}.yml"

- name: Copy index file when Ubuntu
  ansible.builtin.template:
    src: modify.html
    dest: /var/www/html/index.html
  when: ansible_facts.distribution == "Ubuntu"

- name: Copy index file when CentOS
  ansible.builtin.template:
    src: modify.html
    dest: /var/www/html/index.html
  when: ansible_facts.distribution == "CentOS"

- tasks/CentOS.yml

---

- name: Install the latest version of Apache in CentOS
  ansible.builtin.yum:
    name: httpd
    state: present
  notify: Start httpd  
  #when: ansible_facts.distribution == "CentOS"

- tasks/Ubuntu.yml

---

- name: Install the latest version of Apache in Ubuntu
  ansible.builtin.apt:
    name: apache2
    state: present
  #when: ansible_facts.distribution == "Ubuntu"

- templetes/modify.html

<h1> This is Apache server!! </h1>

- playbook.yml

---

- hosts: tnode
  roles:
    - role: apache.http

=> playbook 실행결과 ubuntu, centos에 따라 상이하게 apt, yum으로 apache, httpd package가 설치되었다(해당되지 않는 경우 skip됨을 알 수 있음). 상이하게 적용한 점은 ubuntu의 경우 자동으로 apache service가 실행되었으나 centos의 경우 service를 직접 실행해주어야했으므로 handler를 통해 serivce를 start 시켜주었다.

- 서비스 정상 실행 확인

for i in {1..4}; do ssh tnode$i 'hostname;curl -s 127.0.0.1';echo; done

=> 모든 관리노드에서 설정한 templates/modify.html 내용으로 service가 실행중임을 확인할 수 있었다.

# 도전과제4

* Jinja2 템플릿을 활용한 예시 playbook를 구글링하여 실습 환경에 맞게 구성(내용 추가 및 수정 중)

ansible-galaxy role init --init-path ./roles myrole.nginx

- handlers/main.yml

---
# handlers file for myrole.nginx

- name: Reload daemon
  systemd:
    daemon_reload: yes
- name: Restart nginx
  service:
    name: nginx
    state: restarted

- template/nginx.conf.j2

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 1024;  
}

http {
    sendfile on;
    #tcp_nopush on;
    #tcp_nodelay on;
    keepalive_timeout 65;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    #gzip on;

    server {
        listen 80 default_server;
        listen [::]:80 default_server;
        
        root /var/www/html;
        index index.html index.htm;
        
        server_name _;
        
        location / {
            try_files $uri $uri/ =404;
        }
    }
}

- var/main.yml

---
# vars file for myrole.nginx
user: imyoungho

- tasks/main.yml

---
# tasks file for myrole.nginx

- name: apt update
  apt:
    update_cache: yes

- name: Add User for Nginx
  user:
    name: "{{ user }}"
    shell: /bin/bash
    home: /home/{{ user }}
    createhome: yes

- name: Install Nginx
  apt:
    name: nginx
    state: present

- name: Copy Nginx Configuration
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
  notify:
    - Reload daemon
    - Restart nginx

- playbook file(install_nginx.yml)

---
      
- hosts: tnode3
  vars_files:
    - vars/main.yml
  roles:
    - role: myrole.nginx
      become: yes

# 도전과제5

* file과 lineinfile 모듈을 활용하여 /tmp/test.txt 파일을 생성하고 hello 문자열을 추가하는 playbook 작성

- work.yml

---

- hosts: all
  vars_files: var.yml

  tasks: 
  - name: Create file
    ansible.builtin.file:
      path: "{{ item.filepath }}"
      owner: "{{ item.own }}"
      group: "{{ item.own }}"
      mode: "{{ item.permit }}"
      state: touch
    loop: "{{ fileinfo }}"

  - name: Write String in file
    ansible.builtin.lineinfile:
      path: "{{ item.filepath }}"
      line: "{{ item.string }}"
    loop: "{{ fileinfo }}"

- var.yml

fileinfo:
  - string: hello
    own: ubuntu
    filepath: /tmp/test.txt
    permit: 644
    
  - string: byebye
    own: ubuntu
    filepath: /tmp/test2.txt
    permit: 644

- 결과

for i in {1..3}; do ssh tnode1 ls /tmp/*.txt;echo; done
for i in {1..3}; do ssh tnode1 cat /tmp/*.txt;echo; done

# 도전과제6

* 앤서블 갤럭시에서 PostgreSQL 설치하는 롤을 검색하여, 해당 롤을 통해 tnode3에 설치

Ansible Galaxy

galaxy.ansible.com

* postgreSQL role install

- ansible.cfg file

[defaults]
inventory = ./inventory
remote_user = ubuntu
ask_pass = false
roles_path = ./roles

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

- inventory file

[db]
tnode3

[tnode]
tnode1
tnode2
tnode3

- ansible-galaxy를 통한 role install

Ansible Galaxy

galaxy.ansible.com

ansible-galaxy role install geerlingguy.postgresql

- playbook file (install_postgresql.yml)

- hosts: tnode3
  vars_files:
    - vars/main.yml
  roles:
    - role: geerlingguy.postgresql
      become: yes

- var/main.yml

postgresql_databases:
  - name: imyoungho_db
postgresql_users:
  - name: imyoungho
    password: qwe123

* playbook 실행

ansible-playbook install_postgresql.yml

- postgreSQL 접속

psql -U imyoungho -d imyoungho_db -h localhost -p 5432

=> tnode3에 위에서 설정한 var/main.yml 설정으로 postgresql이 구축되었으며 정상적으로 접속까지 가능한 것을 확인할 수 있었다.

[Ansible] 반복문과 조건문, Roles(스터디 2주차)

IMyoungho — Fri, 19 Jan 2024 17:13:22 +0900

오늘은 스터디 2주차로 주제는 반복문과 조건문, Roles이다.

Ansible의 반복문과 조건문은 의미 그대로 반복이 필요할때 사용하거나 특정조건이 충족되었을 때 사용하도록 할 수 있다.

또한 Ansible Role의 경우 굉장히 유용하다는 생각이 들었다.

똑같다고 할 수는 없지만 디렉토리 구조로 진행되는 과정이 Terraform Module 사용과 비슷하다는 느낌을 받았다.

Ansible 반복문

Variables, Conditionals, Loops - Ansible Handbook

Just like any other Scripting or programming language we can use variable in ansible playbooks. Variables could store different values for different items. Variables help us to have shorter and more readable playbooks. Imagine we want to apply patches on h

borosan.gitbook.io

* 자주 활용하는 module:

- ansible.builtin.service

- ansible.builtin.shell

- ansible.builtin.file

- etc...

* 사용 키워드:

- loop( 반복해야하는 항목의 목록 값을 loop로 사용 )

- item( 해당하는 값 사용 시 item 변수 이용 )

[예제]

- 반복문을 이용해 모든 관리서버의 sshd, rsyslog, httpd의 service가 구동되고있는지 확인해보기로했다.

# 반복문 사용전
---
- hosts: all
  tasks:
    - name: Check sshd state
      ansible.builtin.service:
        name: sshd
        state: started

    - name: Check rsyslog state
      ansible.builtin.service:
        name: rsyslog
        state: started
        
    - name: Check httpd state
      ansible.builtin.service:
        name: httpd
        state: started

# 반복문 사용

---
- hosts: all
  tasks:
    - name: Check sshd state
      ansible.builtin.service:
        name: "{{ item }}"
        state: started
      loop:
        - sshd
        - rsyslog
        - httpd

=> 단순 반복되는 작업을 해야하는 경우 loop를 이용하여 이와 같이 반복되는 작업을 줄일 수 있다.

- 결과

=> 현재 나의 관리서버 환경에는 http daemon이 구동되고 있지 않으므로 다음과 같은 결과를 볼 수 있었다.

[ 도전과제1 ]

- linux user1~10(10명) 를 반복문을 통해서 생성 후 확인 후 삭제를 해보자

---
- hosts: all
  tasks:
    # 생성 시, 사용
    - name: Add user
      ansible.builtin.user: 
        name: "{{ 'test' + item | string }}"
      loop: "{{ range(1, 11) | list }}"
    
    # 삭제 시, 사용
    - name: Delete user
      ansible.builtin.user: 
        name: "{{ 'test' + item | string }}"
        state: absent
      loop: "{{ range(1, 11) | list }}"

ansible -m shell -a "tail -n 10 /etc/passwd" all

=> 해당 playbook 사용 시 test계정 10개가 생성 후 삭제된다(캡쳐화면은 삭제부분 주석처리 후 실행)

[도전과제 2]

- loop 반복문 중 sequence 를 이용하여 /var/log/test1 ~ /var/log/test100 100개 파일(file 모듈)을 생성 확인 후 삭제를 해보자

---
- hosts: all
  tasks:
   - name: show file(s) contents
     ansible.builtin.file:
      path: /var/log/test{{ item }}.log
      mode: '0600'
      state: touch
     with_sequence: start=1 end=100

   # 삭제 시, 사용
   - name: show file(s) contents
     ansible.builtin.file:
      path: /var/log/test{{ item }}.log
      state: absent
     with_sequence: start=1 end=100

=> 100개의 로그파일이 '600'권한으로 생성되었다(위의 playbook 진행 시, 생성 후 삭제됨)

Ansible 조건문

Conditionals — Ansible Documentation

In a playbook, you may want to execute different tasks or have different goals, depending on the value of a fact (data about the remote system), a variable, or the result of a previous task. You may want the value of some variables to depend on the value o

docs.ansible.com

* 사용 키워드:

- when

* 조건 연산자:

!= : 값이 같지 않을 때 참 true
>, >=, <=, < : ‘초과, ‘ 이상’, ‘이하’, ‘미만’ 일 때에 참 true
not : 조건의 부정
and, or : ‘그리고’, ‘또는’의 의미로 여러 조건의 조합 가능
in : 값이 포함된 경우에 참 true. 예를 들어 2 in “1, 2, 3” 은 참 true
is defined : 변수가 정의된 경우 참 true

연산예시	설명
ansible_facts[’machine’] == “x86_64”	ansible_facts[’machine’] 값이 x86_64와 같으면 true
max_memory == 512	max_memory 값이 512와 같다면 true
min_memory https://www.youtube.com/watch?v=u17SmSSQ9rE 128	min_memory 값이 128보다 작으면 true
min_memory > 256	min_memory 값이 256보다 크면 true
min_memory <= 256	min_memory 값이 256보다 작거나 같으면 true
min_memory >= 512	min_memory 값이 512보다 크거나 같으면 true
min_memory != 512	min_memory 값이 512와 같지 않으면 true
min_memory is defined	min_memory 라는 변수가 있으면 true
min_memory is not defined	min_memory 라는 변수가 없으면 true
memory_available	memory 값이 true이며 true, 이때 해당 값이 1이거나 True 또는 yes면 true
not memory_available	memory 값이 false이며 true, 이때 해당 값이 0이거나 False 또는 no면 true
ansible_facts[’distribution’] in supported_distros	ansible_facts[’distribution’]의 값이 supported_distros 라는 변수에 있으면 true

[예제]

- run_my_task 변수의 값이 true일 때만 task가 실행되도록 확인해보았다.

---
- hosts: localhost
  vars:
    run_my_task: true

  tasks:
  - name: echo message
    ansible.builtin.shell: "echo test"
    when: run_my_task
    register: result

  - name: Show result
    ansible.builtin.debug:
      var: result

run_my_task 값이 true 인 경우

run_my_task 값이 false 인 경우

[ 복수조건문 예시 ]

- and나 or을 사용할 수 있다.

---
- hosts: all

  tasks:
    - name: Print os type
      ansible.builtin.debug:
        msg: >-
             OS Type: {{ ansible_facts['distribution'] }}
             Bios_vendor: {{ ansible_facts['bios_vendor'] }}
      when: 
        ( ansible_facts['distribution'] == "Ubuntu" and
          ansible_facts['bios_vendor'] == "Amazon EC2")
       or
        ( ansible_facts['distribution'] == "CentOS" and
          ansible_facts['distribution_version'] == "22.04")

[도전과제 3]

- Ubuntu OS이면서 fqdn으로 tnode1 인 경우, debug 모듈을 사용하여 OS 정보와 fqdn 정보를 출력해보자.

---
- hosts: all
  tasks:
    - name: Node info
      ansible.builtin.debug:
        msg: >-
             fqdn info: {{ ansible_facts['fqdn'] }}
             hostname: {{ ansible_facts['hostname'] }}
             OS Type: {{ ansible_facts['distribution'] }}
      when: 
        - ansible_facts['fqdn'] == "ip-10-10-1-11.ap-northeast-2.compute.internal"
        - ansible_facts['distribution'] == "Ubuntu"

[도전과제 4]

- 반복문+조건문을 함께 사용해보자

Conditionals — Ansible Documentation

docs.ansible.com

---
- hosts: all
  tasks:
    - name: Node info
      ansible.builtin.debug:
        msg: >-
             information: {{ ansible_facts[item] }}
      loop:
        - hostname
        - distribution
      when: ansible_facts['distribution'] == "Ubuntu"

핸들러 및 작업 실패 처리

- 일부 task시, 시스템 변경 후 추가작업이 필요한 상황이 존재(예를 들어, 서비스 구성 파일 변경 후 변경내용 저장을 위한 서비스 재기동)

- 이때 사용할 수 있는 것이 Handler이며 다른 작업에서 트리거한 알림에 응답하는 작업.

- 해당 host에서 작업이 변경될 때만 핸들러에 통지함

- notify문을 이용하여 사용

[예제]

- rsyslog 재시작 task 실행 시, notify 키워드를 통해 print msg라는 handler 호출

---
- hosts: tnode2
  tasks:
    - name: restart rsyslog
      ansible.builtin.service:
        name: "rsyslog"
        state: restarted
      notify:
        - print msg

  handlers:
    - name: print msg
      ansible.builtin.debug:
        msg: "rsyslog is restarted"

[도전과제 5]

- apache2 패키지를 apt 모듈을 통해서 설치 시, 핸들러를 호출하여 service 모듈로 apache2를 재시작 해보자

---
- hosts: tnode3
  tasks:
    - name: Install apache httpd  (state=present is optional)
      ansible.builtin.apt:
        name: apache2
        state: present
      notify:
      - restart apache

  handlers:
    - name: restart apache
      ansible.builtin.service:
        name: "apache2"
        state: restarted

ansible -m shell -a "systemctl status apache2" tnode3

작업 실패 무시

- 일반적으로 Ansible은 task가 실패하면 이후의 모든 task를 건너뛴다.

- 작업이 실패한경우에도 다음 task를 실행하기위해 사용하는 것이 바로 'ignore_errors' 키워드이다.

[예제]

---
- hosts : tnode1

  tasks:
    - name: Install apache3
      ansible.builtin.apt:
        name: apache3
        state: latest

    - name: Print msg
      ansible.builtin.debug:
        msg: "Before task is ignored"

=> 'Install apache3' task 실패로 다음의 'Print msg'가 실행되지 않은 것을 볼 수 있었다.

* Ignore_errors 키워드 사용

---
- hosts : tnode1

  tasks:
    - name: Install apache3
      ansible.builtin.apt:
        name: apache3
        state: latest
      ignore_errors: yes

    - name: Print msg
      ansible.builtin.debug:
        msg: "Before task is ignored"

=> 'Install apache3' task가 실패했지만 다음 task가 정상적으로 동작함을 알 수 있었다.

작업 실패 후 Handler 실행

- 일반적으로 작업이 실패하고 해당 호스트에서 Play가 중단되면 이전 작업에서 알림받은 모든 Handler 역시 실행되지 않는다.

- 작업이 실패하여 Play가 중단되더라도 알림받은 Handler를 호출하는 키워드가 바로 'forece_handlers: yes'이다.

[예제]

---
- hosts: tnode2

  tasks:
    - name: restart rsyslog
      ansible.builtin.service:
        name: "rsyslog"
        state: restarted
      notify:
        - print msg

    - name: install apache3
      ansible.builtin.apt:
        name: "apache3"
        state: latest

  handlers:
    - name: print msg
      ansible.builtin.debug:
        msg: "rsyslog is restarted"

* 'forece_handlers: yes' 키워드 사용

---
- hosts: tnode2
  force_handlers: yes

  tasks:
    - name: restart rsyslog
      ansible.builtin.service:
        name: "rsyslog"
        state: restarted
      notify:
        - print msg

    - name: install apache3
      ansible.builtin.apt:
        name: "apache3"
        state: latest

  handlers:
    - name: print msg
      ansible.builtin.debug:
        msg: "rsyslog is restarted"

=> 실패하였음에도 알림(notify)을 받은 handler가 정상적으로 호출된 것을 볼 수 있었다.

Ansible 블록 및 오류처리

- block 문법을 통해 오류를 제어할 수 있음.

- block은 작업을 논리적으로 그룹화해주며 block을 통해 작업 실행방법을 제어할 수 있음

block : 실행할 기본 작업을 정의함
rescure : block 절에 정의된 작업이 실패할 경우 실행할 작업을 정의함
always : block 및 rescue 절에 정의된 작업의 성공 또는 실패 여부와 관계 없이 항상 실행되는 작업을 정의함

[예제]

---
- hosts: tnode2
  vars:
    logdir: /var/log/daily_log
    logfile: todays.log

  tasks:
    - name: Configure Log Env
      block:
        - name: Find Directory
          ansible.builtin.find:
            paths: "{{ logdir }}"
          register: result
          failed_when: "'Not all paths' in result.msg"

      rescue:
        - name: Make Directory when Not found Directory
          ansible.builtin.file:
            path: "{{ logdir }}"
            state: directory
            mode: '0755'

      always:
        - name: Create File
          ansible.builtin.file:
            path: "{{ logdir }}/{{ logfile }}"
            state: touch
            mode: '0644'

=> block구문 내의 failed_when 구문을 통해 result.msg에서 "Not all paths"가 발견되면 실패로 처리하게되고 실패로 처리시, rescue 구문이 실행됨, 예제에서는 해당 디렉터리가 없는 경우 생성하게됨.

=> always구문의 경우 이름그대로 항상 실행되며 예제에서는 로그파일을 생헝함.

[도전과제 6]

- block rescure always 키워드를 사용한 플레이북을 작성하여 테스트 해보자

Blocks — Ansible Documentation

All tasks in a block inherit directives applied at the block level. Most of what you can apply to a single task (with the exception of loops) can be applied at the block level, so blocks make it much easier to set data or directives common to the tasks. Th

docs.ansible.com

---
- hosts: tnode2
  tasks:
    - name: Mangement user
      block:
        - name: Find user
          ansible.builtin.shell: "cat /etc/passwd | grep test1"
          register: result
          failed_when: '"" in result.msg'

      rescue:
        - name: Add user
          ansible.builtin.user:
            name: test1

      always:
        - name: Create manager user
          ansible.builtin.user:
            name: testuser-manager

        - name: Show result
          ansible.builtin.debug:
            var: result

=> 'test1' 계정이 존재하지않아 block 구문이 실패하였고 failed_when 설정을 통해 rescue 구문이 실행되었다. 따라서 'test1' 계정이 생성되었으며 항상 실행되는 always로 인해 testuser-manager 계정도 생성된 것을 볼 수 있었다(멱등성으로 기존상태 그대로 진행)

Ansible Roles

- Playbook 내용을 기능단위로 나누어 공통 부품으로 관리/재사용하기위한 구조를 의미한다.

- 대규모 프로젝트를 쉽게 관리할 수 있으며 다른 사용자와 동시 개발도 가능해서 굉장히 유용하다.

- 잘 만들어진 Role의 경우 엔서블 갤럭시를 통해 공유하여 다른 사람이 공유한 Role을 사용할 수 있다.

- Playbook에 전달된 변수를 사용할 수 있다(변수 미설정 시 기본값을 Role의 해당 변수에 설정하기도 한다)

Roles — Ansible Documentation

The classic (original) way to use roles is with the roles option for a given play: When you use the roles option at the play level, Ansible treats the roles as static imports and processes them during playbook parsing. Ansible executes each play in this or

docs.ansible.com

* Role의 구조는 다음과 같다.

하위 디렉터리	기능
defaults	이 디렉터리의 main.yml 파일에는 롤이 사용될 때 덮어쓸 수 있는 롤 변수의 기본값이 포함되어 있습니다. 이러한 변수는 우선순위가 낮으며 플레이에서 변경할 수 있습니다.
files	이 디렉터리에는 롤 작업에서 참조한 정적 파일이 있습니다.
handlers	이 디렉터리의 main.yml 파일에는 롤의 핸들러 정의가 포함되어 있습니다.
meta	이 디렉터리의 main.yml 파일에는 작성자, 라이센스, 플랫폼 및 옵션, 롤 종속성을 포함한 롤에 대한 정보가 들어 있습니다.
tasks	이 디렉터리의 main.yml 파일에는 롤의 작업 정의가 포함되어 있습니다.
templates	이 디렉터리에는 롤 작업에서 참조할 Jinja2 템플릿이 있습니다.
tests	이 디렉터리에는 롤을 테스트하는 데 사용할 수 있는 인벤토리와 test.yml 플레이북이 포함될 수 있습니다.
vars	이 디렉터리의 main.yml 파일은 롤의 변수 값을 정의합니다. 종종 이러한 변수는 롤 내에서 내부 목적으로 사용됩니다. 또한 우선순위가 높으며, 플레이북에서 사용될 때 변경되지 않습니다.

Ansible Role 생성하기

- ansible-galaxy를 통해 role을 생성할 수 있다.

ansible-galaxy role init my-role

=> role 생성 시, 위에서 설명한 role 구조대로 디렉터리와 main.yml 파일들이 생성된다.

* 다른사람이 만들어놓은 Role Search 및 상세보기

ansible-galaxy role search postgresql --platforms Ubuntu
ansible-galaxy role info geerlingguy.postgresql

* Role Install

ansible-galaxy role install -p roles geerlingguy.postgresql
tree roles

[Ansible] 환경구축 및 기본사용(스터디 1주차)

IMyoungho — Wed, 10 Jan 2024 21:37:44 +0900

오랜만에 돌아온 Gasida님 스터디!! 이번에는 Ansible이다.

사용해보니 굉장히 편리하고 활용도를 높게 사용할 수 있을 거 같단 생각이 들었다(뭔가 이득본 기분...??)

인프라를 구축하는 분들 뿐만 아니라 보안업무 측면에서도 활용도가 높을 것 같다.

(예를 들어 굳이 힘들게 서버를 일일이 들어가서 제어하는 것이 아닌 한번에 제어가 가능하다)

Ansible이란??

- IT 자동화 도구로Ansible과 Python만 설치할 수 있다면 플레이북(yaml 형식) 작성을 통해 IT업무를 여러 환경에서 동일하게 적용 및 실행 할 수 있는 오픈소스이다.

Ansible의 특징

- Agentless:

Ansible의 경우 관리노드에 Agent를 설치할 필요가 없으며 SSH를 통해 관리노드에 명령을 전달

- Idempotent:

멱등성을 가지기 때문에 여러번 시도해도 항상 같은 결과를 낸다.

Ansible 환경 구축

- Requirement:

Python, Ansible

apt install ansible -y
apt install python3 -y

- Options:

Amazon EC2, VScode

AWS Management Console

AWS Support 플랜은 AWS로 성공하는 데 도움이 되는 다양한 도구, 프로그램 및 전문 지식에 대한 액세스의 조합을 제공합니다.

aws.amazon.com

Download Visual Studio Code - Mac, Linux, Windows

Visual Studio Code is free and available on your favorite platform - Linux, macOS, and Windows. Download Visual Studio Code to experience a redefined code editor, optimized for building and debugging modern web and cloud applications.

code.visualstudio.com

=> 스터디에서는 추가적으로 VScode를 통해 코드작성 환경을 구축했으며 Node의 경우 Amazon EC2 Instance를 사용했다(자신이 편한 환경으로 구축해서 사용하면 될 것 같다)

Ansible 사용

위의 그림에도 존재하지만 사용 시, 중요하게(?) 알아둬야할 것들이 몇 가지 존재한다.

- SSH

- Inventory

- ansible.cfg(Ansible 환경설정)

- playbook

- etc..

SSH(Secure Shell Protocol)

# Create SSH Keypair
ssh-keygen -t rsa -N "" -f /root/.ssh/id_rsa

=> 사실 SSH에 대해서는 대부분 알고 있고 많이 사용중이겠지만 환경 구축 시에 미리 설정해주는게 좋기 때문에 먼저 언급하기로 했다. 많은 분들이 이미 SSH를 사용하고 있기 때문에 어느정도 사용법은 알고 있을 것이다. SSH 사용에는 크게 ID/Passwd based와 패스워드를 굳이 입력하지 않는 방법으로 많이 알려진 Key based 방법이 있다.

- KeyPair 생성

=> 위와 같이 keypair를 생성하고 id_rsa.pub 내용을 Ansible 명령을 받을 Managed node의 authorized_keys 파일 내에 해당 값을 추가해주면 된다. 이는 명령어를 통해 복사를 수행해주었다. 참고로 id_rsa.pub 값의 끝에는 해당 명령이 실행된 "계정"@"hostname" 형식이 작성되어있다.

- 각 node의 root 의 .ssh/authorized_keys 복사

=> 각 node의 authorized_keys파일에 정상적으로 id_rsa.pub 값이 복사된 것을 볼 수 있었다.

[참고] ubuntu 계정으로 ping module 명령이 실패한 이유

ansible -m ping web -u ubuntu

=> 이유는 ubuntu 계정의 /home/ubuntu/.ssh/authorized_keys 파일 내에 위에서 생성한 root의 id_rsa.pub값이 존재하지 않기때문이다. 때문에 ubuntu 계정으로 명령을 진행해 SSH 연결을 시도했으나 public key 값이 등록되지 않았으므로 connect에 실패하게 된다.

~~=> SSH 관련 확인이 필요한 부분이 발견되어서 확인되는데로 추가예정(--ask-pass 옵션 시, 패스워드 미입력에도 접속됨)~~

- root의 id_rsa.pub 값을 ubuntu 계정의 /home/ubuntu/.ssh/authorized_keys 파일에 복사

해결방법은 당연히 간단하다.

for i in {1..3}; do ssh-copy-id ubuntu@tnode$i; done
for i in {1..3}; do echo ">> tnode$i <<"; ssh tnode$i cat /home/ubuntu/.ssh/authorized_keys; echo; done

=> 실패했던 "ansible -m ping web -u ubuntu" 명령이 정상적으로 성공한 것을 볼 수 있었다.

Inventory

- 텍스트 파일로 Ansible이 자동화 대상으로 하는 Host를 지정

- /etc/hosts 파일에 IP와 Domain이 mapping되어있다면 Domain명으로도 지정이 가능하다.

- 그 밖에도 inventory는 다양한 형태로 그룹을 설정할 수 있다.

cat <<EOT > inventory
10.10.1.11
10.10.1.12
10.10.1.13
EOT

---

cat <<EOT > inventory
tnode1
tnode2
tnode3
EOT

---

cat <<EOT > inventory
[web]
tnode1
tnode2

[db]
tnode3

[all:children]
web
db
EOT

Inventory 구성

- 그룹별: "[ ]" 내에 그룹명을 작성한 뒤 해당 그룹에 속하는 Host명이나 IP를 작성(하나의 Host가 여러 그룹에 속해도 무방)

- 중첩 그룹: 기존에 정의한 Host 그룹을 다른 Host 그룹에 포함시킬 수 있으며 이때 ":children"이라는 접미사를 추가

[default]
# 아래의 내용을 범위로 지정 가능 -> 192.168.1.[1:3]
192.168.1.1
192.168.1.2
192.168.1.3

[dns]
[a:c].dns.example.com # a.dns.example.com , b.dns.example.com , c.dns.example.com 을 의미함

[dev]
# 아래의 내용을 범위로 지정 가능 -> hi[01:02].exmple.com
hi01.example.com
hi02.example.com

[stage]
sleep01.example.com
sleep02.example.com

[qa]
bye01.example.com
bye02.example.com

[prod]
hi01.example.com
bye02.example.com
sleep01.example.com

[test:children]
dev
qa
stage

- Inventory 검증

ansible-inventory -i ./inventory --list | jq
ansible-inventory -i ./inventory --graph

ansbile.cfg

- 매번 위의 방법처럼 -i 옵션을 이용하는 것은 불편함. 그래서 사용하는 것이 ansible.cfg라는 Ansible 환경설정 파일

- 이 밖에도 ansible config를 적용하는 방법은 다양하다.

- key : value 타입으로 구성됨

# ansible.cfg 파일 생성
cat <<EOT > ansible.cfg
[defaults]
inventory = ./inventory
EOT

# inventory 목록 확인
ansible-inventory --list | jq

[참고] ansible config 적용 방법 및 우선 순위

Ansible Configuration Settings — Ansible Documentation

['bud-frogs', 'bunny', 'cheese', 'daemon', 'default', 'dragon', 'elephant-in-snake', 'elephant', 'eyes', 'hellokitty', 'kitty', 'luke-koala', 'meow', 'milk', 'moofasa', 'moose', 'ren', 'sheep', 'small', 'stegosaurus', 'stimpy', 'supermilker', 'three-eyes',

docs.ansible.com

ANSIBLE_CONFIG (environment variable if set)
ansible.cfg (in the current directory)
~/.ansible.cfg (in the home directory)
/etc/ansible/ansible.cfg

- 스터디에서는 아래와 같이 ansible.cfg를 구성해서 사용했다.

[defaults]
inventory = ./inventory
remote_user = root
ask_pass = false

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

Ansible module을 통한 명령

- ping 모듈

ansible -m ping all
ansible -m ping web
ansible -m ping web -u ubuntu
ansible -m ping web -u ubuntu --ask-pass

- shell 모듈

ansible -m shell -a 'hostname' all
ansible -m shell -a 'pwd' all

Playbook

- 위의 방법처럼 module을 이용한 명령어 실행으로 각각의 node들을 제어할 수 도 있지만 yml 형식의 파일을 미리 작성해 사용할 수 있다. 각각의 명령 실행을 play라고 한다면 이를 책처럼 묶어서 사용하는 의미가 playbook이라고 할 수 있다.

- 참고로 ansible cli를 사용하여 하나 이상의 managed node에 대한 단일 작업을 자동화 명령을 'ad-hoc' 이라고 한다.

- 사용법은 ansible-playbook 명령어를 통해 작성된 playbook yml 파일 내용을 실행한다.

Creating a playbook — Ansible Documentation

docs.ansible.com

# first-playbook.yml
---
- hosts: all
  tasks:
    - name: Print message
      debug:
        msg: Hello CloudNet@ Ansible Study

=> 스터디에서 진행한 기본예제이다.

ansible-playbook first-playbook.yml

Playbook 변수

- 종류: 호스트, 그룹, 플레이, 추가, 작업 변수 등이 존재

- 우선순위: 추가변수(실행 시 파라미터) > 플레이 변수 > 호스트 변수 > 그룹 변수

[web]
tnode1
tnode2

[db]
tnode3 user=ansible1

[all:children]
web
db

[all:vars]
user=ansible

1. 그룹변수

- inventory 파일에 선언. 현재 예시로는 all 그룹에서 user라는 변수를 사용할 수 있게됨

[all:vars]
user=ansible

- playbool yml 파일에서 변수 사용(띄어쓰기 주의)

---

- hosts: all
  tasks:
  - name: Create User {{ user }}
    ansible.builtin.user:
      name: "{{ user }}"
      state: present

=> 멱등성 특징으로인해 만약 해당 계정(ansible)이 이미 존재하더라도 에러가 아닌 최종형태가 동일한 결과로 나타남.

2. 호스트 변수

- inventory 파일내 호스트 옆에 변수 선언

[db]
tnode3 user=ansible1

- 사용 시, 해당 호스트가 포함된 그룹 또는 호스트로 작성

---

- hosts: db # <- 이 부분에 그룹 또는 호스트 
  tasks:
  - name: Create User {{ user }}
    ansible.builtin.user:
      name: "{{ user }}"
      state: present

3. 플레이변수

- playbook yml 내 hosts 아래에 "vars"를 추가해서 사용(file로도 가능하며 아래의 도전과제1 참고)

---

- hosts: all
  vars:
    user: ansible_test
    
  tasks:
  - name: Create User {{ user }}
    ansible.builtin.user:
      name: "{{ user }}"
      state: present

4. 추가변수

- ansible-playbook 실행 시, parameter로 전달하는 변수( extra의 의미인 "-e" 옵션을 이용)

ansible-playbook -e user=ansible create-user.yml

5. 작업변수

- playbook의 수행결과를 저장할 수 있는 변수로 특정 작업 후, 그 결과를 이용하여 후속작업 시, 주로 사용

- "register: " 문구를 이용하여 사용함

---

- hosts: db
  tasks:
  - name: Create User {{ user }}
    ansible.builtin.user:
      name: "{{ user }}"
      state: present
    register: result
  
  - ansible.builtin.debug:
      var: result

Ansible Vault

- Password, API key 등 중요한 정보 및 Credential 값이 ansible-playbook에는 text로 저장되며 접근권한이 있다면 누구나 확인이 가능함. 때문에 이를 통한 유출을 막기위해 데이터 파일을 암/복호화 할 수 있는 기능을 제공함

ansible-vault create secret.yml

=> 해당 명령 진행 시, 해당 파일을 암호화할 때 사용할 passwd를 입력받으며, 입력이 끝나면 yml 파일 내용을 작성할 수 있음. 작성된 내용은 "cat" 명령어로는 암호화되어 확인이 불가

암호화된 파일 보기

ansible-vault view secret.yml

=> 위에서 암호화한 파일의 내용을 해당 명령과 Vault 패스워드를 통해 확인할 수 있음

파일을 이용한 암복호화

- 패스워드 파일을 만들어서 암복호화를 진행할 수도 있다.

echo 'my-passwd' > vault-pass

ansible-vault create --vault-pass-file ./vault-pass secret.yml
ansible-vault view --vault-pass-file ./vault-pass secret.yml

=> 패스워드가 작성된 파일을 잘 관리해줘야 한다는 번거로운 점이 있을 수 있겠으나 대량의 중요파일들에 대해 패스워드를 설정하거나 변경할 때 편리할 것 같다.

기존파일 암호화

- 기존에 만들어놓은 파일에 대해 암호화 및 복호화가 가능

ansible-vault encrypt original_file.yml

=> 해당 명령 진행 시, 패스워드를 입력해주면 된다.

ansible-vault decrypt var_file.yml --output=var_decrypted.yml

=> 복호화 시, 암호화된 파일은 그대로 두고 복호화한 파일만 따로 생성할 수 도 있다.

패스워드 변경

- 직접 입력해서 변경이 가능하며 파일로도 가능하다.

ansible-vault rekey mysecret.yml
ansible-vault rekey --new-vault-password-file=./vault-pass mysecret.yml

playbook 진행 시, 암호화된 파일 사용법

- 일반적인 ansible-playbook으로는 에러가 발생한다.

- '--vault-id @promt' 옵션을 추가해주고 패스워드를 입력하면 정상적으로 동작한다.

ansible-playbook --vault-id @prompt create-user.yml

* 에러발생

* 정상동작

Facts

- Ansible이 관리 호스트에서 자동으로 검색한 변수(자동 예약 변수)를 의미

- Facts에는 아래와 같은 호스트별 정보가 담겨있음

- 사용 표기법은 많이 알아두면 좋지만 ansible_facts 전체를 출력해서 보고 사용해도 무방할 것 같음.

- ansible_facts.* 네임스페이스 표기법 사용을 권장

- 사용자 지정 fact도 만들 수 있음

호스트 명, 커널 버전, 네트워크 인터페이스 명, 운영체제 버전, CPU 개수, 사용 가능한 메모리, 스토리지 장치의 크기 및 여유 공간 etc...

=> 화면에는 다보이지 않지만 굉장히 많은 정보를 json 형식으로 볼 수 있다.

* 구버전 fact 문법 비활성화

- 구버전 사용은 권장하지 않으며 ansible.cfg 파일에 옵션을 추가하여 비활성화가 가능하다(infect_facts_as_vars=false)

[defaults]
inventory = ./inventory
remote_user = root
ask_pass = false
inject_facts_as_vars = false

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

* facts 수집 비활성화

- fact 수집으로 인한 호스트 부하를 줄이고 싶거나 굳이 fact 수집이 필요하지 않은 경우 사용

- 참고로 facts 수집을 비활성화 한상태에서 해당 facts를 사용하려하면 당연히 에러가 난다)

---

- hosts: db
  gather_facts: no # <- 수집 비활성

  tasks:
  - name: Print all facts
    ansible.builtin.debug:
      msg: >
        The default IPv4 address of {{ ansible_facts.hostname }}
        is {{ ansible_facts.default_ipv4.address }}

* Manual 하게 facts 수집 비활성화

- hosts 레벨에서 facts를 비활성화하되 tasks 레벨에서 수집할 수 있게 설정도 가능하다.

- hosts: db
  gather_facts: no

  tasks:
  - name: Manually gather facts
    ansible.builtin.setup:

  - name: Print all facts
    ansible.builtin.debug:
      msg: >
        The default IPv4 address of {{ ansible_facts.hostname }}
        is {{ ansible_facts.default_ipv4.address }}

* 사용자 지정 fact 만들기 & 수집

- host의 /etc/ansible/facts.d 디렉터리 내에 *.fact 형식의 파일을 생성하여 수집하고 싶은 facts를 정의하고 수집이 가능하다.

# 관리 호스트에 facts.d 디렉터리 생성
mkdir /etc/ansible/facts.d

# my-custom.fact 파일 생성
cat <<EOT > /etc/ansible/facts.d/my-custom.fact
[packages]
web_package = httpd
db_package = mariadb-server

[users]
user1 = ansible
user2 = k8s-ho
EOT

- Playbook 예시

---

- hosts: localhost

  tasks:
  - name: Print all facts
    ansible.builtin.debug:
      var: ansible_local

도전과제1

- 생성된 user를 ansible.builtin.user 모듈을 통해 제거해보자.

- 참고로 Ansible의 변수선언은 다양하게 가능하며 아래와 같은 우선순위를 가진다.

추가변수(실행 시 파라미터) > 플레이 변수 > 호스트 변수 > 그룹 변수

=> 도전과제1에서 나의 경우 별도 파일을 분리한 플레이 변수를 사용하였다.

* 계정 생성

ansible-playbook create-user.yml

# var_file.yml
user1: ansible1
user2: ansible2
user3: ansible3


# create_user.yml
---

- hosts: all
  vars_files:
    - var_file.yml

  tasks:
    - name: Create User {{ user1 }}
      ansible.builtin.user:
        name: "{{ user1 }}"
        state: present
    - name: Create User {{ user2 }}
      ansible.builtin.user:
        name: "{{ user2 }}"
        state: present
    - name: Create User {{ user3 }}
      ansible.builtin.user:
        name: "{{ user3 }}"
        state: present

=> 삭제를 위해 우선 계정을 생성해주었다.

* 계정삭제

- 변수는 이미 작성되어있으므로 삭제로만 수정진행

ansible-playbook remove-user.yml

# remove-user.yml
---

- hosts: all
  vars_files:
    - var_file.yml

  tasks:
    - name: Remove User {{ user1 }}
      ansible.builtin.user:
        name: "{{ user1 }}"
        state: absent
    - name: Remove User {{ user2 }}
      ansible.builtin.user:
        name: "{{ user2 }}"
        state: absent
    - name: Remove User {{ user3 }}
      ansible.builtin.user:
        name: "{{ user3 }}"
        state: absent

=> 깔끔하게 삭제가 완료되었다.

도전과제2

- 관리대상에 uptime을 ansible.builtin.debug 모듈을 통해 확인해보자

# uptime.yml
---
- hosts: all
  tasks:
    - name: Get uptime to Node
      ansible.builtin.shell: /usr/bin/uptime
      register: result

    - name: Show uptime
      ansible.builtin.debug:
        msg: "{{ result.stdout }}"

=> 관리 node별 uptime을 확인할 수 있었다.

도전과제3

- 팩트를 사용하여 3개의 EC2 '커널버전'과 '운영체제 종류'를 출력해보자.

# fact.yml
---

- hosts: all
  tasks:
    - name: facts data collecting
      ansible.builtin.debug:
        #var: ansible_facts
        msg: >
          The OS of this VM is {{ ansible_facts.distribution }} {{ ansible_facts.distribution_version  }}
          and the Kernel version is {{ ansible_facts.kernel }}

ansible-playbook fact.yml

=> 각각 VM별 OS 종류와 Kernel version을 볼 수 있었다. ansible_facts가 수집된 내용을 확인한 뒤에 필요한 데이터만 파싱해서 사용하면 된다.

[AWS] LocalStack이란?

IMyoungho — Mon, 4 Dec 2023 11:01:29 +0900

LocalStack이란?

이름 그대로 로컬에서 AWS 서비스를 구축/개발 테스트해볼 수 있는 AWS 클라우드 서비스 에뮬레이터이다. 얼마전에 알게되어 정보공유차원에서 작성해보았다.

LocalStack

Use LocalStack as a drop-in replacement for AWS in your dev and testing environments.

www.localstack.cloud

=> 생각보다 다양한 AWS 서비스를 사용해볼 수 있다. 기업이나 개발팀에서 보통 클라우드 비용을 고려해 테스트용도로 구축해서 많이 사용한다고한다.

=> 하지만 개인적인 용도(공부 등)로 사용하는거라면 그냥 AWS를 사용하는 것을 추천한다. 아무리 로컬에서 AWS 서비스를 사용할 수 있다고 하더라도 둘의 차이는 분명히 존재하기때문에 어처피 AWS를 위해 사용해보는거라면 조금의 과금이 발생하더라도 AWS와 친숙해지면서 자신의 과금 정도를 체크해보는 것이 더 좋을 것 같다.

- 로컬스택에 대해 잘정리되어있는 블로그(인프랩)

Localstack 을 활용한 AWS 인프라 통합테스트

안녕하세요. 인프랩에서 백엔드 개발을 담당하고 있는 인트라고합니다. 저는 최근 오픈한 채용 서비스 랠릿 프로젝트에 참여하였습니다. 기존 인프런 서비스와는 다른 스택과 환경에서 개…

tech.inflab.com

[Istio] 환경 구축(feat. Minikube)

IMyoungho — Sun, 26 Nov 2023 13:27:31 +0900

Istio

A service mesh for observability, security in depth, and management that speeds deployment cycles.

istio.io

공유 목적을 위해 istio 관련 포스팅을 진행해보려고 한다

나의 환경의 경우 mac os(M2 pro)에 minikube를 설치해서 진행하였으며

istio는 1.20, kubernetes 버전은 1.28이다.

Istio 사용이유

- Istio는 ServiceMash로 MSA 구조상 규모가 커져감에 따라 점점 복잡해지고 상호동작에 대한 이해가 어려워지면서 관리의 어려움이 발생하게되는데 이를 어느정도 해소해줄 수 있는 오픈소스이다. 사용자는 sidecar를 injection하는 것만으로 software 레벨이 아닌 인프라 레벨에서 트래픽을 관리하고 제어할 수 있다는 점이 장점이다. 그 밖에 서킷브레이킹이나 Service 라우팅을 통한 트래픽 흐름제어와 배포 관리, 가시성 확보, 분산추적, MTLS 보안 통신 등 다양한 기능을 활용할 수 있다.

minikube 설치

minikube start

minikube is local Kubernetes

minikube.sigs.k8s.io

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64
sudo install minikube-darwin-amd64 /usr/local/bin/minikube
minikube start

kubectl 설치 & 자동완성설정

리눅스에 kubectl 설치 및 설정

시작하기 전에 클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v1.28 클라이언트는 v1.27, v1.28, v1.29의 컨트롤 플레인과 연동될 수 있다. 호환되는 최신 버전

kubernetes.io

kubectl Cheat Sheet

This page contains a list of commonly used kubectl commands and flags. Note: These instructions are for Kubernetes v1.28. To check the version, use the kubectl version command. Kubectl autocomplete BASH source <(kubectl completion bash) # set up autocomple

kubernetes.io

brew install kubectl
또는
brew install kubernetes-cli

alias k=kubectl
complete -o default -F __start_kubectl k

source <(kubectl completion zsh)  
echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc

istioctl 설치

Getting Started

Try Istio’s features quickly and easily.

istio.io

curl -L https://istio.io/downloadIstio | sh -
cd istio-1.20.0
export PATH=$PWD/bin:$PATH

helm 설치 및 Kubernetes istio 구축

Install with Helm

Instructions to install and configure Istio in a Kubernetes cluster using Helm.

istio.io

brew install helm
helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update

kubectl create namespace istio-system
helm install istio-base istio/base -n istio-system --set defaultRevision=default
helm ls -n istio-system

helm install istiod istio/istiod -n istio-system --wait
helm ls -n istio-system
kubectl get deployments -n istio-system --output wide

kubectl create namespace istio-ingress
helm install istio-ingress istio/gateway -n istio-ingress --wait

다른방법의 istio 구축

git clone https://github.com/DickChesterwood/istio-fleetman
cd istio-fleetman/_course_files/arm64/warmup-exercise
k apply -f 1-istio-init.yaml
k apply -f 2-istio-minikube.yaml
..
..

=> 이후 나머지 yaml도 실행시켜주면 테스트 환경을 확인할 수 있다. 아래는 Istio를 통해 구성된 service mesh를 모니터링할 수 있는 툴 kiali Dashboard의 화면이다. 참고로 해당 dashboard에 보여지려면 당연히 pod내에 envoy proxy를 sidecar형태로 injection해야하며 이는 namespace의 labeling을 통해 가능하다. 원하는 namespace에 istio-injection=enabled label을 적용하면된다. 정상적으로 injection이 되었다면 pod 생성 시(Pod내에 1개의 container를 생성했을경우) 2개의 container가 존재하는 것을 확인할 수 있으며 그중 하나는 istio-proxy(envoy proxy)이다.

Kiali Dashboard 접근

=> 하단의 Legend를 클릭하면 해당 map에 대한 정보를 볼 수 있다.

[참고] MacOS(M1, M2) minikube service type NodePort 접근이 안되는 이슈

minikube ip is not reachable

I have created one service called fleetman-webapp: apiVersion: v1 kind: Service metadata: name: fleetman-webapp spec: selector: app: webapp ports: - name: http port: 80 nodePort: ...

stackoverflow.com

Cannoot access services via NodePort on MacOS with Docker driver · Issue #11193 · kubernetes/minikube

Hello, I am facing issues accessing services via node port on Mac OS. System information: ProductName: macOS ProductVersion: 11.1 BuildVersion: 20C69 Ninikube version: minikube version: v1.19.0 com...

github.com

참고로 nodePort를 통해 Pod를 노출시키는경우 minikube ip로 접근이 안되는 이슈가 발생할 수 있다. 이는 docker를 driver로 사용하기 때문이라는 말도 있는데 어찌되었던 minikube service를 통해 간단하게 해결할 수 있다.

[AWS] AHSS 1주차 - S3 취약점 및 보안(feat. s3game)

IMyoungho — Fri, 1 Sep 2023 21:08:55 +0900

오랜만에 Gasida님 스터디에 참가하게 되었다.

Gasida님의 테라폼 스터디도 참가하고 싶었지만.. 요즘 프로젝트가 너무 바빠져서..ㅠ(다음기회에 꼭!!..)

이번 스터디의 주제는 드디어 클라우드 Security이다!

1주차 주제는 s3 취약점 및 보안으로 스터디 공백기간 동안 클라우드 관련 wargame들을 풀어본적이 있었다

(BigIAMchallange, flAWS 등)

그래서인지 훨씬 수월했고 1주차 과제는 스터디에서 배운 것들을 활용할 수 있는 s3game writeup을 진행하였다.

s3game Writeup

S3 Game

_ _______ _______ _ __ ( \ ( ____ \|\ /|( ____ \( \ / \ | ( | ( \/| ) ( || ( \/| ( \/) ) | | | (__ | | | || (__ | | | | | | | __) ( ( ) )| __) | | | | | | | ( \ \_/ / | ( | | | | | (____/\| (____/\ \ / | (____/\| (____/\ __) (_ (_______/(_______/ \_/ (____

s3game-level1.s3-website.us-east-2.amazonaws.com

< Level1 >

=> 1번 문제는 그저 s3 URL의 구조에 대해서 설명을 해주고 bucket name이 뭔지만 알 수 있으면 풀 수 있는 문제였다. 대놓고 bucket name이 s3game-level1이기 때문에 aws-cli를 통해 접근해보았다.

aws s3 ls s3://s3game-level1
aws s3 cp s3://s3game-level1/tresure1 -

=> 해당 s3는 public으로 공개되어있었고 treasure1라는 object가 누가봐도 다음 Level로 갈 수 있게 도와줄 것 같이 생겼다

= >해당 파일을 확인해보니 secret code라는 숫자+영문 조합과 다음 Level로가는 링크를 알려주었다. 1번은 쉽게 클리어~

< Level2 >

S3 Game

s3game-level2.s3.us-east-2.amazonaws.com

=> 2번문제의 내용은 Virtual Hosted Style URL format에 대한 내용을 가르쳐주면서 이 게임에서는 Path Style의 접근은 사용하지 않으며 2020년 09월 30일 이후 생성된 bucket은 Virtual Hosted Style만 지원한다고 하며 해당 날짜보다 이전에 생성된 s3는 두 가지 Style을 모두 지원한다고 한다.

'Old' vs 'New' 참고

Amazon S3 Path Deprecation Plan – The Rest of the Story | Amazon Web Services

Update (September 23, 2020) – Over the last year, we’ve heard feedback from many customers who have asked us to extend the deprecation date. Based on this feedback we have decided to delay the deprecation of path-style URLs to ensure that customers hav

aws.amazon.com

=> 해당 문제에서 제공하는 또하나의 링크를 들어가면 Path-style과 Virtual-hosted style의 예시를 제공하고 있다. 문제에서 보여주었던 URL은 Virtual-hosted style인 것으로 보여진다. 그렇다면 두 가지 모두 접근해보자.

Path-style & Virtual-hosted style Request

curl http://s3game-level2.s3.us-east-2.amazonaws.com/treasure2
curl https://s3-us-east-2.amazonaws.com/s3game-level2/treasure2

=> 문제에서 제공한 bucket-name은 s3game-level2이며 treasure2를 얻을 수 있을 것이라고 했으니 object 명은 treasure2를 사용해주었고 나머지는 제공하는 style의 format에 맞게 진행했다.

=> 결과는 똑같이 나왔고 웹에서 해당 URL로 접근하면 treasure2 파일이 자동으로 Download 되었다. 파일 내용은 aws credential로 보여지는 내용과 Level3으로 가는 URL을 알려주었다. credential은 다음 문제에서 쓰이지 않을까 싶다. 2번도 어렵지 않게 클리어~

< Level3 >

S3 Game

s3game-level3.s3.us-east-2.amazonaws.com

=> Level2에서 줍줍한 credential을 사용해야한다는 것을 직감했다. 해당 credential만이 문제에서 제공하는 bucket에 접근할 수 있을 것 같다.

aws configure

aws configure --profile test
aws --profile test sts get-caller-identity

# Credential 정보
Access Key ID: AKIAZBIEGK7G53TU2K4L  
Secret Access Key: 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
region name: us-east-2

=> 참고로 등록된 credential에 대한 파일은 .aws/credential과 .aws/config 파일에서 확인할 수 있다. 문제에서 제공하는 credential외에 나의 계정의 credential이 있어서 --profile 옵션을 사용해주었다.

=> 등록이 완료되면 Security Token Service의 get caller identity로 제대로 된건지 확인해보면 된다.

aws-cli를 통한 s3 접근

aws --profile test s3 ls s3://s3game-level3
aws --profile test s3 cp s3://s3game-level3/treasure3_has_no_secret_code -

=> 해당 credential로 s3 bucket 이름을 추측해서 접근해보았다. 기존에 s3game-<LEVEL NAME> format이였기 때문에 s3game-level3 bucket이 존재한다면 Object Listing이 될 것이라고 생각했고 예상대로 존재했다. object 중에는 treasure3가 존재했고 내용을 확인해보니 Level4로 가는 URL이 확인되었으나 중간에 <THE CODE>를 비우고 줘서.. 접근이 불가했다.

aws-cli의 s3api 명령을 통한 접근

get-object — AWS CLI 1.29.39 Command Reference

Note: You are viewing the documentation for an older major version of the AWS CLI (version 1). AWS CLI version 2, the latest major version of AWS CLI, is now stable and recommended for general use. To view this page for the AWS CLI version 2, click here. F

docs.aws.amazon.com

aws s3api --profile test get-object --bucket s3game-level3 --key treasure3_has_no_secret_code  outfile

https://s3game-level4-k73045aztqln.s3.us-east-2.amazonaws.com/level4.html

=> 스터디에서도 언급되었던 내용으로 aws-cli 명령어 중 s3 관련 명령어는 s3와 s3api가 존재한다.

=> 둘의 차이는 s3 명령의 경우 일반적인 bucket 관련 작업이나 object 관련 작업을 쉽게 수행하기 위한 용도이며 s3api명령어는 s3 명령어 보다 좀더 많은 작업이 가능한 s3 API 요청관련 명령어이다. 즉, 명령어 그대로 s3의 API를 사용하는 것이라고 보면 된다.

=> 때문에 두 명령어는 위처럼 응답도 다르게 온다. 위에서처럼 s3api 명령어를 통해 secret code를 확인할 수 있었다. 결과적으로 이번문제에서는 s3, s3api 명령어 둘 다 사용해야 문제를 풀 수 있었다.

< Level4 >

S3 Game

_ _______ _______ _ ___ ( \ ( ____ \|\ /|( ____ \( \ / ) | ( | ( \/| ) ( || ( \/| ( / /) | | | | (__ | | | || (__ | | / (_) (_ | | | __) ( ( ) )| __) | | (____ _) | | | ( \ \_/ / | ( | | ) ( | (____/\| (____/\ \ / | (____/\| (____/\ | | (_______/(_______/

s3game-level4-k73045aztqln.s3.us-east-2.amazonaws.com

=> 사악하다...힌트 없다고 한다. 한 가지 신경쓰이는 부분은 이번 Level의 bucket name을 더블 체크하라고 한다...

일단 s3 bucket에 접근해보자

aws --profile test s3 ls s3://s3game-level4-k73045aztqln
aws --profile test s3 cp s3://s3game-level4-k73045aztqln/treasure4_also_has_no_secret_code -

=> 오잉? 그냥 바로 실마리가 나왔다. 이번에도 이전문제와 동일하게 다음 Level로 가는 URL에서 비어있는 부분을 찾기만 하면 될 것 같다. metadata를 언급하는 걸로 봐서는 s3api를 한번 더 사용해보는 것이 좋을 것 같다.

s3api 명령어 get-object 사용

aws s3api --profile test get-object --bucket s3game-level4-k73045aztqln --key treasure4_also_has_no_secret_code outfile
https://s3game-level4-k73045aztqln.s3.us-east-2.amazonaws.com/treasure4_also_has_no_secret_code

=> 음.. Metadata가 빈 값으로 나왔다.. 하지만 TagCount가 1로 존재했다. 그렇다면 Tag 관련 정보를 보기로 했다.

s3api 명령어 get-object-tagging 사용

aws s3api --profile test get-object-tagging --bucket s3game-level4-k73045aztqln --key treasure4_also_has_no_secret_code

# secret-code를 넣은 다음 Level로 가는 URL
https://s3game-level5-8v95e5rv7z4i.s3.us-east-2.amazonaws.com/level5.html

=> 객체의 Tag 정보를 반환하는 명령을 통해 확인을 해보니 secret_code가 확인되었다. 이를 통해 다음 Level로 가는 URL의 비어진 부분을 알 수 있었다.

< Level5 >

S3 Game

_ _______ _______ _ _______ ( \ ( ____ \|\ /|( ____ \( \ ( ____ \ | ( | ( \/| ) ( || ( \/| ( | ( \/ | | | (__ | | | || (__ | | | (____ | | | __) ( ( ) )| __) | | (_____ \ | | | ( \ \_/ / | ( | | ) ) | (____/\| (____/\ \ / | (____/\| (____/\ /\____) ) (____

s3game-level5-8v95e5rv7z4i.s3.us-east-2.amazonaws.com

=> 보이지 않는 것을 볼필요가 있다는 말만 남기고 다른 힌트는 없었다.

s3 ListObject

aws --profile test s3 ls s3://s3game-level5-8v95e5rv7z4i

=> 우리가 찾는 실마리가 될만한 object는 보이지 않았다. 이전에 클라우드나 컨테이너 관련 취약점 공부를 했을 때 git, docker image의 과거 데이터에 정보가 남겨져 있어 취약했던 경험이 있어서 s3도 history를 확인해야 겠다는 생각이 들었다.

s3 object version 정보 확인

aws --profile test s3api list-object-versions --bucket s3game-level5-8v95e5rv7z4i

=> 과거의 기록에서 "treasure5_is_deleted"라는 객체명이 확인되었다. 해당 객체는 DeleteMarkers가 설정되어있어 드디어 실마리를 찾았고 복구를 하거나 해당 내용을 볼 수 있는 방법을 찾아보았다.

Version 옵션값을 s3 object 조회

삭제된 Amazon S3 객체 검색

버전 관리가 활성화된 Amazon Simple Storage Service(S3) 버킷에서 삭제된 객체를 검색하려고 합니다. 어떻게 해야 하나요?

repost.aws

aws --profile test s3api get-object --bucket s3game-level5-8v95e5rv7z4i --key treasure5_is_deleted --version-id 344PQOyFqocF0TI66MbLynNNdQqHfBz3 outfile

=> 삭제되었던 객체의 Version-Id를 옵션값으로 get-object 명령을 통해 객체를 다운로드 했다. 내가 설정한 파일명인 "outfile"을 확인할 수 있었으며 해당 객체에는 역시 다음 Level로 가는 URL이 존재했다.

Bucket Version 관리 활성화 여부 확인

aws --profile test s3api get-bucket-versioning --bucket s3game-level5-8v95e5rv7z4i

=> 다 풀고 나서 다른사람의 풀이를 보고 알게된 것은 나의 경우 "Bucket의 버전관리가 활성화되어있는지"에 대한 확인과정 없이 풀이를 진행했다는 것이다. 사실 그냥 문제풀 때는 해당 과정 없이 시도해보면 되긴하지만 나중에 공격 관련 자동화 스크립트를 만든다면 버전관리 활성화 여부 확인 시, 필요할 것 같아서 작성했다.

< Level6 >

S3 Game

s3game-level6-vjv45x1gux81.s3.us-east-2.amazonaws.com

select-object-content — AWS CLI 1.29.39 Command Reference

select-object-content Description This action filters the contents of an Amazon S3 object based on a simple structured query language (SQL) statement. In the request, along with the SQL expression, you must also specify a data serialization format (JSON, C

docs.aws.amazon.com

=> 이번 문제는 객체에서 필요한 데이터만 추출하여 비용을 절감할 수 있는 S3 Select에 관련된 문제라는 것을 대놓고 알려주고 있다. 심지어 문제에서 s3의 select-object-content를 사용하라고 까지 말해주는 것으로 보아, 해당 명령을 통해 문제를 풀며 사용법을 익히라는 것 같다.

s3 Object 확인

aws --profile test s3 ls s3://s3game-level6-vjv45x1gux81
aws --profile test s3 cp s3://s3game-level6-vjv45x1gux81/s3select.csv.gz .

=> s3game-level6-vjv45x1gux81 bucket의 object를 확인해보니 s3select.csv.gz라는 압축파일이 존재했고 확인을 위해 우선 Download하였다.

s3select.csv.gz 파일 살펴보기

=> 해당 파일과 문제에서 제공한 query를 비교해보면 첫 번째줄이 컬럼이라는 것을 알 수 있었고 우리가 찾는 데이터는 Answer 컬럼에 존재한다는 것을 추측해볼 수 있다. 또한 해당 칼럼내의 "TREASURE"인 부분만 반환하도록 쿼리를 작성한 것도 알 수 있었다.

=> 즉, s3 객체 내에서 Category 컬럼의 값이 "TREASURE"일 때 Answer 컬럼의 값을 출력해내면 된다.

=> 때문에 해당 파일에 유추를 통해 grep을 여러번 이용하더라도 문제는 풀 수 있었다. 하지만 이번문제의 출제의도는 select-object-content를 통해 깔끔하게 필요한 추출하는 것일 것이기 때문에 s3 select-object-content를 사용해보자.

s3 select-object-content 사용

# FileHeaderInfo": "USE" 사용 시
aws --profile test s3api select-object-content \
--bucket s3game-level6-vjv45x1gux81 \
--key s3select.csv.gz \
--expression "SELECT Answer FROM s3object WHERE Category = 'TREASURE'" \
--expression-type 'SQL'  \
--input-serialization '{"CSV": {"FileHeaderInfo": "USE", "FieldDelimiter": ";"}, "CompressionType": "GZIP"}' \
--output-serialization '{"CSV": {}}' "output.csv"


# FileHeaderInfo": "IGNORE" 사용 시
aws --profile test s3api select-object-content \
--bucket s3game-level6-vjv45x1gux81 \
--key s3select.csv.gz \
--expression "SELECT s._8 FROM s3object s WHERE s._5 = 'TREASURE'" \
--expression-type 'SQL'  \
--input-serialization '{"CSV": {"FileHeaderInfo": "IGNORE", "FieldDelimiter": ";"}, "CompressionType": "GZIP"}' \
--output-serialization '{"CSV": {}}' "output2.csv"

다음 Level로 ~

=> 나머지 옵션은 사용법이 어렵지 않기 때문에 핵심 옵션만 설명하자면 --expression과 --input-serialization만 잘 넣어주면 된다. --expression의 경우 우리가 흔히 사용하는 SQL query이며 s3 객체 자체를 대상으로 데이터를 선택하는 것이기 때문에 FROM 다음에 "s3object" 키워드를 사용하면 된다. 또한 --input-serialization을 통해 FileHeaderInfo를 "USE" 나 "IGNORE"로 주어서 첫 번째 줄이 헤더임을 인식시켜주고 FieldDelimiter를 통해 레코드를 ";"로 구별할 수 있도록 작성해주면 된다.

=> 위의 방법대로 명령을 진행하게되면 깔끔하게 다음 Level로 갈 수 있게 된다.

< Level7 >

S3 Game

s3game-level7-zhovpo4j8588.s3.us-east-2.amazonaws.com

=> 이번 문제의 s3의 모든 객체가 private라고 한다. 그리고 해당 object owner만이 접근 권한이 있다고 한다. 하지만 다른 사용자들에게 share가 가능하다며 presigned URL이라는 것을 통해 시간 제한으로 object를 다운로드 할 수 있는 권한을 부여할 수 있다고 한다.

=> 해당 기능 관련해서는 스터디 시간에도 실습했기 때문에 어렵지 않게 풀 수 있었다.

s3 presigned URL

aws --profile test s3 presign s3://s3game-level7-zhovpo4j8588/treasure7 --expires-in 3600

=> 다음과 같이 해당 s3의 presigned url을 획득했다.

presigned URL로 접근

=> 해당 URL로 접근했지만 Access Denied 당했다.. 그렇다면 object명이 잘못된 것이 아닌가 싶다...

curl $(curl $(aws --profile test s3 presign s3://s3game-level7-zhovpo4j8588/somethingstrange --expires-in 3600))

=> 문제를 제대로 안봤다.. object명을 문제에서 제공한 somethingstrange로 다시 시도해 보았고 다음 Level로 가는 URL을 만날 수 있었다. 문제 잘 읽자...

< Level8 >

S3 Game

s3game-level8-v6g8tp7ra2ld.s3.us-east-2.amazonaws.com

=> 해당 문제는 CloudFront에 관련된 문제이며 Hint로 Bucket에 대한 IAM policy를 보여주고 있다.

=> 해당 IAM 정책은 CloudFront의 경우 모든 s3 bucket에 대해 GetObject가 가능하다는 의미이다. 간략하게 말해서 CloudFront만이 s3 bucket의 object에 접근이 가능한 것이다. 이를 가능하게 하기위해 문제에서는 CloudFront distribution URL도 제공해주었다.

=> 사용자는 접근하지 못하는 S3 bucket에 대해 CloudFront를 A서버, S3 bucket object를 B서버라고 한다면 A서버인 CloudFront의 권한을 이용하여 B서버인 s3 bucket object에 접근하는 SSRF라고 볼 수 있다(예시가 애매할 순 있지만 이해를 위해..ㅎㅎ)

=> 어쨌든 특히 클라우드에서는 이러한 취약점이 발생하지 않도록 IAM policy를 잘 생각하고 구성해야한다.

s3 object Listing

aws --profile test s3 ls s3://s3game-level8-v6g8tp7ra2ld

=> 우선 Level8의 bucket object를 확인해보니 "treasure8_CDN"이라는 object가 보였다.

=> 문제에서 말한 "bucket에 대해 직접 접근을 막았다면 object를 Listing하는 것도 허용하지 말라고" 한 이유가 여기 있었다. 결국에 해당 bucket은 Cloudfront를 통해 서비스 중이므로 object명을 Listing을 통해 알게 되었으니 Cloudfront URL을 통해 object에 접근이 가능하기 때문이다.

CloudFront URL을 통해 S3 object 접근

curl d2suiw06vujwz3.cloudfront.net/treasure8_CDN

=> 아주 손쉽게 CloudFront URL로 해당 object에 접근하여 다음 Level로 갈 수 있게 되었다~

< Level9 >

S3 Game

s3game-level9-781xtls2quvy.s3.us-east-2.amazonaws.com

=> 이번 문제는 referer에 관련된 문제로 IAM policy를 보면 aws:Referer가 "http://s3game.treasure"이여야 "s3game-level9-781xtls2quvy/treasure9_referer"를 GetObject 할 수 있다.

curl 명령어의 referer 옵션을 통한 요청

curl -e "http://s3game.treasure" https://s3game-level9-781xtls2quvy.s3.us-east-2.amazonaws.com/treasure9_referer

=> 문제에서 제공한 IAM Policy를 allow하기 위해 curl에 -e 옵션을 통해 referer값을 "http://s3game.treasure"로 맞춰주고 s3 bucket을 URL 형식으로 변환하여 요청하면 다음 Level로 갈 수 있게 된다 ~

< Level10 >

S3 Game

_ _______ _______ _ __ _______ ( \ ( ____ \|\ /|( ____ \( \ / \ ( __ ) | ( | ( \/| ) ( || ( \/| ( \/) ) | ( ) | | | | (__ | | | || (__ | | | | | | / | | | | __) ( ( ) )| __) | | | | | (/ /) | | | | ( \ \_/ / | ( | | | | | / | | | (____/\| (____/\ \ / | (__

s3game-level10-gac6tf83erp6.s3.us-east-2.amazonaws.com

=> Amazon S3는 용도에 따라 사용할 수 있게 다양한 storage classes를 제공하고 있다고 하며 대략적인 설명을 함께 제공하고 있다.

s3 bucket sync 이용

aws --profile test s3 sync s3://s3game-level10-gac6tf83erp6 .

=> 음.. 우선은 sync 명령을 통해 다운로드 하였더니 해당 bucket에서 2개의 파일만이 다운로드 되었다. 그 중 하나는 문제 페이지이고 나머지하나가 바로 우리가 찾던 다음 Level로 가는 정보가 들어있는 object 였다. 근데 풀고나서 드는 생각은 "문제의 힌트는 하나도 사용하지 않았는데 이렇게 푸는게 맞나???" 였는데.. 아니나 다를까 출제 의도는 이렇게 푸는게 아니였다.. 크흠...

s3api list-object에 --query 사용

aws --profile test s3api list-objects --bucket s3game-level10-gac6tf83erp6 --query 'Contents[?StorageClass == `STANDARD_IA`]'
aws --profile test s3 cp s3://s3game-level10-gac6tf83erp6/djq30a807iyq -

=> s3api의 list-object에 StorageClass가 "STANDARD_IA"인 것을 조회하였더니 하나의 object만 확인할 수 있었다. 출제자의 의도는 이렇게 푸는 것이 맞는 것 같다...ㅎㅎ 출제자는 아마도 수많은 object를 다 확인하지 않을거라고 생각한 것 같지만 하나의 object만 접근이 가능해서 아주 쉽게 날로 풀었다.. 아니면 문제를 위해서 알면서도 뒀을지도..

< Level11 마지막 문제 >

S3 Game

s3game-level11-djq30a807iyq.s3.us-east-2.amazonaws.com

=> 이번 문제에서는 평문파일의 object를 안전하게 지키기위해 암호화하는 기능인 SSE(Server-Side Encryption)에 대해서 말하고 있다. 참고로 AWS에서는 S3 암호화 옵션을 활성화하면 자동으로 수행해준다.

=> 문제에서는 암호화에 사용된 Server-Side Encryption Key 값을 알려주고 있기 때문에 GetObject 시, 옵션으로 사용하면 --sse-c-key를 통해 object를 복호화하여 다운로드 할 수 있다. SSE는 SSE-S3 또는 SSE-KMS 키를 암호화 옵션을 지정할 수 있으며 둘다 AES256 알고리즘을 사용하여 데이터를 암호화 한다.

s3 bucket object Listing & get object

aws --profile test s3 ls s3://s3game-level11-djq30a807iyq
aws --profile test s3 cp s3://s3game-level11-djq30a807iyq/treasure11_encryption -

=> 해당 bucket에는 treasure11_encrpytion이라는 의심스러운 object가 존재했다. 내용을 보고 싶었지만 400 Error로 (이렇게 간단하게 풀릴리가 없기 때문에) 당연히 실패했다. 그렇다면 문제에서 제공한 --sse-c랑 --sse-c-key 옵션을 통해 Server-side key값을 사용해보자.

Server-side key 값을 이용하여 s3 get object 진행

aws --profile test s3 cp s3://s3game-level11-djq30a807iyq/treasure11_encryption - --sse-c AES256 --sse-c-key "UkXp2s5v8y/B?E(H+MbPeShVmYq3t6w9"

=> 마지막으로 가는 URL까지 알아낼 수 있었다. 마지막 문제는 생각보다 쉽게 끝났다~

< Level12 모든 Treasure을 다모았다>

S3 Game

s3game-level12-bk0m5ax5n92o.s3.us-east-2.amazonaws.com

=> 이렇게 해당 s3game 11문제를 ALL Clear 했다~ s3에 전반적인 부분들을 익힐 수 있는 좋은 문제들이였다~

[Openshift] OCP구축하기(feat. Assisted Installer)

IMyoungho — Sat, 12 Aug 2023 20:06:31 +0900

OCP란

Product Documentation for OpenShift Container Platform 4.13 | Red Hat Customer Portal

Access Red Hat’s knowledge, guidance, and support through your subscription.

access.redhat.com

회사에서 OCP 관련 업무를 맡게되어서 구축해보았다.

Openshift Contianer Platform의 약자인 OCP는 Kubernetes 기반의 Redhat에서 만든 서비스이다.

kubernetes에 추가적으로 monitoring, logging, CI/CD, Service Mesh 등의 운영에 필요하거나 편리한 tool들이 포함되어있다.

그렇다면 이제 구축해보자!!

Assisted Installer를 이용한 OCP 구축(4.13버전)

Hybrid Cloud Console

console.redhat.com

이번 포스팅에서는 처음부터 끝까지 구축하기보다는 Openshift에서 제공하는 Assisted Installer를 사용하여 구축해보려고한다.

1. Redhat Hybrid Cloud Console에 접속하자.

=> Red Hat Openshit로 접속한다.

2. Cluster 생성(최소 Node 3개이상 필요)

=> Cluster를 생성해보자. 나는 Local에 설치한 VM fusion을 이용하여 cluster를 구축할 것이다. Cluster name과 Base Domain을 원하는 값으로 작성해주고 CPU를 설정해준다. 나의 경우 M2 MacBook이라 Arm64로 설정해주었다. 나머지는 기본값으로 진행했다(컴퓨터 사양때문에 조금 가볍게 진행하고 싶다면 Single Node Openshift - SNO를 선택하자)

3. Host 추가

=> Operators에서는 기본값으로 진행했고 이제 OCP를 구성할 Host를 찾을 수 있도록 설정해보자.

- ISO image generate

=> Assisted Installer를 사용하는 이유가 아닌가 싶다. Cluster를 구성할 Node들에서 설정해야할 내용들을 알아서 ISO 이미지로 만들어준다. 이를 Generate하기전에 나의경우 Provisioning type을 Minimal image file로 선택해주었고 그다음 내가 사용할 SSH public key만 준비해서 넣어주면된다. 아래의 Generate를 클릭하면 오른쪽 그림과 같이 ISO 이미지를 다운로드 할 수 있게 된다.

4. VM Fusion을 이용한 node 생성

=> Cluster에서 Node로 사용될 가상머신을 만들어주었다. 참고로 Openshift의 node들은 굉장히 고사양이 필요하다. 어지간한 노트북으로는 구축도 안된다...나도 꽤많은 프로세서와 메모리, 하드(400GB)를 넣어주었다. 참고로 해당 클러스터 구축 시, 필요한 최소사양이 있으니 참고하길 바란다.

[주의] 가상머신 생성

=> 참고로 생성을 진행하게되면 위와같은 화면을 보게될텐데. "왜 멈췄지??" 하면서 삭제하고 다시 만드는 삽질은 하지말길 바란다. 대략 2~5분사이를 대기하면 자동으로 만들어진다(ㅠㅠ안되는줄알고 삽질했다..) 이런식으로 3개를 만들어주자!

5. Cluster를 구성할 Node Role 선택

=> Node를 모두 생성하게되면 console에서 자동으로 탐지를 진행한다. 위와같이 목록에 생성한 3개의 node가 보여지면 Role을 선택해준다. Control plane node를 선택했지만 자동으로 Controlplane node + worker node가 되었다. 이후 storage는 Pass했다. 참고로 최소 클러스터 구성조건은 Master, Worker node 각각 3개이상이다. 하지만 하나의 node를 master와 worker로 사용이 가능했다. 따라서 3대만 있어도 구축은 가능하다.

6. Networking 설정

=> API IP와 Ingress IP를 설정해주고 다음으로 넘어가자

7. Cluster Installation

=> 어떤설정으로 cluster가 구축될지 preview를 해주고 install을 진행하면 cluster를 생성하기 시작한다. 이 때부터는 그냥 기다리기만하면된다. 내 기준 1시간 정도 걸렸던 것 같다.

설치완료 & Web Console 접속

=> 그렇다면 이제 Web Console에 접속해보자 계정의 경우 아래에 알려주고 있다. Web Console에 접근이 되지 않는다면 DNS 설정이 되지 않아서인데 아래에 친절하게 접근되지 않을 경우 조치방법을 알려주고 있다. "/etc/hosts" 파일 또는 "/etc/resolves.conf" 파일에 안내하는 내용을 붙여넣어주면 된다. 위와같이 드디어 Web Console에 접근할 수 있게된다!!

kubectl 또는 OC 사용

oc login

=> 해당 명령을 진행하면 관리자 계정에 대한 token 정보나 login 방법, API 사용예시 등을 알려준다.

=> 추가적으로 kubectl을 사용하기위해서는 kubeconfig를 이용해야한다. kubectl은 API요청을 편리하게 사용하는 것과 같다고 볼 수 있으며 그때 사용하는 인증정보가 kubeconfig에 담겨있기 때문에 해당 파일관리는 중요하다.

kubectl 또는 oc 명령어를 통해 다음과 같이 Pod가 조회되지 않는다면 .kube/config파일을 다운로드한 kubeconfig 파일로 대체해보자. 우리가 보통 구축해서 사용하던 kubernetes와 다르게 방대한 양의 Pod가 돌고 있는 것을 볼 수 있었다.

[ 참고 ] OCP Command-line interface tool

Hybrid Cloud Console

console.redhat.com

=> OCP를 관리할 때 사용할 tool은 위의 경로에서 설치하면 된다.

[ 자동완성 ]

# zsh 사용시
oc completion zsh > oc

# bash 사용시
oc completion bash > oc

# 이후 .zshrc 또는 .bashrc 파일 하단에 아래내용 입력 후 저장
=> source {경로}/oc 추가

# source .zshrc 또는 source .bashrc 실행

[AWS] flAWS2 Challenge - Level3(Attacker)

IMyoungho — Thu, 20 Jul 2023 10:15:33 +0900

flAWS2.cloud

level3-oc6ou6dnkw8sszwvdrraxc5t5udrsw3s.flaws2.cloud

[AWS] flAWS Challenge - Level5

flAWS level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud 문제확인 => 해당 문제에서는 그저 HTTP proxy 역할만하는 EC2를 sample로 주고 사용법을 알려주고 있다. 실제로 proxy인지 테스트 해보았고 진짜 단순한 proxy

xn--vj5b11biyw.kr

=> 옹? 이번문제는 기존에 flaws-1에서 풀었던 Level5와 비슷한 문제이다. 해당 문제와 동일하게 Proxy만 하나 제시해준다. 그외에 별다른 힌트는 주지않았지만 기존에 풀었던 문제처럼 뭔가 내부에 접근가능한 요청을 보내서 정보를 유출시켜야 할 것 같다.

혹시?? 50000% 안될 것 같지만??

인스턴스 메타데이터 검색 - Amazon Elastic Compute Cloud

Amazon EC2가 새 인스턴스 메타데이터 빌드를 릴리스할 때마다 코드를 업데이트하지 않으려면 버전 번호가 아니라, 경로에서 latest를 사용하는 것이 좋습니다. 예를 들어, 다음과 같이 latest를 사용

docs.aws.amazon.com

http://container.target.flaws2.cloud/proxy/http://169.254.169.254/latest/meta-data/

=> flaws-1 Level5에서 진행했던 instance metadata 검색으로 시도해봤지만 아무런 반응이 없다ㅎㅎ 역시 똑같은 문제는 낼리가 없었다. 그렇다면 비슷한 방법중에 다른게 뭐가 있을까 구글링을 시도했다.

Task Metadata Endpoint 검색

Task Metadata Endpoint version 2 - Amazon Elastic Container Service

The task metadata version 2 endpoint is no longer being actively maintained. We recommend that you update the task metadata version 4 endpoint to get the latest metadata endpoint information. For more information, see Task metadata endpoint version 4. Begi

docs.aws.amazon.com

http://container.target.flaws2.cloud/proxy/http://169.254.170.2/v2/metadata

JSON Formatter & Validator

Format and validate JSON data so that it can easily be read by human beings.

jsonformatter.curiousconcept.com

=> 오 뭔가 Json 형식의 많은 데이터가 나왔다. 아무것도 안나오다가 나오니 반갑다.. 해당 서비스의 container 관련된 정보들으로 추청된다. Json 포멧 정렬을 진행해서 보도록하자.

JSON 데이터 확인

=> 해당 데이터를 보았을 때 ECS(Elastic Container Servivce)로 배포된 것을 알 수 있었고 ECS Cluster에 Task인 Container set에 대한 정보도 확인이 가능했다(현재 해당 Cluster에는 2개의 Docker Container가 존재했다).

[AWS] ECS vs Kubernetes

컨테이너 서비스인 AWS ECS와 Kubernetes에 대해 비교해보려고 한다. 먼저 많이 언급되는 컨테이너 서비스의 장점을 먼저 살펴보자.- Continuous Delivery(CD): 흔히 DevOps에서 언급하는 지속적 배포 과정을

timewizhan.tistory.com

=> Json 데이터를 보니 Task내에 Pause container 추정되는 container + 다른 container가 같이 존재하는 것을 보고 ECS의 Cluster내의 Task는 Kubernetes의 Pod와 같은건가?? 했는데 같다고 할 순 없지만 찾아보니 비슷한 건 맞긴 했다..ㅎㅎ

=> 하지만 결론적으로 딱히 나에게 필요한 정보는 없는 것 같았다. 음....

LFI(Local File Inclusion) - 참고: https://www.hahwul.com/cullinan/file-inclusion/

file: URI 에 대한 궁금증

file:URI 에 대한 개념 및 사용법, StackOverflow, Wikipedia

velog.io

http://container.target.flaws2.cloud/proxy/file:///proc/self/environ

=> LFI를 통해서 해당 container의 환경변수관련 파일에 접근이 가능했으며 환경변수에는 AWS_CONTAINER_CREDNTIALS_RELATIVE_URI라는 값이 존재했다. 대놓고 AWS container와 credential과 관련있는 URI라고 써있는게 정답이라고 티내고있다. 그래서 해당 경로로 접근해보았다.

AWS_CONTAINER_CREDNTIALS_RELATIVE_URL 접근

http://container.target.flaws2.cloud/proxy/http://169.254.170.2/v2/credentials/4c79e5cb-786b-4ceb-a0e2-a94a1c9b073a

=> 우리가 찾던 반가운 credential 값이 보였다. 그렇다면 이제 credential을 사용해보자.

Credential 등록 & S3 bucket내의 객체 확인(Listing)

aws configure --profile gg
aws --profile gg sts get-caller-identity
aws --profile gg s3 ls

=> 우리가 원하던 마지막 화면을 볼 수 있게 되었다.

flAWS2.cloud

the-end-962b72bjahfm5b4wcktm8t9z4sapemjb.flaws2.cloud

=> Attacker 문제는 여기까지라고 한다. 이번문제를 통해 배운 것은 AWS의 다양한 서비스들이다(ECS, instance, fragate, LFI 관련) 결과적으로는 flaws-Level5번 문제에 이어서 Task, Instance와 같이 endpoint에서 metadata 검색이 가능한 부분에 대해서도 반드시 필요한 경우가 아니라면 제한을 하는 것이 좋다.. proxy같은 서비스를 제공할 때는 file scheme 등 관련해서 내부 중요 파일이나 설정파일에 대해 접근제한 하도록 검증 로직을 적용하는 것도 필수적이라는 생각이 들었다.

=> 다음 포스팅부터는 Defender를 풀어보고 포스팅해보겠다.