roki_1213

AWS accesskey 를 어플리케이션에서 사용하고 있습니다.

그러던 중 AWS 키 유출을 확인하게 되었고, 조치 방법 및 유출사유 (원인 [추정]) 작성했습니다.

조치 (1)

1. 다행이 키 유출이 되었지만 IP 제한 정책이 있어서 실제 공격은 차단되었습니다.

2. 유출 키 제거

3. 원인 조치

원인 파악 (2)

1. log 분석

2. 분석 결과 /actuator/heapdump 엔드포인트가 오픈 상태였습니다 (ㅠㅠ)

3. 일단 ALB 라우팅 설정에서 /actuator/heapdump 경로를 차단했습니다.

4. github, gitlab 에서 모든 actuator 설정을 확인 (과거 개발 코드에서 동일한 이슈가 있던것으로 파악했습니다.)

*/actuator/heapdump란

히프덤프(Heapdump)는 특정 시점에서 프로그램의 메모리 상태를 캡처한 스냅샷입니다. 주로 JavaScript 애플리케이션에서 사용되며, 힙 메모리에 있는 객체들의 메모리 할당 상태와 객체 간의 참조 관계를 담고 있습니다.

현재 Github action self hosted runner 구성은 서버에 프로세스 형태로 구성하기 또는 쿠버네티스에 ARC 로 구성하는 방법이 있습니다.

참고 : 

 ARC : https://tech.buzzvil.com/blog/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EC%97%90%EA%B2%8C-github-actions-%EC%84%A4%EC%B9%98%EC%97%90-%EB%8C%80%ED%95%B4-%EB%AC%BB%EB%8B%A4/

저는 특정 상황 때문에 이미지 파일로 구성하려고 합니다. 

도커 파일 

FROM ubuntu:22.04


ARG PERSONAL_ACCESS_TOKEN
ARG HOST=https://github.com
ARG ORGANIZATION
ARG REPOSITORY

ENV BINARY_URL=https://github.com/actions/runner/releases/download/v2.315.0/actions-runner-linux-x64-2.315.0.tar.gz

ENV RUNNER_NAME=myRunner
ENV RUNNER_GROUP=Default
ENV RUNNER_LABELS="self-hosted,Linux"
ENV RUNNER_WORKDIR=_work

RUN apt-get update && \
    apt-get install -y dotnet-sdk-6.0 curl sudo && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

SHELL ["/bin/bash", "-o", "pipefail", "-c"]
RUN useradd runner && \
    echo "runner:runner" | chpasswd && \
    chsh -s /usr/bin/bash runner && \
    usermod -aG sudo runner && \
    mkdir /actions-runner && \

    chown runner:runner /actions-runner

USER runner
WORKDIR /actions-runner

RUN curl -fsSL -o actions-runner-linux-x64-2.315.0.tar.gz -L $BINARY_URL && \
    tar xf ./actions-runner-linux-x64-2.315.0.tar.gz && \
    rm actions-runner-linux-x64-2.315.0.tar.gz && \
    rm actions-runner.tar.gz && \
    echo $PERSONAL_ACCESS_TOKEN && \
    ./config.sh \
        --unattended \
        --url $HOST/$ORGANIZATION/$REPOSITORY \
        --pat $PERSONAL_ACCESS_TOKEN \
 #      --token $PERSONAL_ACCESS_TOKEN \
        --name $RUNNER_NAME \
        --runnergroup $RUNNER_GROUP \
        --labels $RUNNER_LABELS \
        --work $RUNNER_WORKDIR

CMD ["nohup","./run.sh", "&"]

모니터링 중앙화 ?

쿠버네틱스 안에 프로메테우스가 있고 외부에 있는 서버의 메트릭 프로메테우스로 가지고 오기

k8s (프로메테우스 ) - 외부 서브넷에 있는 서버 (Cadvisor)

--------------------------------------------

현재 상태 : Prometheus, Grafana Helm 으로 구성

1. 추가 서버에서 cadvisor 설치 (컨테이너 실행 or 바이너리 파일로 실행)

참고 : os 별 (https://github.com/google/cadvisor/blob/master/docs/running.md)

컨테이너 실행이나 바이너리 파일 실행도 서버 재기동을 생각해서 docker restart, systemd 에 등록이 필요합니다.

sudo docker run -d --restart always --volume=/:/rootfs:ro --volume=/var/run:/var/run:ro --volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/docker:ro --volume=/dev/disk/:/dev/disk:ro --publish=8080:8080 --detach=true --name=cadvisor --privileged --device=/dev/kmsg gcr.io/cadvisor/cadvisor:latest

2. 프로메테우스 설정 파일에 하기 내용 추가

extraScrapeConfigs: |
  - job_name: 'test-api'  
    scrape_interval: 5s  
    static_configs:  
    - targets: ['172.3.61.111:8080']
      labels:
        type: AWS-EC2

3. 프로메테우스 target 에서 수집이 잘되는지 확인

모니터링 구성 (import 13946)- 그라파나 버전에 따라 많은 수정이 필요합니다.

혹시 몰라서 테스트

kube-prometheus-stack 에서 동일하게 구성하기

https://malwareanalysis.tistory.com/566
https://www.jacobbaek.com/1540

프로메테우스 설정 파일에 하기 내용 추가 (헬름)

prometheus:
  prometheusSpec:
    additionalScrapeConfigs:
      - job_name: "test-api"
        scrape_interval: 5s
        static_configs:
          - targets: ["172.3.61.111:8080"]
            labels:
              type: AWS-EC2

컨테이너 로그를 ELK 스택으로 수집을 했습니다.

최근 서비스 배포 후 pod 내부 filebeat 6.7.0실행이 되지 않아 원인을 찾어 조치한 내용을 공유 드립니다.

하기 블로그를 참고하여 조치 했습니다.

https://velog.io/@jhbaik1501/Filebeat-%EC%8B%A4%ED%96%89-%EC%98%A4%EB%A5%98-runtimecgo-pthreadcreate-failed-Operation-not-permitted

이슈 발생 후 다양한 원인 추정

1. 오픈 파일 수 제한 ?

2. 메모리 리소스 부족 (모니터링 확인 결과 아니였습니다.)

3. filebeat 디버그 모드 실행? (로그 수집)

3번을 생각하고 

filebeat 기존 로그 확인 (/var/log/filebeat)

config 테스트 (filebit test config)

filebeat -e -c filebeat.yml (실행 시 발생하는 로그 확인)

위에 블로그와 동일한 이슈 발생  

runtime/cgo: pthread_create failed: Operation not permitted 등등

과거 amazon linux2023에서도 동일한 이슈가 있었는데 까먹고 있었다. ㅠㅠ

해당 시스템은 데비안 12 를 사용하고 있고 apt-get update 하면서 libc 가 업데이트 되었습니다. 

filebeat.yml에 하기 내용을 추가 후 조치 했습니다. (오류 원인은 위에 블로그에서 확인 부탁드립니다!)

seccomp:
  default_action: allow
  syscalls:
  - action: allow
    names:
    - rseq

최근들어 다양한 컨테이너 이미지를 사용하면서 우분투, 데비안, 알파인 리눅스 등등 사용하면 패키지 (yum, apt, apk) 등등 동작 방식 및 버전 관리에 중요성을 느끼고 있습니다. 

2023년도 4월 1일 [DNS]네이버 클라우드 스터디 다녀왔습니다.

실습 내용 :  https://brunch.co.kr/@topasvga/3132

후기 : 

dns ns 서버 장애 발생 전 대비 방법 및 이유를 듣고 이해를 하게 되었습니다. (https://brunch.co.kr/@topasvga/3097)

정리된 용어

  DNS :

     레코드 등록 시 장애 대비하여 ttl 을 미리 수정이 필요합니다. (기존에 ttl 설정이 1일 경우 당장 변경하여도 1일 뒤에 캐쉬에 수정 됩니다.)

 네임서버 :

  1주에 한번은 백업을 하자

   가비아 ns ttl 기본 1일

   AWS  ns ttl 기본 2일

 도메인 등록 대행기관 (가비아, 아이네임즈, 후이즈)

 캐쉬 DNS (KT 등등)

    여러개의 등록된 네임 서버 쿼리가 이중화 되어 있는 것이 아니라 % 로 질의한다는 것을 알게되었습니다.

     * 로컬 dns 캐쉬는 다를 수 있습니다. 

실습 중 문의 내용

1. 제가 구매한 도메인은 ns ttl 설정이 1일 인데 ns 를 변경해도 바로 적용이 되는지 문의를 드렸습니다.

    답변 : 다른 누군가 쿼리를 보내야 캐쉬 DNS 저장이 되는데 쿼리가 없어 저장된 것이 없었다.

네이버 클라우드

Global DNS같은 경우 모든 서비스 사용자들이 동일한 ns를 사용하게 됩니다. 

그래서 내부에 누군가 도메인을 등록하면 네이버 클라우드에 연락하여 조치가 필요합니다.

  AWS 같은 경우 랜덤한 ns를 사용자들에게 분배해서 네이버 클라우드와 동일한 이슈는 거의 발생하지 않는것으로 추측하고 있습니다.

LB

LB 존이 따로 필요합니다.

LB 는 프라이빗 존에서 있습니다. 

추가로 공부하려는 것

https://medium.com/ctc-mzc/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%97%90%EC%84%9C-%EC%9A%94%EC%B2%AD%ED%95%9C-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%9D%84-dns-%EB%A5%BC-%ED%86%B5%ED%95%B4-%ED%95%B4%EC%84%9D%EB%90%98%EB%8A%94-%EC%A0%88%EC%B0%A8%EB%A5%BC-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90-a3cce5307840

루트 dns 13개 이유 

 DNS와 특정 프로토콜들의 제한, 즉 파편화되지 않은 사용자 데이터그램 프로토콜(UDP) 패킷의 실질적인 크기 제한으로 인해 루트 서버 수를 13개 서버 주소로 제한하도록 결정되었다.2020년 1월 11일 기준으로 애니캐스트 어드레싱을 사용하면 루트 서버 인스턴스의 실제 수  를 더 크게 잡을 수 있으며 그 수는 1034이다.

DNS 실전 교과서  책 읽어보기

레코드 분석

https://www.youtube.com/watch?v=1I3hMwQU6GU&t=5644s

면접을 본 곳에서 대량 발송 처리를 위한 Messaging System 아키텍쳐 구성도를 과제로 요청을 해서 만들어 봤습니다. 

과거에 msp 업무를 진행하면서 이런 서비스를 구성 해본적이 경험이 없어 많이 고민을 했습니다. 

주로 했던 고민에 첫번째는 다양한 메시지 서비스 (RabbitMQ, Apache Kafka, SQS) 들이 있는데 어떤 서비스를 사용 할 것인가 ?

두번째는 사용을 해본적이 없어 해당 구성도를 그려도 되는가? 를 가장 고민을 했습니다. 

요청 사항

* SQS FIFO를  높은 처리량 모드 변경이 필요합니다.

* FIFO 대기열 값으로 오토 스케일링 설정합니다. 

* 구성도에서는 FIFO 대기열을 1개만 존재하지만 SNS 와 SQS를 같이 사용하여 팬 아웃 구조로 사용하여 서비스 속도를 증가할 수 있을 것 같습니다.

* 성공 여부를 어떤 방식으로 전송하는 기준이 정확지 않아서 SNS 서비스를 사용하였습니다.

후기

1. 조금 더 다양한 서비스 workshop, awsskillbuilder 을 진행하면서 구성을 이해하는 노력이 필요하다.

2. 다양한 서비스가 합쳐지면 요구사항에 "1,000 TPS 처리" 가능 할까? 어떻게 측정해야되는가?? 

AWS Certified Solutions Architect - Associate (SAA-C03) 시험을 보고 후기를 적습니다. 

2020년도에 통과를 했지만 회사에서 ec2, alb ,vpc, s3, cloud front 정도에 서비스만 사용해서 다른 서비스가 기억이 잘 나지않아서 다시 시험을 받습니다. 

다행이 합격했습니다. :)

문제를 풀면서 주로 특정 키워드를 찾고 해당 키워드에 맞는 서비스의 특징을 예상하면서 문제를 풀었습니다. 

examtopics 사이트에서는 정답 보다는 토론에 내용을 보면서 aws 서비스 특징을 정리했습니다.

주로 사용한 사이트 목록 

https://docs.aws.amazon.com/ko_kr/index.html

https://www.examtopics.com/

https://explore.skillbuilder.aws/

참고

2023년 1월 16일부터 2023년 4월 17일까지의 기간 사이에 Pearson VUE를 통해 AWS 시험을 예약하실 때, 이번 프로모션 코드를 입력하시면, 추후 재응시가 필요한 경우 무료 재응시가 가능합니다.

주제 : 카오스 엔지니어링

해당 온라인 밋업을 듣고 나서 카오스 엔지니어링이 필요한 이유 및 다양한 툴이 있는 사실에 알게 되었습니다. 

카오스 엔지니어링을 하려면 모니터링 설정에서 다양한 정보를 수집하고 분석하는 지식이 필요할 것 같습니다.

현재는 공부하기 힘들지만 추후 테스트 해보려고 합니다!

이해되는 내용을 정리하자면 

카오스 엔지니어링의 구현 :

 - 가설 수립 -> 결함 주입 -> 관찰 -> 개선

 - 정상 상태와 비정상 상태를 명확하게 구분을 지어야 한다.

 - 장애가 발생하면 대조군과  실험군의 데이터로 정상 상태 차이를 찾아서 가설을 반증 한다.

 - 필요한것 IaC <-> CI/CD <-> 테스트 자동화 <-> 마이크로 서비스<-> 클라우드 네이티브 <-> ㅜNoSql (Nosql의 필요성은 아직 잘 이해하지 못했습니다.)

 - 작은 단위 부터 테스트 : 인스턴스 -> 클러스터 그룹 -> 가용영역 ->  리전 ->  클라우드 서비스

사용되는 서비스 or tool

chat.openai를 사용해보고 후기를 남깁니다. 

결론만 말하면 정말 대단합니다. 

간단한 aws eks 생성, terraform 코드 작성, 문의한 내용에 보완되면 좋은 것들 등등 최대한 깔끔하게 내용이 출력됩니다.

문의 내용을 자세히 기입할 수록 내용이 잘 나옵니다. 

앞으로 공부하다가 모른는 것이 있으면 chat.openai에 물어볼것 같습니다. 

예시