반응형

https://www.wiz.io/blog/brokensesame-accidental-write-permissions-to-private-registry-allowed-potential-r

 

#BrokenSesame: Accidental ‘write’ permissions to private registry allowed potential RCE to Alibaba Cloud Database Services |

A container escape vulnerability, combined with accidental 'write' permissions to a private registry, opened a backdoor for Wiz Research to access Alibaba Cloud databases and potentially compromise its services through a supply-chain attack

www.wiz.io

 

 

공격 흐름

Privilege Escalation (권한 상승)

루트 권한으로 1분마다 바이너리를 실행하는 cronjob 발견

 

$: ls -lah /etc/cron.d/tsar 
-rw-r--r-- 1 root root 99 Apr 19  2021 /etc/cron.d/tsar 

$: cat /etc/cron.d/tsar 

# cron tsar collect once per minute 
MAILTO="" 
* * * * * root /usr/bin/tsar --cron > /dev/null 2>&1

 

cronjob 으로 실행하는 tstar 의 바이너리의 의존성을 확인해보니 사용자의 write 권한이 있는 바이너리를 실행하고 있음

(/u01/adbpg/lib/libgcc_s.so.1)

 

 

$: ls -alh /u01/adbpg/lib/libgcc_s.so.1 
-rwxr-xr-x 1 adbpgadmin adbpgadmin 102K Oct 27 12:22 /u01/adbpg/lib/libgcc_s.so.1

 

  • 코드를 루트로 실행할 수 있도록 SUID 권한으로 libgcc_s.so.1 파일을 복사
  • patchELF 유틸리티로 libgcc_s.so.1 라이브러리에 종속성 추가
  • libgcc_s.so.1 라이브러리를 공격 코드가 기재되어 있는 라이브러리로 덮어씌움
  • /usr/bin/tsar 라이브러리가 실행되기를 기다림

 

Container Escape (호스트 노드로 이동)

Alibaba Cloud 포털의 SSL Encryption 기능을 on / off 했을 때 수행되는 행위 조사

 

# Command lines of the spawned processes
su - adbpgadmin -c scp /home/adbpgadmin/xxx_ssl_files/* 
*REDACTED*:/home/adbpgadmin/data/master/seg-1/ 

/usr/bin/ssh -x -oForwardAgent=no -oPermitLocalCommand=no -oClearAllForwardings=yes 
-- *REDACTED* scp -d -t /home/adbpgadmin/data/master/seg-1/

 

  • 생성된 프로세스 중 컨테이너에 존재하지 않는 경로가 명령줄에 포함되어 있어
  • PID 네임스페이스를 공유하는 다른 컨테이너에서 생성되고 있다고 추론

 

SCP 프로세스가 실행되기를 기다린 다음, 파일 시스템에 접근할 수 있는지 조사

 

# The Python script we used to access the second container filesystem
import psutil 
import os 
listed = set() 
while True: 
    for proc in psutil.process_iter(): 
        try: 
            processName = proc.name() 
            processID = proc.pid 
            cmdLine = proc.cmdline() 
            if processID not in listed and processName == 'scp': 
                os.system('ls -alh /proc/{}/root/'.format(processID)) 

                listed.add(processID) 
        except (psutil.NoSuchProcess, psutil.AccessDenied, psutil.ZombieProcess):
          pass

 

두 컨테이너가 같은 홈 디렉토리를 마운트해서 사용하고 있음을 확인

홈 디렉토리가 공유될 때마다 SSH 명령이 실행되기 때문에 로컬 SSH 클라이언트 구성 파일을 수정해서 임의의 명령을 실행 할 수 있도록 수정 (LocalCommnad 필드를 통해 구성할 수 있음)

 

 

SSL Encryption 기능을 활성화 / 비활성화하기 위해 임시로 생성된 컨테이너에서 /run/docker.sock 이 열려져 있는 것을 확인함

 

/run/docker.sock 도커 데몬을 통해 영구적으로 권한이 상승된 컨테이너를 생성. 자세한 사항은 아래 내용을 참고

https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#mounted-docker-socket-escape

 

Docker Breakout / Privilege Escalation | HackTricks

If you somehow have privileged access over a process outside of the container, you could run something like nsenter --target --all or nsenter --target --mount --net --pid --cgroup to run a shell with the same ns restrictions (hopefully none) as that proces

book.hacktricks.xyz

 

Lateral Movement (측면 이동)

멀티테넌시 환경에서 다른 테넌트의 자원을 사용할 수 있었음 (측면 이동이라기 보다는 멀티 테넌시 악용)

k8s API 서버에 엑세스하여 kubectl 명령어로 다른 테넌트의 pod 를 접속하여 정보 접근이 가능했음

 

# Listing the pods inside the K8s cluster
$: /tmp/kubectl get pods 
NAME                                                                       READY   STATUS      RESTARTS   AGE 
gp-4xo3*REDACTED*-master-100333536                                      1/1     Running     0          5d1h 
gp-4xo3*REDACTED*-master-100333537                                      1/1     Running     0          5d1h 
gp-4xo3*REDACTED*-segment-100333538                                     1/1     Running     0          5d1h 
gp-4xo3*REDACTED*-segment-100333539                                     1/1     Running     0          5d1h 
gp-4xo3*REDACTED*-segment-100333540                                     1/1     Running     0          5d1h 
gp-4xo3*REDACTED*-segment-100333541                                     1/1     Running     0          5d1h 
gp-gw87*REDACTED*-master-100292154                                      1/1     Running     0          175d 
gp-gw87*REDACTED*-master-100292155                                      1/1     Running     0          175d 
gp-gw87*REDACTED*-segment-100292156                                     1/1     Running     0          175d 
gp-gw87*REDACTED*-segment-100292157                                     1/1     Running     0          175d 
gp-gw87*REDACTED*-segment-100292158                                     1/1     Running     0          175d 
gp-gw87*REDACTED*-segment-100292159                                     1/1     Running     0          175d 
...

 

자격증명 탈취를 위해 docker 이미지 스펙들을 조사하던 찰나, 프라이빗 레지스트리 저장소에서 이미지를 불러오는 것을 확인함

 

# A snippet of the pods configuration, illustrating the use of a private container registry 

"spec": { 
    "containers": [ 
        { 
            "image": "*REDACTED*.eu-central-1.aliyuncs.com/apsaradb_*REDACTED*/*REDACTED*", 
            "imagePullPolicy": "IfNotPresent", 
...            
    "imagePullSecrets": [ 
        { 
            "name": "docker-image-secret" 
        } 
    ],

 

kubectl 명령어로 secret 확인

 

# Retrieving the container registry secret
$: /tmp/kubectl get secret -o json docker-image-secret 
{ 
    "apiVersion": "v1", 
    "data": { 
        ".dockerconfigjson": "eyJhdXRoc*REDACTED*" 
    }, 
    "kind": "Secret", 
    "metadata": { 
        "creationTimestamp": "2020-11-12T14:57:36Z", 
        "name": "docker-image-secret", 
        "namespace": "default", 
        "resourceVersion": "2705", 
        "selfLink": "/api/v1/namespaces/default/secrets/docker-image-secret", 
        "uid": "6cb90d8b-1557-467a-b398-ab988db27908" 
    }, 
    "type": "kubernetes.io/dockerconfigjson" 
} 

# Redacted decoded credentials
{ 
    "auths": { 
        "registry-vpc.eu-central-1.aliyuncs.com": { 
            "auth": "*REDACTED*", 
            "password": "*REDACTED*", 
            "username": "apsaradb*REDACTED*" 
        } 
    } 
}

 

컨테이너 이미지 레지스트리에 대한 자격 증명을 테스트한 결과 , 읽기 액세스 권한뿐만 아니라 쓰기 권한도 있다는 것을 발견 즉, 최소 권한의 원칙이 지켜지지 않았음

반응형
반응형

 

ssh {접속하려고 하는 서버의 계정}@{접속하려고 하는 서버의 IP 나 도메인} 명령어 형태로 실행되며 사용할 수 있는 옵션은 다음과 같다. ssh 명령어는 ssh client 에서 실행해야 한다.

 

옵션 설명
-i 개인키 파일(identity pem file)
-p 포트 번호 지정. (기본 22번 포트 번호가 아닌 다른 포트 번호를 사용할 때 사용)
-L 로컬 터널링 (로컬 포트 포워딩)
-L {로컬 포트}:{목적지 IP}:{목적지 포트} {SSH 서버의 계정}@{SSH 서버의 IP 나 도메인}
-R 리모트 터널링 (리모트 포트 포워딩)
-R {로컬 포트}:{목적지 IP}:{목적지 포트} {SSH 서버의 계정}@{SSH 서버의 IP 나 도메인}
-D 다이나믹 터널링

 

로컬 터널링과 리모트 터널링, 다이나믹 터널링에 대한 자세한 예제는 다음과 같다.

 

로컬 터널링

 

 

리모트 터널링

 

 

다이나믹 터널링

 

반응형
반응형

두 스토리지 타입 모두 인스턴스가 종료되어도 저장하기 위한 용도로 사용된다.

 

EBS

  • 네트워크 볼륨 드라이브 (USB Stick)
    • 네트워크 사용 필요
  • 하나의 인스턴스에만 마운트 가능 (advanced 한 방법으로 multi-attach 도 가능)
  • 특정 가용성 존에 연결
  • EBS Elastic Volume
    • 볼륨 사이즈 변경 가능 ( 용량은 늘릴 수 있지만 줄일 수 없음 )
    • IOPS 나 처리량만 변경 가능 
    • 가동 중지 시간 없이 바로 변경 ( 인스턴스를 재시작하거나 볼륨을 삭제하지 않아도 된다 )
  • 사용 시 주의사항
    • 기본적으 인스턴스가 종료될 때 Root EBS 볼륨도 같이 삭제된다
    • Root EBS 볼륨이 삭제되지 않으려면 'Delete on Terminated' 옵션을 비활성화한다
    • 기본적으로 다른 부착된 EBS 볼륨은 삭제되지 않는다

EFS

  • 완전관리형 NFS (Network File System)
  • 많은 인스턴스에 동시에 마운트 가능
  • POSIX 파일 시스템 (표준 파일 API)
    • AMI 기반 Linux 인스턴스에 부착 가능 (윈도우 불가능)
  • NFS v4.1 프로토콜 사용
  • Security Group 으로 Access 제어할 수 있음
  • KMS 서비스를 통한 암호화 가능
  • 용량 계획 필요 없음. 자동 스케일링 지원
  • 성능
    • NFS 에 1000 개의 세션이 동시 접근 가능하고 각각 10 GB / s 처리량 가능
    • 최대 Peta Byte 용량까지 지원 가능 자동 스케일링
  • 성능 모드
    • EFS 생성 시에 설정 가능 
    • 일반 목적 - 민감한 지연 시간이 필요한 서비스에 사용 가능 (웹 서버, CMS)
    •  Max I/O  - 더 높은 최대 처리량 / 병렬 실행 (빅데이터, 미디어 처리)
  • 처리량 모드
    • 버스팅 - 1TB 는 초당 50MB 인데 버스트는 초당 100MB 까지 상승 가
    • 프로비저닝 - 스토리지 크기에 상관 없이 처리량 설정 가능
    • 엘라스틱 - 워크로드 기반 자동 스케일링 업 / 다운 지원
      • 초당 3GB 읽기 / 초당 1GB 쓰기 업 가능
  • 클래스
    • lifecycle 정책 설정하여 일정한 기간 이후 계층 이동 가능
    • Standard - 스토리지에 자주 접근이 필요한 경우
    • IA(Infrequent Access) - 자주 접근하지 않은 경우. 더 저렴한 비용
    • Archive - 1년에 한 번 접근하는 경우. 50% 저렴한 비용
  • 가용성과 내구성
    • Standard - 여러 가용 영역에 배치. 프로덕션용으로 적합
    • One-zone - 한 개의 가용역역에 배치. 개발용으로 적합

EBS vs EFS

  EBS (Elastic Block Store) EFS (Elastic File System)
접근 가능 여부 1 개의 AZ 영역 마운트 가능 Multi-AZ 영역 마운트 가능
용량 ~ GBs ~ IOPs
(프로비저닝 필요)
사실상 무제한
(프로비저닝 불필요)
사용 사례 부팅 볼륨
트랜잭션
가상머신(VM)
데이터 공유
컨텐츠 관리
웹 서빙 (Wordpress)

 

반응형

'인프라 > AWS' 카테고리의 다른 글

AWS S3 정리  (6) 2024.09.01
AWS Step Functions  (0) 2024.08.20
AWS Service Catalog  (0) 2024.08.19
Amazon EKS 역할 / 네트워크 / 볼륨 / 모니터링  (0) 2024.07.20
반응형

S3 정의

  • 객체 스토리지
    • 버킷은 디렉토리, 객체는 파일과 유사
    • 객체 크기는 5TB 까지 저장
  • 무한히 스케일링이 가능
  • 버킷 이름은 모든 계정 모든 리전 통틀어 유일해야 한다
  • 버킷은 리전에 위치
  • 사용 사례
    • 아카이브 저장
    • 백업 및 장애 복구
    • 어플리케이션, 미디어 호스팅
    • 데이터 레이크
    • 정적 웹 사이트 호스팅

 

S3 복제

  CRR (Cross-Region Replication)
(교차 리전 복제)
SRR (Same-Region Replication)
(동일 리전 복제)
복제 대상 모든 오브젝트 또는 prefix 나 tag 기반 하위 오브젝트
복제 지역 다른 AWS 지역 같은 AWS 지역
목적 컴플라이언스 준수
대기 시간 최소화
다른 계정 복제
재해 복구
로그 통합
프로덕션 계정과 테스트 계정 간에 라이브 복제 구성
운영 효율성 증가
 

S3 Storage Class

스토리지 클래스 설계 이유 내구성 가용성 가용영역 최소 스토리지 기간 최소 요금 객체 크기 기타 고려 사항
S3 Standard 자주 액세스하는 데이터(한 달에 한 번 이상), 밀리초 단위의 액세스 99.999999999% 99.99% >= 3 없음 없음 없음
S3 Standard-IA 밀리초 단위의 액세스로 한 달에 한 번 이따금 액세스하는 수명이 긴 데이터 99.999999999% 99.9% >= 3 30일 128KB GB당 검색 요금이 적용됩니다.
S3 Intelligent-Tiering 알 수 없거나 변경되거나 예측할 수 없는 액세스 패턴이 있는 데이터 99.999999999% 99.9% >= 3 없음 None 객체당 모니터링 및 자동화 비용이 적용됩니다. 검색 요금이 없습니다.
S3 One Zone-IA 재생성 가능하고 자주 액세스하지 않는 데이터(한 달에 한 번), 밀리초 단위의 액세스 99.999999999% 99.5% 1 30일 128KB GB당 검색 요금이 적용됩니다. 가용 영역의 손실에 대한 복원력이 없습니다.
S3 Express One Zone 단일 AWS 가용 영역 내에서 지연 시간에 민감한 애플리케이션을 위한 10밀리초 미만의 데이터 액세스 99.999999999% 99.95% 1 None None S3 Express One Zone 객체는 선택한 단일 AWS 가용 영역에 저장됩니다.
S3 Glacier Instant Retrieval 밀리초 단위의 액세스로 분기에 한 번 액세스하는 수명이 긴 아카이브 데이터 99.999999999% 99.9% >= 3 90일 128KB GB당 검색 요금이 적용됩니다.
S3 Glacier Flexible Retrieval 몇 분에서 몇 시간의 검색 시간으로 1년에 한 번 액세스하는 수명이 긴 아카이브 데이터 99.999999999% 99.99%(객체 복원 후) >= 3 90일 NA* GB당 검색 요금이 적용됩니다. 이 객체에 액세스하려면 먼저 보관된 객체를 복원해야 합니다. 자세한 정보는 아카이브된 객체 복원 섹션을 참조하세요.
S3 Glacier Deep Archive 몇 시간의 검색 시간으로 1년에 한 번 미만 액세스하는 수명이 긴 아카이브 데이터 99.999999999% 99.99%(객체 복원 후) >= 3 180일 NA** GB당 검색 요금이 적용됩니다. 이 객체에 액세스하려면 먼저 보관된 객체를 복원해야 합니다. 자세한 정보는 아카이브된 객체 복원 섹션을 참조하세요.

 

S3 Lifecycle Rules

 

  • LifeCycle Rule 을 통해 S3 버킷 스토리지 클래스를 자동으로 전환할 수 있다.
  • 스토리지 클래스를 전환할 뿐만 아니라 유효기간이 만료되어 삭제도 가능하다. (전환 작업, 만료 작업)
  • 버킷 전체나 버킷 내부 특정 Prefix 단위, Tag 단위로 설정이 가능하다.
  • 사용 시 주의사항
    • Standard => Standard-IA => Intelligent-tier => OneZone-IA => Glacier => Deep-Archive 클래스로 순으로 전환이가능하지만 역순은 불가능하다. 사본 생성 후 사본을 옮겨야 한다.
  • 사용 사례
    • 이미지 원본은 60일 이내에 즉시 복구가 가능하고, 썸네일은 쉽게 만들 수 있는데 마찬가지로 60일 정도 보관하고 6시간 이내에 복구해야 한다.
      • => 이미지 원본은 Standard 보관, 60일 이후 Glacier 로 전환, 썸네일 이미지는 OneZone-IA 보관 60일 이후 삭제
    • 드물지만 삭제된 객체는 30일 이내에 즉시 복구가 가능해야 하고, 최대 1년까지는 삭제한 객체를 48시간 내 복구해야 한다.
      • => S3 버저닝 활성화 후, 이전 버전은 Standard-IA 로 전환하고 30일 이후에는 Glacier Deep-Archive 로 전환

S3 Analytics

  • 스토리지 접근 패턴을 분석해 언제 S3 스토리지 객체를 변환해야 하는지 S3 Analytics 서비스를 사용할 수 있다.
  • 오직 Standard 로 부터 Standard-IA 로 보낼 때만 사용 가능하다.
  • 데이터 분석이 가능하도록 보고서 (.csv) 가 24 ~ 48 시간 주기로 매일 업데이트된다.

 

S3 Event

  • S3 EventBridge 로 전달하거나 직접 SNS, SQS, Lambda 로 보낼 수 있다.
  • 직접 보내는 경우, 여러 개의 이벤트 소스로 전달할 수 있다.
  • 직접 보내는 경우 S3 가 행동할 수 있도록 SNS, SQS, Lambda 의 Resource Policy 정책이 허용되어 있어야 한다.

 

S3 Performance

baseline

  • S3 는 아주 많은 수의 요청량을 처리하기 위해 자동으로 스케일링한다. 지연율은 보통 100 ~ 200 ms 정도이다.
  • 버킷의 prefix 당 최대 초당 쓰기 요청(PUT/COPY/POST/DELETE) 횟수은 3,500, 최대 초당 읽기 요청(GET/HEAD) 횟수은 5,500 이다.
  • 버킷의 총 최대 요청 횟수와 버킷 당 prefix 의 개수는 제한이 없으므로 더 많은 요청을 받기 위해서는 요청량이 집중되는 오브젝트 단위를 분석해 prefix 로 분리해야 한다.
  • 사용 사례
    • bucket/1/file => /1/, bucket/2/file => /2/, bucket/3/file => /3/, bucket/4/file => /4/ 라면 최대 22,000 요청량 가능

Multi-Part Upload (분할 업로드)

  • 매우 큰 파일을 업로드 시 전송 속도를 향상하기 위해 파일을 분할하여 병렬 업로드한다.
  • 100MB 이상 파일은 분할 업로드 권장, 5GB 이상 파일은 분할 업로드 필수
  • 사용 사례

S3 Transfer Acceleration

  • 버킷 파일을 AWS 의 엣지 로케이션으로 전송함으로써 접송 속도를 높이는 방식이다.
  • 공용 인터넷을 최소한으로 거치고 사설 AWS 네트워크 라인을 사용하기 때문에 속도가 훨씬 빠르다.
  • Multi-Part Upload 기능과 호환

S3 Byte-Range Fetches

  • 파일의 특정 바이트 일부 범위만 읽기 요청하는 방식이다.
  • 병렬 요청 가능
  • 사용 사례
    • 다운로드 속도 가속화
      • Multi-Part Upload 기능의 반대 전략으로 매우 큰 파일을 분할하여 병렬 다운로드한다. 예를 들어 100 GB 파일을 100 MB 씩 분할해서 10 번 반복 요청한다.
    • 헤더 부분 읽어서 파일 확장자 확인

 

S3 Encryption

Amazon S3에서는 4가지 방법으로 S3 버킷의 객체를 암호화할 수 있다.

  • Server-Side Encryption (SSE)
    • Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3)
      • Amazon S3 관리형 키를 사용하는 서버 측 암호화
    • Server-Side Encryption with KMS Keys stored in AWS KMS (SSE-KMS)
      • AWS KMS 키를 사용하는 서버 측 암호화
    • Server-Side Encryption with Customer-Provided Keys (SSE-C)
      • Client 가 제공하는 키를 사용하는 암호화
      • AWS Console 에서는 확인이 불가능하고, SDK 프로그래밍 방식만 지원 가능
  • Client-Side Encryption
    • Client 에서 직접 암호화 후 전송하고 다운로드 후 복호화하는 방식

SSE-S3

  • 기본 S3 객체 암호화 방식
  • AWS S3 에서 처리, 관리, 및 소유하는 키를 사용하여 암호화
  • AES-256 알고리즘으로 암호화
  • 클라이언트에서 "x-amz-server-side-encryption": "AES256" 로 header 조작 필요

SSE-KMS

  • AWS KMS(Key Management Service) 서비스를 통해 처리되고 관리되는 키를 사용하여 암호화
  • 사용자가 KMS 서비스를 통해 키를 관리할 수 있음
  • CloudTrail 로그를 통해서 키 사용 여부들을 감사 가능
  • 클라이언트에서 "x-amz-server-side-encryption": "aws:kms" 로 header 조작 필요
  • 사용 시 주의사항
    • 업로드 시 GenerateDataKey KMS API 를 호출하고, 다운로드 시에는 Decrypt KMS API 를 호출하는데 이 API 가 초당 할당량 제한이 있음. 지역에 따라 다르지만 5,500, 10,000, 30,000 req/s.
    •  쓰로틀링 방지를 위해, 서비스 할당량 콘솔을 통해 초당 할당량을 높인다.

SSE-C

  • Client 가 키를 생성해서 AWS 에 전송하고 서버 측에서 암호화 (Client 가 직접 키 관리)
  • HTTPS 에서만 가능
  • AWS 에서 키를 관리하지 않으므로 HTTPS 요청마다 암호화 키를 HTTP 헤더에 제공해야 함

Client-Side Encryption

  • AWS 에서 키 생성, 관리 및 암복호화 하지 않고 클라이언트 측에서 모두 수행하는 방식
  • Amazon S3 Client-Side Encryption Library 와 같은 클라이언트 라이브러리 사용
  • 클라이언트가 데이터를 S3 에 업로드하기 전에 암호화하고, 다운로드 후 복호화한다.

S3 전송 암호화 (SSL/TLS)

  • S3 는 두 가지 방식의 엔드포인트를 제공
    • HTTP 엔드포인트 (암호화하지 않음)
    • HTTPS 엔드포인트 (전송 중 암호화)
      • SSL 또는 TLS 방식으로 암호화
  • HTTPS 를 권장
  • 대부분의 클라이언트는 기본적으로 HTTPS 엔드포인트를 사용

S3 암호화 강제

  • S3 버킷 정책을 사용하여 전송 중 암호화를 강제하거나, 오브젝트 업로드 시 특정 암호화 방식으로 강제할 수 있음
  • 전송 중 암호화 강제
    • Effect => Deny
    • Condition => (Bool) aws:SecureTransport: false
  • S3 객체 업로드 시 암호화 헤더 없는 경우 거부
    • Effect => Deny
    • Condition => (StringNotEquals) s3:x-amz-server-side-encryption: aws:kms
    • Condition => (Null) s3:x-amz-server-side-encryption-customer-algorithm: true
  • 사용 사례
    • 왼쪽 정책은 SSE-KMS 방식 아니면 거부. 오른쪽 정책은 SSE-C 방식 아니면 거부.
  • 아니면 기본 암호화 방식을 채택할 수 있다.
  • 해당 버킷 정책은 항상 기본 암호화 전에 평가된다.

 

S3 Access Points

  • S3 에 접근하는 사용자나 그룹이 많아지고 S3 에 저장하는 데이터의 유형이 많아짐에 따라 Bucket Policy 에 모든 접근 권한을 설정하기가 복잡해졌다.
  • S3 버킷 Prefix 별로 사용자나 그룹의 접근 권한 설정을 한다.
  • 접근할 수 있는 포인트인 DNS Name 과 Access Point Policy 를 가지고 있다.
  • 사용 시 주의사항
    • VPC 내부에서만 접근하도록 설정하려면
      • VPC Endpoint(Interface 나 Gateway) 무조건 생성 필요
      • VPC Endpoint Policy 에서 S3 Access Point 와 S3 Bucket 둘 다 allow 정책 허용 필요

 

S3 Object Lambda

 

S3 CORS

  • 웹 브라우저에서 다른 Origin 에 대한 요청으로 인한 공격을 방지하고자 SOP(Same Origin Policy) 정책을 도입함
    • Origin은 scheme (protocol) + host (domain) + port 로 Same Origin 은 프로토콜, 도메인, 포트 번호가 같아야 함
  • 하지만 웹 사이트들이 다른 도메인 영역에 웹 자원을 로드하고 서비스하고 있는 경우가 많아 특정 Origin 만 접근이 가능하도록 설정이 필요했다. CORS(Cross-Origin Resourse Sharing) 이라는 기능이다.
  • 현재 웹 사이트를 방문하면서 다른 Origin 의 자원을 사용해야 하는 경우, 다른 Origin 서버에서 허용 응답을 보내주어야 한다.
    • 정확히는 응답 헤더로 Access-Control-Allow-Origin, Access-Control-Allow-Methods 등 CORS 헤더를 보내주어야 한다.
  • 마찬가지로 S3 에서도 CORS 헤더를 설정함으로써 특정 출처와 메서드들을 허용할 수 있다.

 

S3 Delete 방지

MFA 사용

  • 사용자가 중요한 S3 작업을 수행하기 전에 MFA (Multi-Factor Authentication) 다중 인증을 추가로 요구할 수 있다.
  • 버전 관리 활성화 필수
  • MFA Delete 기능을 활성화 / 비활성화 할 수 있는 권한은 버킷 소유자만 가능
  • MFA가 필요한 작업은 다음과 같다.
    • 객체 버전을 영구적으로 삭제
    • 버킷에서 버전 관리를 중단할 때

S3 Object Lock

  • WORM (Write Once Read Many) 모델로 지정된 기간 동안 특정 객체 버전을 삭제하는 것을 방지한다.
  • 버저닝 기능이 무조건 활성화 되어 있어야 함
  • 버킷 내의 모든 객체에 각각 적용 가능
  • 보관 모드
  • ( * 법적 보관은 보관모드는 아니나, 비교를 위해 같이 정리하였다 )
  Compliance (규정준수) Governance (거버넌스) Legal Hold (법적 보관)
삭제 가능 불가능 (루트 사용자 포함) 삭제 권한이 있는 일부 사용자만 가능 s3:PutObjectLegalHold IAM 권한 필요
보존 기간 보존 기간 설정 후 조작 불가능 보존 기간 설정 후 변경 가능 무기한
모드 변경 불가능 가능 가능

 

S3 Access Logs

  • 감사 목적으로 S3 버킷의 모든 액세스를 로깅할 수 있다.
  • 승인 또는 거부 여부와 상관없이 모든 계정에서 S3에 대한 요청이 로그로 남는다.
  • 로깅 대상 버킷은 동일한 AWS 리전에 있어야 한다.
  • Amazon S3 서버 액세스 로그 형식: https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/LogFormat.html
  • 사용 시 주의사항
    • 로깅 버킷을 모니터링하는 버킷과 동일하게 설정하면 무한 루프 발생

 

Pre-Signed URLs

  • 접근 권한 인증을 마쳤는데도 불구하고 다른 AWS 서비스 제한 때문에 S3 에 도달하지 못 할 수 있다.
  • 접근 권한에 대한 인증을 마치면 직접 S3 에 접근할 수 있는 URL 을 발급해준다.
  • URL 만료 기한
    • S3 Console 은 1분부터 720분(12시간)까지 설정 가능
    • AWS CLI 는 --expires-in 매개변수로 만료 시간을 지정할 수 있으며, 초 단위로 설정 가능 (기본값은 3600초, 최대 604800초(168시간))
  • 미리 서명된 URL을 받은 사용자는 GET / PUT에 대한 권한을 URL을 생성한 사용자로부터 상속받음.
  • 사용 사례
    • 로그인한 사용자만 S3 버킷에서 프리미엄 비디오를 다운로드할 수 있도록 허용
    • URL을 동적으로 생성하여 계속 변경되는 사용자 목록이 파일을 다운로드할 수 있도록 허용
    • 일시적으로 사용자가 S3 버킷의 특정 위치에 파일을 업로드할 수 있도록 허용
반응형

'인프라 > AWS' 카테고리의 다른 글

AWS EBS & EFS  (0) 2024.09.03
AWS Step Functions  (0) 2024.08.20
AWS Service Catalog  (0) 2024.08.19
Amazon EKS 역할 / 네트워크 / 볼륨 / 모니터링  (0) 2024.07.20
반응형

Step Functions

 

AWS 의 마이크로서비스 워크플로우 구현을 위한 오케스트레이션 서비스

Lambda 와 같은 서버리스 서비스들을 조합하여 구현

 

Step Functions 특징

  • AWS 의 다른 서비스들과 네이티브하게 연계 통합 가능
  • 비즈니스 로직 중심 워크플로우 설계 가능 (관리형 서비스(내결함성, 안정성, 확장성, 고가용성))
    • 빌트인 된 try-catch-finally 패턴을 통해 타임아웃, 재시도, 에러메세지 관리가 가능하여 장애 대응에 원할
    • 모니터링 후, 요청량에 따른 자동 스케일링 가능
  • 다양한 상태를 활용하여 워크플로우를 정의하기 쉬움

Step Functions 구조

Action 과 Flow 컴포넌트로 구성되어 있음

  • Action
    • 다른 AWS 서비스를 활용하여 작업을 수행
    • 예 : 람다 함수 호출, SNS Publish, AWS Fargate 서비스 호출
  • Flow
    • task 들의 제어 흐름을 정의하는 7가지 상태
    • 분기 choice, 반복 map, 동시 실행 parallel, 디버깅 path, 타이머 wait, 성공 success, 실패 fail

Step Functions 구축

Step Functions 는 특성 상 비지니스 로직과 밀접하게 연결되어 있어 인프라와 애플리케이션을 디커플링하여 개발하면 새로운 개발 요청이 들어왔을 때 인프라와 코드를 둘 다 수정해야 되는 단점이 있음.

 

따라서, 인프라와 애플리케이션을 커플링하여 서비스 변경에 더 민첩하게 반응할 수 있는 애플리케이션 특수적 인프라를 활용하는 추세임.

 

Step Functions 한계점

Step Functions 는 별도의 요청으로 상한을 올릴 수 있는 소프트 할당량과 상한을 올릴 수 없는 하드 할당량이 있다.

소프트 할당량은 유연하게 대처가 가능하므로 하드 할당량에 대해서 알아본다.

  • 페이로드의 최대 크기 (256 KB)

페이로드는 오직 실행이나 컨텍스트 관리에 필수적인 데이터만 포함하여 핸들링하는 것이 바람직하다.

이외 데이터들은 다른 서비스나 서버에 저장 후 로드한다.

  • 실행 기록의 최대 이벤트 개수 (25,000 개)

상태머신을 활용할 경우, Step Functions 는 해당 실행에 대한 모든 이벤트를 기록하기 시작한다.

각 상태마다 2 ~ 5 개 정도의 이벤트가 발생한다. 예를 들어 람다 호출의 경우, 람다 예약 => 람다 시작 => 람다 성공 순으로 이벤트가 기록된다.

 

이베트 개수를 줄이는 방법이 있을 수 있다. 하지만 권장하지 않는다.

예를 들어, 여러 개의 Lambda 함수를 활용하여 병렬처리하는 구조의 애플리케이션을 Lambda 함수 하나로 포팅한다면 이벤트의 개수는 줄일 수 있지만, 병렬 처리로 얻는 속도, 효율 등의 장점들을 모두 포기해야 한다.

 

Lambda 함수를 통해 상태머신을 재실행하는 방법을 AWS 에서 권장하고 있다.

 

1 . (plan) StateMachine 시작 전 작업 크기를 계산하고, 현재 실행 정보를 담고 있는 컨텍스트 정보를 생성한다.

  • 총 처리해야 하는 개수
  • 현재 처리 개수
  • 커서

2 . (fetch, apply) 병렬 작업자들에게 할당할 작업들을 생성하고 반복 처리한다.

  • 최대 동시성(동시 실행 가능한 작업자의 최댓값)을 고려하여 전체 작업을 처리 가능한 크기의 작업으로 분할한다.
  • 반복 실행을 통해 순차 처리한다. 아래 3, 4 단계를 참고한다.

3 . (aggregate) apply 결과 값들을 취합한다.

4 . 더 이상 작업이 없다면 Finish, 아직 작업이 있고 최대 반복 횟수 도달했다면 ExecuteNew, 최대 반복 횟수 미달했다면 다시 fetch 실행

4 - 1 . ExecuteNew 로 실행했다면 현재 실행의 Context 정보도 같이 전달하여 plan 재실행

 

Active Worker 패턴

AWS 서비스 이외에 다른 서비스(온 프레미스 서비스, 써드 파티 SDK, 다른 클라우드 서비스) 처리 시 지연시간으로 인해

비동기적인 처리가 필요할 수도 있다. 만약 Lambda 로 구현한다면 지속적으로 폴링해야 할 수도 있다. 불필요한 시간을 소요할 수 있으며 결국 Lambda 의 최대 실행 시간인 15분을 넘길 수 있다.

 

외부 서비스와 통합하기 위해 Activity 를 사용하는 것을 권고한다. 상태머신의 진행을 비동기적으로 바꿀 수 있다.

 

 

그런데 아래 공식 문서는 코드 분리 측면으로 봐야되고, 위 병렬 실행 TIP 과는 다른 컨셉으로 봐야 될 것 같다.

https://docs.aws.amazon.com/ko_kr/step-functions/latest/dg/tutorial-use-sfn-api-cont-exec.html

 

참고

https://www.youtube.com/watch?v=EZrL7p7Qlp4

 

 

 

반응형

'인프라 > AWS' 카테고리의 다른 글

AWS EBS & EFS  (0) 2024.09.03
AWS S3 정리  (6) 2024.09.01
AWS Service Catalog  (0) 2024.08.19
Amazon EKS 역할 / 네트워크 / 볼륨 / 모니터링  (0) 2024.07.20
반응형

 

개념

인프라 구축을 코드형 인프라(IaC) 로 구성할 수 있도록 괸리된 환경에서 배포해주는 서비스

  • 지정된 사용자가 원하는 서비스를 골라 프로비저닝
  • 해당 서비스에 다양한 Action 들까지 제공
  • CloudFormation 으로 구성
  • 내부적으로는 Systems Manager Automation 사용

구조

AWS Service Catalog 는 제품, 포트폴리오으로 구성되어 있다.

 

제품

  • 엔드유저에게 제공할 미리 구성된 AWS 인프라
  • 각 제품 별 버전 설정 가능
  • 신규 버전 생성 시 서비스 액션 역시 다시 연동 필요
  • CloudFormation Output 으로 엔드유저에게 정보 제

포트폴리오

  • 다양한 제품을 모은 관리 단위
  • 그룹/역할/사용자에게 해당 포트폴리오를 이용할 수 있는 권한 부여 가능
  • 다른 계정과 공유 가능
  • AWS Budget 생성 가능 (Tag 기반)

제약조건

  • 사용자가 제품을 프로비전할 때 사용하는 권한
  • 사용자가 권한을 가지고 있지 않더라도 제품을 생성하는데 필요한 권한 부여 가능
  • 반대로, 사용자가 충분한 권한을 가지고 있어도 제품을 생성 및 사용하는데 제약할 수 있는 권한 부여 가능
  • = > 즉 사용자의 권한을 가지고 프로비저닝을 하는 것이 아니라 제약 조건에 명시된 권한으로 프로비저닝
  • 서비스 액션 등에도 제약 조건 권한 사용 가능
  • IAM 정책 기반
  • 아래 유형의 권한으로 구성
    • 시작
    • 알림
    • 템플릿
    • StackSet
    • 태그 업데이트

서비스 액션

  • 앤드유저가 제품을 프로비전 후, 제품을 제한적으로 관리하는 방법
  • 각 액션 수행 후 이벤트 로그를 통해 수행 결과 확인 가능
  • 내부적으로는 Systems Manager Automation 사용

 

서비스 카탈로그 실습

1 . AWSServiceCatalogEndUserFullAccess 정책 가진  enduser 사용자를 생성한다.

(서비스 카탈로그에 접근 가능한 접근만 가지고 있다.)

2 . enduser 사용자가 사용할 제약조건 역할을 생성한다. 정책 생성 후 역할을 연결!

3 . 서비스 카탈로그에 제품 생성 후, 포트폴리오 생성한다.

4 . 해당 포트폴리오에 enduser 사용자를 추가하고 제약조건 역할을 연결한다.

 

인프라 관리자가 아니라면, 프로비저닝 하위 항목들만 표시된다. 인프라 관리자가 생성한 항목들만 확인할 수 있다.

 

삭제 시 주의해야 할 점

포트폴리오 삭제 시 제품과 포트폴리오에 연결된 주체/역할 부터 먼저 삭제해야 함

반응형

'인프라 > AWS' 카테고리의 다른 글

AWS EBS & EFS  (0) 2024.09.03
AWS S3 정리  (6) 2024.09.01
AWS Step Functions  (0) 2024.08.20
Amazon EKS 역할 / 네트워크 / 볼륨 / 모니터링  (0) 2024.07.20
반응형

0 . IAM 계정에서 AdministratorAccess 권한 추가

IAM 권한 권한  페이지에서 AdministratorAccess 권한이 있는지 확인한다. 없으면 해당 역할을 추가한다.

 

1 . AWS Identity Center devops 용 사용자 생성

계정 생성 시 기입한 이메일로 확인해서 계정 비밀번호를 생성해야 한다.

 

IAM Identity Center > 설정 > 자격증명 소스에서 AWS 액세스 포탈 URL 을 기억해둔다.

 

2 . AWS CLI 로컬에 설치

AWS 공식 홈페이지에서 각 운영체제에 맞게 AWS CLI 를 설치할 수 있다.

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

 

Install or update to the latest version of the AWS CLI - AWS Command Line Interface

When updating from a previous version, the unzip command prompts to overwrite existing files. To skip these prompts, such as with script automation, use the -u update flag for unzip. This flag automatically updates existing files and creates new ones as ne

docs.aws.amazon.com

 

Mac OS 기준 CLI 설치 명령어는 다음과 같다.

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

which aws
aws --version

 

3 . AWS SSO 설정

aws configure sso 명령어로 아래 SSO 를 세팅한다.

 

SSO session name : SSO 세션 이름

SSO start URL : AWS 액세스 포탈 URL (1에서 기억한 URL)

SSO region : SSO 계정이 활동할 region

SSO registration scopes : SSO 활동 범위 (디폴트 선택해도 무방)

 

이후 웹 페이지에서 SSO 계정 로그인

 

CLI default client Region : AWS CLI 가 활동할 region (SSO region 동일하게 적용)

CLI default output format : text, json, table 중 하나 선택 (디폴트로 text 선택)

 

aws s3 ls --profile SSO 사용자 명령어 실행 후, 명령어가 정상적으로 실행되는지 확인한다.

 

4 . AWS_PROFILE 환경변수 세팅

export AWS_PROFILE=SSO 사용자 이름

 

5 . terraform init && terraform plan 명령어 실행

terraform 프로바이더에 계정에 관련된 access_key, secret_key 삭제 후 테스트

반응형
반응형

 

 

Amazon EKS 가 마스터 노드를 Amazon EKS Node groups 가 워커 노드를 관리해준다.

 

EKS 인증

 

 

1 . kubectl 명령을 내리면 Kubernetes Master Node 서버에 API 호출

Kubernetes API 서버 인증 토큰과 IAM 인증 토큰(Kubeconfig 파일) 토큰을 함께 보냄.

2 . 요청한 사용자가 IAM User 맞는지만 확인

별도로 Policy 정책은 확인하지 않음. aws-auth 라는 configmap 생성함. (Kubectl edit configmap aws-auth -n kube-system 명령어로 확인 가능)

 

 

Groups 에는 쿠버네티스 RBAC 권한 정보가 포함됨.

 

EKS 역할

 

영역으로 분류

특정 네임스페이스 리소스 사용 권한 설정과 클러스터 전역의 리소스 사용 권한 설정으로 나뉠 있다.

 

책임으로 분류

IAM Role 유사하게 리소스에 대한 권한이 명시적으로 기재되어 있는 Role 해당 Role 권한을 할당받을 사용자나 그룹을 설정하는 Role Binding 으로 이루어져 있다.

 

사용자 추가하고 싶을

1 . IAM Role 생성

정책들은 확인하지 않고 사용자인지만 확인하기 때문에 역할만 생성해도 된다.

2 . aws-auth Configmap mapRole 추가

 

 

3 . ClusterRole 또는 Role 생성

 

 

4 . ClusterRoleBinding 또는 RoleBinding 생성

 

 

5 . aws-auth Configmap mapRole group 설정

 

 

6 . 대상 사용자의 kubeconfig 파일에 인증 정보 설정

kubectl 명령어를 호출할 , 어떤 role 실행할지 명시를 해주어야 하기 때문에 설정이 필요하다.

 

 

EKS 네트워크 구조

 

 

단일 호스트일 쿠버네티스 네트워크는 eth0 물리 네트워크 인터페이스, docker0 브릿지 네트워크, veth0 가상 네트워크 인터페이스 구조로 구성되어 있다. Pod 안에 여러 개의 컨테이너를 생성하면 가상 네트워크 인터페이스를 공유하면서 하나의 IP 부여받게 된다. Pause 컨테이너를 통해 공유하게 된다.

 

참고로 도커에서는 --net=container:컨테이너이름 옵션을 주게되면 위와 같이 컨테이너 네트워크 공유를 있다.

 

 

다중 호스트일 때는 위와 같이 호스트 내부 IP 충돌하는 문제가 발생할 있다. 그래서 호스트가 여러 되어도 컨테이너를 찾아갈 있게 모든 호스트의 브릿지 네트워크에 각기 다른 IP 할당하는 Overay Network 구조를 생각하게 되었다.

쿠버네티스 코어에 있는 것은 아니고 weave net 이나 AWS CNI, calico, flannel 쿠버네티스 플러그인으로 제공한다. Amazon EKS AWS CNI 사용한다.

 

그런데 AWS CNI 다른 플러그인과 다르게 가상 IP 부여하는 것이 아닌 VPC IP Range 내부 IP 할당하게 된다.

 

 

DaemonSet IPAM 이라는 모듈에서 ENI 로부터 IP 받아 Pod 할당하게 되는데

ENI 할당할 있는 IP 수를 초과하면 추가로 ENI 생성해서 IP 부여한다.

 

인스턴스 유형마다 최대 ENI 개수와 ENI 할당할 있는 최대 IP 주소가 다르다.

Amazon EC2 인스턴스 유형 사양 - Amazon EC2 ((트워크 사양 참고)

 

따라서 최대로 띄울 있는 Pod = 인스턴스 유형에 따른 ENI * (ENI IP - 1) 개이다. (ENI 자체가 할당 받는 IP 주소가 있으므로)

 

EKS 볼륨 관리

 

Pod 내려가면 데이터가 날라가기 때문에 안정적인 데이터 관리가 필요하다.

심플하게 안정적인 저장소를 준비한 다음 컨테이너에 안정적인 저장소를 마운트하면 된다. EBS EFS 준비한다.

 

1 . Storage Class 생성

어떤 저장소를 사용할 것인지 명시한다.

 

 

2 . Persistent Volume Claim 생성

어떤 스펙으로 생성할 것인지 명시한다.

 

 

3 . 컨테이너에 마운트

 

 

EKS 모니터링

 

마스터 노드 로그는 대상 클러스터 로깅 설정으로 CloudWatch 로그가 적재되고 확인할 있다.

Pod 모니터링은 Container Insights 통해 확인할 있다.

1 . 워커 노드의 IAM Role 편집

2 . CloudWatchAgentServerPolicy 정책 추가

3 . 빠른 시작 설정

4 . CloudWatch 페이지 이동

5 . Container Insights 선택

6 . 대상 EKS 클러스터 선택

 

출처

쿠알못이 Amazon EKS로 안정적인 서비스 운영하기 - 최용호 (넥슨코리아) :: AWS Community Day 2020 (youtube.com)

반응형

'인프라 > AWS' 카테고리의 다른 글

AWS EBS & EFS  (0) 2024.09.03
AWS S3 정리  (6) 2024.09.01
AWS Step Functions  (0) 2024.08.20
AWS Service Catalog  (0) 2024.08.19

+ Recent posts