업무를 하다가 Azure 테스트 환경을 배포하는 일이 생겼다. 근데, Azure가 생각보다 AWS보다 복잡해서 공부하는 겸, 이 글을 쓰게 되었다. 1. 전체 아키텍처 개요- 이번 글에서 다루는 환경은 하나의 Azure VNet 안에 다양한 데이터베이스를 배치한 테스트 인프라다. - 크게 두 부류로 나눈다.1) Azure Native 관리형 DB - Azure가 엔진, 패치, 백업을 관리해주는 Native 서비스 MySQL Flexible Server 8.0PostgreSQL Flexible Server 16Azure SQL Database (MSSQL 기반)Cosmos DB for MongoDB 6.0Cosmos DB for Cassandra 3.11Cosmos DB for PostgreSQL 16 (..
사전지식1. HTTP vs HTTPS 1) HTTP는 평문 통신이여서 가로채면 내용이 그대로 보인다. - HTTPS = HTTP + TLS 암호화 - 다음과 같은 세가지를 보장한다. 기밀성(Confidentiality) → 통신 내용을 암호화 (도청 방지)무결성(Integrity) → 데이터가 중간에 변조되지 않음인증(Authentication) → 상대방이 진짜 그 서버가 맞는지 확인- 세번째 인증이 트러블 슈팅에서 가장 많이 문제가 되는 부분 2) 인증서의 역할 - https://naver.com 접속 시, 그 서버가 진짜 네이버인지 알기 위해선 서버는 인증서를 클라이언트에 내밀어 신원을 증명한다.- 인증서가 제대로 된 인증서임을 증명할 필요가 있다. 왜냐하면, 인증서는 아..
사전지식1. name resolution의 흐름- 리눅스에서 도메인 이름을 IP로 변환하는 과정은 단순히 DNS 서버에 질의하는 것은 아니다. 여러 단계를 거치며, 어느 한 곳이라도 깨지면 Resolving은 실패.1) 순서 앱이 도메인 요청 → nsswitch.conf (어디서 먼저 찾을지 순서 결정) → files (/etc/hosts 파일 조회) → dns (/etc/resolv.conf에 지정된 DNS 서버에 질의) → iptables (DNS 패킷이 나갈 수 있는가?) → 외부 DNS 서버 2) 각 단계에서 확인할 파일과 역할/etc/nsswitch.conf → 이름 해석 순서 결정 (files가 먼저? dns가 먼저?)/etc/hosts →..
사전 지식 - tcpdump 패턴 세 가지 1. 세가지 패턴- 네트워크 접속이 안될 떄 tcpdump를 떠보면, 패킷 흐름의 패턴이 크게 세가지로 나뉨SYN → RST → 도달했지만 거부됨 (포트에 프로세스 없음 / REJECT 정책)SYN → 무응답(재전송 반복) → 패킷이 드랍됨 (DROP 정책 / NSG / 라우팅 문제)SYN → SYN-ACK 이후 문제 → 연결은 되지만 앱 레벨 이슈 (설정 오류 / SELinux) 2. iptables 테이블 구조- iptables -L의 경우 filter 테이블만 보여준다.- iptables는 filter외에도 여러 테이블이 존재1) 테이블 구조filter → 패킷 허용/차단 (기본, iptables -L로 보이는 것)n..
SELinux실습 #2부터 SELinux가 본격적으로 등장한다. 그 전에 SELinux가 무엇이고 왜 필요한지 이해하자 1. DAC vs MAC - 리눅스에서의 두 가지 접근제어 방식 1) DAC- 일반적인 리눅스의 권한시스템이라고 하면 chmod나 rwx, 644 같은 것을 떠올린다.- 실제로도 rwx(읽기/쓰기/실행)으로 구성된다.- 파일 소유자가 chmod로 권한을 자유롭게 읽기, 쓰기 ,실행을 조정할 수 있는데, 이를 DAC(임의적 접근제어)라고 한다. 2) DAC의 한계- DAC만으로는 보안이 부족하다.- 상황 예시 : Nginx가 해킹되어 nginx프로세스가 nginx유저로 실행되고 있으며, /etc/shadow 파일이 실수로 chmod 644로 설정되어 있다. - 이럴 경우, 권한을 갖게 ..
들어가며예전에는 혼자 공부하면서 한계를 많이 느꼈다. 일을 하고 있지만, 매번 시행착오를 겪으면서 배워나가야 했다.하지만, 개념적으로 미리 알고 업무에 대응하면 효율적으로 인프라를 운영할 수 있을 것이라고 생각했다.게다가 요즘엔 AI도 있으니, 여러 실제 상황을 트러블 슈팅하는 느낌으로 공부했다.방법은 이러했다.1) Claude에게 실제 장애 상황을 만들도록 스크립트를 짜달라고 했다.2) 스크립트를 실행한다. 3) 문제를 풀고 서버를 정상화 시킨다.4) 문제원인을 이론적/개념적으로 분석한다. 앞으로도 계속 이렇게 임하면서 개념을 분석해나갈 것이다.Linux VM에 의도적으로 장애를 만든 뒤, 직접 원을 추적하고 해결하는 실습을 기록해나갈 것이다.이를 통해 주먹구구식으로 '일단 되게 만들기'가 아니라 '왜..
1. RBAC(Role-Based Access Control)1) 정의 : 쿠버네티스에서 누가(Subject) + 뭘(Resource) + 어떻게 (Verb) 할 수 있는가를 정의하는 접근제어 메커니즘2) 다른 보안 솔루션이나 IAM Policy 에서 특정 계정/역할에 Select 만 가능하게하거나, Delete를 못하게 하는 것과 같은 계념3) 쿠버네티스에선 특정 Service Account만 Pod 조회만 가능, 삭제는 불가 이런식으로 정의하는 것을 의미2. 네임스페이스와 RBAC의 4가지 오브젝트1) Namespace : 클러스터 내에서 리소스를 논리적으로 격리하는 단위- 네임스페이스의 범위에 따라 RBAC 오브젝트가 나뉜다.범위권한 정의권한 연결(바인딩)네임스페이스 한정RoleRoleBinding..
1. 개요- EKS에 이어 AKS 구축- AKS는 EKS보다 심플1) 비교항목EKSAKSVPC/네트워크직접 생성 필수 자동 생성IAM Role직접 생성 필수 자동 생성Control Plane 비용$0.10/시간무료Terraform 리소스 수 22개2개생성 시간10분~15분5~10분2.프로젝트 구조terraform-azure-aks/├── main.tf├── variables.tf└── outputs.tf 3. 코드sjw1995628/terraform-azure-aks GitHub - sjw1995628/terraform-azure-aksContribute to sjw1995628/terraform-azure-aks development by creating an account on GitHub.githu..
sjw1995628/terraform-aws-eks GitHub - sjw1995628/terraform-aws-eksContribute to sjw1995628/terraform-aws-eks development by creating an account on GitHub.github.com 1. 개요- 프로젝트 목표더보기AWS EKS(Elastic Kubernetes Service)를 Terraform으로 구축하고, Nginx를 배포해 외부에서 접근 가능한 환경을 만드는 것이 목표입니다.- 아키텍처 (클로드가 만들어줌) ┌─────────────────────────────────────────┐ │ AWS C..
들어가며5편까지 모듈화, Branch Protection, Labels, tfvars 분리를 완성했습니다. 하지만 매번 terraform plan하고 terraform apply를 직접 쳐야 합니다.혼자 할 때는 괜찮지만, 팀에서 쓰면 문제가 됩니다.여러 명이 동시에 apply하면 충돌누가 언제 뭘 바꿨는지 추적 불가plan 안 보고 바로 apply하는 실수이번 편에서는 GitHub Actions를 이용해 PR을 올리면 자동으로 plan이 실행되고, main에 머지하면 자동으로 apply가 실행되는 CI/CD 파이프라인을 구축합니다.그리고 그 과정에서 만난 실수들도 함께 공유합니다.1. GitHub Actions1) 지금까지의 방식- terraform apply, plan 매번 수동으로 진행- 매번 수동..