Security & DevOps

AWS Security Group 검토 자동화 대시보드 개발기

MR. ZERO — Mon, 10 Nov 2025 23:36:07 +0900

1. Security Group Review Dashboard 소개

Security Group의 적정성 검토, 어떻게 하고 계시나요?

ISMS의 '2.10.1 보안시스템 운영' 항목은 보안시스템에 설정된 정책의 타당성 여부를 주기적으로 검토하도록 요구하고 있습니다. 이에 따라 기업의 보안담당자는 정해진 주기마다 방화벽 정책을 검토하는데요.

레거시 한 방화벽의 정책을 검토하는 것도 쉽지 않지만, 더 큰 문제는 AWS의 Security Group을 검토할 때 발생합니다. 담당자들이 흔히 겪는 어려움은 다음과 같습니다.

SG가 어떤 리소스에 attach되어 있는지, 미사용하고 있는지 한눈에 보기 어렵다
출발지/목적지를 IP가 아닌 SG를 참조하는 경우, 심지어 2차, 3차로 참조되는 경우 정책 흐름 파악이 복잡하다
출발지 IP 혹은 서비스 범위가 과도하게 넓은 룰을 일괄적으로 조회하기 어렵다
순환 참조나 정책 충돌이 발생했는지 확인하기 힘들다

이처럼 AWS 콘솔이나 CLI만으로는 실무에서 검토하고 싶은 정보들을 한 번에 확인하기 어렵습니다. 이런 불편함을 해소하고 업무 생산성과 SG의 보안 수준을 함께 높이기 위해, Claude Code를 활용해 “Security Group Review Dashboard”(이하 SG 대시보드)를 개발했습니다.

SecurityGorup Review Dashboard를 통해 확인한 SG 관계도(보안을 위해 데이터는 마스킹 처리)

검토가 필요한 SG만 확인할 수 있도록 필터 기능을 활용해 가시성 확보(보안을 위해 데이터는 마스킹 처리)

SG 대시보드는 리소스가 어떤 SG에 연결되어 있고, 각 SG 간 참조 관계를 시각적으로 표현하여 한눈에 파악할 수 있도록 하는 것을 목표로 합니다. 이와 함께 보안 리스크, 순환 참조, 정책 충돌 여부 등도 한 번에 점검할 수 있도록 개발했습니다. 다음은 SG 대시보드에서 제공하는 기능입니다.

멀티어카운트 지원
필터를 활용해 특정 어카운트 조회
필터를 활용해 특정 VPC 조회
특정 객체 검색 기능
SG 간 참조 표시
순환 참조 규칙 표시
충돌 규칙 표시
보안 위험 규칙 표시
미사용 SG 숨김
미사용 SG 목록 json/csv 추출
SG를 참조하는 EC2 / RDS / LB / VPC Endpoint 표시
객체 클릭 시 세부정보 출력
대시보드 객체가 수천개가 되어도 느려지지 않도록 성능 최적화

2. SG 대시보드 작동 원리

처음에는 Steampipe로 데이터를 쿼리하고 Powerpipe로 시각화하려 했지만, Powerpipe로는 관계도 기반의 대시보드를 표현하기에 한계가 있어서 HTML + JavaScript를 활용해 프론트엔드를 구성했습니다. SG 대시보드를 실행하기 위해 필요한 준비물은 네 가지입니다. 이 중에서 3번과 4번을 ClaudeCode를 활용해 개발했습니다.

AWS CLI를 실행 가능한 로컬 환경
steampipe 설치
데이터 추출용 파이썬 스크립트
대시보드 구성용 html

전체 흐름은 단순합니다. 별도 인프라를 구성할 필요 없이 로컬 환경에서 바로 실행할 수 있도록 설계했습니다. 만약 대시보드 객체가 수십만 개를 넘는 경우, 간단한 웹서버를 구동시켜 대시보드에 접속하는 방식도 가능합니다.

데이터 추출용 파이썬 스크립트 실행 → 스크립트가 steampipe로 쿼리 호출 → 쿼리로 얻은 데이터를 기반으로 대시보드 구성

3. 개발 후기

그동안 SG의 복잡성 때문에 적정성 검토를 충분히 하지 못한 점이 늘 마음에 걸렸습니다. 특히 1인 보안 담당자로서 모든 AWS 계정의 Security Group을 수동으로 검토하는 것은 큰 부담이었습니다. SG 대시보드를 통해 이제는 검토가 필요한 SG를 명확히 식별할 수 있고, SG 간 관계를 시각적으로 한눈에 파악할 수 있게 되어 업무 부담이 크게 줄었습니다.

또 ClaudeCode를 활용해 2.5일 만에 오직 자연어만으로 이런 도구를 만들 수 있는 것도 참 놀랍습니다. AI 서비스가 상용화되기 전에는 아이디어가 있어도 개발 능력이 따라주지 않아 구현하지 못하는 경우가 왕왕 있었는데요. 이제는 아이디어만 있다면 업무에 필요한 자동화 도구를 자체적으로 개발할 수 있는 세상이 되었음을 체감합니다. 생성형 AI를 기존에도 잘 활용하고 있었지만, 이제는 업무에 뗄레야 뗄 수 없는 팀원이 되었네요.

24년도 ISMS-P 인증심사원 자격검정 실기시험 합격 후기

MR. ZERO — Sat, 14 Dec 2024 14:01:09 +0900

1. 들어가며

ISMS-P 인증심사원 자격 증명서

24년도 ISMS-P 인증심사원 자격검정 실기시험 결과가 11.28.에 발표되었습니다. 5월부터 준비를 시작했으니 장장 7개월 만에 막을 내렸네요. 마음 한편에 찝찝하게 남아있던 짐덩어리가 사라져서 홀가분합니다.

앞서 작성했던 필기시험 합격 후기를 많은 분들이 읽어주시고 공유해주셨는데요. 막막한 시험 준비에 조금이나마 도움이 된 것 같아 뿌듯합니다. 지난 글의 내용 중 일부를 인용하며 실기시험 합격 후기를 시작합니다.

시중에는 수험생을 유혹하는 수백 만 원대의 온/오프라인 강의와 신뢰도를 알 수 없는 유료 이북이 성행하고 있는데요. 이런 상황에서 ISMS-P 자격검정을 공부하시는 분들께 조금이나마 명확한 학습 방향을 제시하고, 불필요한 비용 지출 없이 KISA 공식 문서와 법령만으로 합격할 수 있었던 방법을 공유하기 위해 시험 합격 후기를 작성합니다.

2. 자격검정 타임라인

ISMS-P 인증심사원 시험을 준비하시는 분들이 학습일정을 효과적으로 계획할 수 있도록 필기와 실기를 비롯한 24년도 전체 시험 타임라인을 공유합니다.

세부적인 일정은 조금씩 다를 수 있지만 큰 틀에서는 향후 시험에서도 큰 변화가 없을 것으로 예상됩니다. 처음 시험을 신청한다면 시험 신청서를 미리 준비해서 빠르게 제출하는 것을 추천드립니다. 작성 및 구비해야 할 서류가 많기 때문에 제출일자에 근접해서 준비하기에는 시간이 무척 촉박합니다.

3. 실기시험 준비 방법

필기시험을 합격해 실기시험을 준비하고 있다면 인증기준에 대한 지식은 갖추어진 상태일 것입니다. 따라서 실기시험은 심사원의 관점에서 주어진 상황을 빠르게 판단하고, 올바른 결함을 식별하는 훈련을 하는 것이 핵심인데요.

필기시험 합격자는 일주일간 ISMS-P 실무교육을 의무적으로 수강하면서, 결함을 식별하는 방법과 보고서를 작성하는 방법을 배우게 됩니다. 이때 제공되는 시나리오를 열심히 분석하고 보고서를 쓰는 법을 연습했습니다. 강사님이 내주신 과제도 성실하게 임하고 부족한 부분에 대해 피드백을 받았습니다.

실무교육을 마치고 나서는 가상의 시나리오를 만들어서 결함 보고서를 작성하는 연습을 했습니다. 실기시험을 앞둔 동료가 있어서 서로 작성한 보고서에 대해 피드백을 주고받으면서 각자의 부족한 점을 보완했습니다. 또한 타이머를 활용해 시간을 체크하면서 보고서를 작성했습니다. 보고서 하나당 15 ~ 20분을 목표로 작성하는 연습을 했습니다.

결함 보고서를 작성하는데 있어 중요한 포인트는 다음과 같습니다. 이점을 유념하면서 보고서를 작성하는 것이 중요합니다.

육하원칙으로 작성
운영현황은 마련되어 있는 내부 규정과 현황을 엮어서 기재
결함내역을 구체적이고 가독성있게 작성
조치사항은 구체적인 방법 또는 기술을 서술하기보다는 방향을 제시하는 뉘앙스로 작성
운영현황/결함내역/조치사항 세 가지 내용의 흐름이 기승전결을 갖추고 결함항목과 일치성이 있어야 함

4. 실기시험 당일

실기시험은 서초고등학교에서 치러졌습니다. 필기시험을 치렀던 경기고등학교보다 학교 크기가 훨씬 작아서 시험장까지 가는데 무리가 없었습니다.

정문으로 들어가면 바로 옆 게시판에서 고사실을 확인할 수 있습니다.

총 7개의 고사장이 있었고 각 반마다 25명의 수험생이 배치됐습니다. 마지막 7 고사실은 전년도 실기시험에서 떨어진 응시자들이 있는 교실이었습니다.

24년도 필기시험에 약 3천 명이 응시했을 것으로 추정되고, 실기시험은 150명(25*6 고사실(재수생 제외))이 치렀으니 24년도 ISMS-P 필기시험의 합격률은 약 5%로 생각됩니다. 필기시험 응시자 수를 정확히 몰라서 확실한 수치는 아닙니다.

4.1. 문제 유형

실기시험 문제 유형은 크게 세 가지고 합격점수는 70점 이상입니다. 결함보고서를 작성하는 문제가 배점이 25점으로 가장 크고 나머지 문제는 10점 배점입니다.

인터뷰 질문사항 작성 1문제
- 자산목록, 네트워크 구성도 등을 참고하여 심사원 관점에서 추가로 질문할 사항 작성
예비결함 항목 작성 4문제
- 개인정보 수집 동의서, 인터뷰 내용 등을 참고하여 통제항목/결함내역/조치사항 작성
결함보고서 작성 2문제
- 제공된 모든 자료(인터뷰 내용, 구성도, 자산목록, 규정 등)를 참고하여 결함 보고서 작성

4.2. 실기시험 Tip

시험 시작 시 시험문제 1권, 답안지 1권, 내부규정 1권, 인증기준 책받침 1개를 지급합니다. 책상이 좁기 때문에 이 자료들을 체계화해서 배치해야 문제풀이 및 정답 작성을 효율적으로 할 수 있습니다.
결함보고서를 작성하는 문제가 가장 크기 때문에 이 두 문제를 확실히 맞혀야만 합격할 수 있습니다. 따라서 가장 먼저 두 문제를 풀거나 혹은 어느 정도 몸이 풀리고 나서 결함보고서 작성을 시작하는 등 전략적으로 판단해야 합니다.
개인정보 수집 시 안내 항목, 국외 이전 시 안내 항목 등 각종 개인정보 동의 안내 시 고지해야 하는 항목을 암기하면 좋습니다.

5. 시험 준비에 도움 된 글

ISMS-P 인증심사원 필기합격자 실무교육 및 실기 시험 준비

SaaS 엔드포인트 보안솔루션 엑소스피어 도입 및 운영 후기

MR. ZERO — Sun, 18 Aug 2024 15:55:00 +0900

1. 들어가며

스타트업 1인 보안담당자로 업무를 하다 보면 수많은 어려움을 마주하게 됩니다. 대표적으로 보안솔루션 도입이 그러한 난관 중 하나인데요. 특히나 엔드포인트 보안솔루션은 도입함에 있어 고민할 것이 정말 많습니다. 가격과 성능은 물론이거니와 임직원이 느끼는 불편함은 어느 정도인지, 배포와 운영의 편의성은 갖춰져 있는지, Mac은 지원하는지 등등 고민할 지점이 여러 가지죠.

이러한 고민을 모두 해결할 수 있는 제품을 도입하기 위해 다양한 솔루션을 리서치하고 PoC를 거쳐 엑소스피어 올인원(링크)을 도입했고 현재까지 약 1년 6개월간 운영해오고 있습니다.

비용 효과적이고 운영이 간편한 엔드포인트 보안솔루션을 고민하고 계실 보안담당자를 위해 제가 직접 엑소스피어를 도입ㆍ운영하면서 느꼈던 장점을 소개합니다.

2. 간편한 도입 및 배포

엔드포인트 보안솔루션을 도입ㆍ변경하는 경우 보안담당자는 다음의 두 가지를 고민하게 됩니다.

(1) 솔루션 구축은 어디에, 어떻게, 누가 하는가

(2) 에이전트 또는 클라이언트 배포를 언제, 어떻게, 누가 하는가

엑소스피어는 SaaS 서비스 특성에 걸맞게 기존 레거시 솔루션에서 수반되는 귀찮고 복잡한 설치 절차가 없습니다. 라이센스를 구매해서 사용 신청만 하면 솔루션 구축 단계는 완료됩니다. → (1) 해결

클라이언트 배포 또한 임직원의 이메일 주소를 관리자 페이지에 등록(수동 또는 LDAP 연동)하고 설치요청 메일발송 버튼만 클릭하면 보안담당자가 처리해야 할 모든 작업은 끝납니다. → (2) 해결

이러한 간편함 덕분에 채 1시간도 걸리지 않고 엑소스피어를 도입 및 배포할 수 있었습니다. 기존 레거시 솔루션 도입(도입 위치 선정, 구성 일자 협의, 구성 사전 준비, 구성)보다 시간을 효과적으로 절약할 수 있다는 강력한 장점이 있습니다.

3. 뛰어난 애플리케이션 제어

엑소스피어 올인원 도입을 결심하게 된 가장 큰 계기는 강력한 애플리케이션 제어 기능 때문이었습니다. MDM 솔루션을 사용해 본 경험이 있는 보안담당자라면 공감하겠지만, 카카오톡과 같은 특정 애플리케이션에 대한 사용제어는 솔루션에서 지원하지만 파일 업로드 차단과 같은 세부적인 통제 기능은 대부분의 솔루션에서 지원하지 않거나 혹은 지원하더라도 기능이 제대로 작동하지 않거나 설정이 매우 복잡합니다.

엑소스피어 올인원은 매우 뛰어난 애플리케이션 제어 기능을 제공하고 있어 카카오톡, 네이트온, 슬랙을 비롯해 다양한 메신저와 클라우드 클라이언트, P2P 등의 파일반출을 차단하는 기능을 제공합니다. 또한 예외 설정을 비롯해 매우 간편하게 정책을 구성할 수 있는 GUI를 제공합니다.

4. 다양한 보안통제 기능

엑소스피어 올인원은 백신, 웹 접속 제어, 매체 제어를 비롯해 총 9가지의 엔드포인트 보안 기능을 제공합니다. 컴플라이언스 준수를 위해서는 최소 2 ~ 3개의 엔드포인트 보안솔루션을 도입해야만 하는데요. 엑소스피어를 도입한다면 여러 개의 솔루션을 도입함으로 인해 발생하는 비용을 절약할 수 있고, 관리해야 하는 솔루션이 늘어남에 따라 함께 증가하는 운영 리소스도 혁신적으로 절약할 수 있습니다.

5. ISMS 인증 대응

보안담당자 입장에서 엑소스피어는 생소한 벤더의 보안솔루션이고 더욱이 SaaS 솔루션이기 때문에 설령 도입한다 해도 컴플라이언스 요건을 준수할 수 없는 것 아닐까 하는 우려가 생길 수 있습니다. 저 또한 마찬가지로 고민이 되었던 부분이기도 하고요.

하지만 ISMS에서 요구하는 모든 엔드포인트 보안통제 정책을 엑소스피어로 설정하고, 모니터링 및 관리할 수 있었고 이를 관리자페이지에서 가시성 있게 확인할 수 있었습니다. 덕분에 작은 문제도 없이 ISMS 최초심사를 마칠 수 있었습니다. 더욱이 SaaS 서비스인 덕분에 on-prem이라면 필요했을 취약점 점검, 패치관리 등의 보안관리가 전혀 필요하지 않아 보안담당자 입장에서 신경 써야 할 요소가 줄어들어 편리했습니다.

6. 마치며

엑소스피어에 대한 칭찬 일색만 늘어놓은 것 같은데요. 물론 단점도 존재합니다. 발생한 로그에 대해 세부적으로 모니터링할 수 있는 기능이 부재한 점과 임직원 개인별로 정책을 설정할 수 없는 부분, 슬랙과 연동할 수 없는 부분 등이 아쉬운 점이지요.

다만 그럼에도 불구하고 엑소스피어는 가격대비 뛰어난 기능을 제공하는 엔드포인트 통합 보안솔루션이라는 생각에는 변함이 없습니다. 엑소스피어의 적극적인 기술지원 능력을 신뢰하기 때문에 아쉬운 지점도 빠른 시일 내로 개선될 것이라고 생각하고 있습니다.

예산의 압박 속에서 어떤 보안솔루션을 도입할지 고민하고 있을 보안담당자에게 이 글이 유용한 참고가 되기를 기대합니다.

24년도 ISMS-P 인증심사원 자격검정 필기시험 합격 후기

MR. ZERO — Sat, 10 Aug 2024 16:30:50 +0900

1. 들어가며

필기시험 합격 결과

바로 어제인 8월 9일에 24년도 ISMS-P 인증심사원 자격검정 필기시험 합격 결과가 발표됐습니다. 응시자격을 갖추자마자 치른 첫 회 시험이었고, 여태 시험 중 난이도가 가장 높았다는 평이 자자해 합격을 기대하지 않았는데 예상밖에 좋은 결과를 받았습니다.

시험을 준비하는 초반에 가장 혼란스러웠던 점은 합격 후기마다 공부 방법이 제각각 달라서 어떤 방식으로 공부를 해야 할지, 학원을 꼭 다녀야만 하는 것인지, 문제집을 반드시 풀어야 되는 것인지 갈피를 잡을 수 없는 것이었습니다.

더욱이 이미 시중에는 수험생을 유혹하는 수십 만 원대의 온/오프라인 강의와 신뢰도를 알 수 없는 유료 이북이 성행하고 있는데요.

이런 상황에서 ISMS-P 자격검정을 공부하시는 분들께 조금이나마 명확한 학습 방향을 제시하고, 불필요한 비용 지출 없이 KISA 공식 문서와 법령만으로 합격할 수 있었던 방법을 공유하기 위해 필기시험 합격 후기를 작성합니다.

2. 자격검정 타임라인

시험을 준비하시는 분들이 학습일정을 효과적으로 계획하실 수 있도록 24년도 필기시험 자격검정 타임라인을 공유합니다.

시험응시 서류 제출 : 4.22.(월) 10시 ~ 4.26.(금) 18시
응시자격 검토 결과 안내 : 5.26.(일)
응시대상자 확정 안내 : 6.7.(금)
수험표 배부 : 7.3.(수)
필기시험 : 7.13.(토) 14:00 ~ 16:00
합격자 발표 : 8.9.(금)

3. 필기시험 준비 방법

ISMS-P 필기시험은 인증기준을 토대로 복합적인 상황을 판단하는 시험인 만큼 인증기준과 법령을 중심으로 학습했습니다. 물론 인증제도에 대한 학습도 함께 진행했고, 추가적으로 가상자산 사업자 인증기준도 살펴봤습니다. 5월 8일부터 준비를 시작했고 67일간 총 103시간을 공부했습니다.

가장 공부 시간을 많이 투자했던 두 가지는 인증기준과 결함사례 암기입니다. 각 인증기준에서 요구하는 내용이 무엇이며 그에 따른 결함사례를 모두 암기하는 것이 시험 합격을 위해 반드시 필요한 과정입니다. 이 과정에서 주의해야 할 것은 단순히 암기를 하는 것이 아니라 인증기준의 본질적인 개념을 이해하는데 중점을 둬야 합니다. 이러한 맥락 없이 단순히 외우는 행위는 도움이 되지 않습니다.

학습 방법을 구체적으로 설명하면 아래의 모든 문서를 각각 7번씩 읽었습니다. 나열한 순서대로 학습했으며 5 회독을 마쳤을 때 결함사례를 암기하고, 다시 2회독(총 7회독)을 마치고 인증기준을 암기했습니다. 그리고 다*원에서 출간된 모의고사 문제집에 수록된 4회 차의 기출문제를 한 번씩 풀이했습니다.

인증제도 안내서
정보보호 및 개인정보보호 관리체계 인증 등에 관한 고시
인증기준 안내서
가상자산 사업자 기준
개인정보 보호법 및 시행령
안전성 확보조치 기준

제가 학습한 방법은 복잡할 것 없이 명쾌하고 간단합니다. KISA에서 제공하는 공식 문서와 관련 법령을 읽고 읽고 또 읽습니다. 그러다 보면 전체적인 맥락이 그려지면서 서로 간의 내용이 연결되고 마침내 자연스럽게 인증기준이 요구하는 본질을 이해하게 됩니다.

상술한 필기시험 준비과정을 한 줄로 정리하면 다음과 같습니다.

문서 5회독 → 결함사례 암기 → 문서 2회독 → 인증기준 암기 → 모의고사 4회차 한 번씩 풀이

다만, 현시점에서 돌이켜 봤을 때 모의고사 풀이는 추천하고 싶지 않습니다. 수록된 문제의 품질이 좋지 않고, 오답인 것을 정답으로 표기하는 등 오히려 혼란만 가중된다고 느꼈습니다. 그나마 문제 유형을 익히는 수준으로는 활용할 수 있기 때문에 서점에서 잠깐 살펴보거나 중고책으로 구입하시는 것을 추천드립니다.(개인적인 의견이며 사람마다 느끼는 유용성은 다를 수 있습니다.)

3.1. 효과적으로 암기하는 방법

학습 도구인 원보카를 활용하면 재밌고 쉽게 암기할 수 있습니다. 제가 암기하기 위해 작성한 단어장을 스프레드시트로 공유합니다.(해당 단어장은 remybaek님이 블로그에 공유해주신 단어장을 기초로 활용)

4. 필기시험 당일

필기시험은 경기고등학교에서 치러졌습니다. 학교 정문과 고사장 거리가 멀어 경기고등학교에서 시험을 치르는 경우 여유 있게 가시는 것을 추천드립니다.

정문으로 들어가면 바로 옆 게시판에서 고사실을 확인할 수 있습니다. 이 날 경기고등학교에는 총 41개의 고사장이 있었고 각 반마다 25명의 수험생이 배치됐습니다. 고사장이 두 곳 더 있는 것으로 알고 있는데 경기고와 같은 규모라면 약 3천 명 정도가 시험에 응시했을 것으로 추정됩니다.

4.1. 필기시험 Tip

2시간 동안 50문제를 풀기에는 시간이 촉박합니다. 지문이 길거나 시간이 많이 소요되는 문제는 과감하게 넘어갑니다. 저는 시간소모가 큰 방화벽/SG 룰 문제는 읽지도 않고 넘어갔습니다.
합격점수 기준은 60점입니다. 즉 최소 30문제만 맞추면 합격이고 20문제까지는 틀려도 되는 것이죠. 시간배분을 하되 확실히 정답을 맞힐 수 있는 문제는 집중합니다.
정답 마킹시간을 아끼기 위해 확실하게 풀이가 끝난 문제는 바로 OMR에 마킹합니다. 저는 이렇게 하지 않아서 마킹에만 10분 가까이 소비했습니다.

5. 시험에 도움된 글

ISMS-P 심사원 필기시험을 준비하면서 온라인에 작성된 모든 합격 후기를 다 읽어본 것 같은데요. 그중에서 가장 도움 됐던 두 개를 공유합니다.

Certified Kubernetes Security Specialist (CKS) 자격증 취득 후기(24.05. 시험)

MR. ZERO — Sat, 18 May 2024 15:18:56 +0900

1. 취득 계기

정보보호 담당자로서 쿠버네티스에 대한 지식을 쌓고 보안을 적용하기 위해 CKS를 취득하게 되었습니다. 또한 CKA, CKAD 취득에 이어서 쿠버네티스 3종을 모두 취득해보자는 목표도 있었구요.

2. 공부 방법

1. 강의

처음에는 Kode Kloud의 CKS 강의를 수강했습니다. 1회차를 다 듣고나서는 개념에 대한 설명이나 실습 측면에서 강의 내용이 부족한 느낌을 많이 받았습니다.
대체재로서 유데미의 CKS 강의를 구매해서 들었는데 굉장히 잘한 선택이었고 해당 강의를 N회차 반복해서 들었습니다.(지금은 전체 강의가 무료로 유튜브에 게시되어 있습니다)

2. 실습

KodeKloud의 모든 실습 문제를 2회씩 풀었고 Lightning Labs와 Mock Exams, Challenges를 각각 10번 넘게 풀었습니다.
유데미 CKS 강사님이 제작하신 killercoda도 굉장히 도움이 많이 되었고 약점이라고 생각하는 분야에 대해 집중적으로 반복해서 풀었습니다.
CKS 시험 등록 후 Linux Foundation에서 제공해주는 killer.sh의 경우 1회차는 제한시간 동안 최대한 풀어보고, 못 푼 문제는 답지를 3번정도 정독 했습니다.
killer.sh 2회차 때도 마찬가지로 제한시간 내에 최대한 풀어보는 연습을 했구요. 다만 2회차에는 모든 문제를 풀고 시간이 남았습니다.

3. 요약

유데미 강의 2회차 수강(모든 실습 문제 풀이) → 강의 내용 블로그 정리 → Lightning Labs, Mock Exams, Challenges, killercoda 각각 10회 이상 풀이 → killer.sh 1회차 풀이 → killer.sh 답지 3회 정독 및 부족한 개념 익숙하게 만들기 → killer.sh 2회차 풀이

3. 팁

killercoda 문제 많이 풀어보기 : 특히 ImagePolicyWebhook은 꼭 완벽하게 숙지하시는 것을 추천드립니다.
이외에 팁은 CKA의 내용과 동일합니다.

4. 시험 후기

보안담당자라서 그런지 개인적인 난이도 체감으로는 CKA / CKAD보다 CKS가 쉬웠습니다.
CKS killer.sh을 처음 풀때도 CKA/CKAD 때는 "너무 어려운데.. 시험에 붙을 수 있을까?"라는 걱정이 앞서 들었다면 이번에는 "뭐지? 이정도면 할만한데?" 라는 생각이 들었습니다.
CKA/CKAD와는 다르게 정답의 토대가 되는 yaml 템플릿을 제공해주는 문제들이 많아서 이것만 잘 활용해도 무난하게 통과할 수 있을 것으로 생각합니다.
모든 CKS 다른 시험후기에서 CKS가 가장 어렵다는 말이 많아서 지레 겁먹고 공부 기간이 길어졌는데요. 시간을 되돌린다면 30% 정도 덜 공부하고 시험 치르고 떨어진 다음에 부족한 부분만 보충해서 재시험을 통해서 합격할 것 같습니다.

Kubernetes 공격 표면 최소화(Reduce Attack Surface)

MR. ZERO — Sat, 16 Mar 2024 23:49:17 +0900

1. 개념

K8s Node와 Host OS의 Security Hardening을 통해 공격 표면을 최소화할 수 있음

Host OS에 대한 Hardening은 CIS Benchmark 또는 주요정보통신 기반시설 취약점 점검 가이드를 참고해 CCE 점검 및 조치

2. 불필요 프로세스 / 서비스 / 패키지 삭제

프로세스 삭제
- netstat -plnt | grep [port_num] 또는 lsof -i :[port_num]
- ls -l /proc/[process_num]/exe
- kill [process_num]
- rm [process_dir]

서비스 삭제
- systemctl list-units -t service --state active | grep -i [svc_name]
- systemctl stop [service]
- systemctl disable [service]

패키지 삭제
- apt list --installed | grep [package]
- apt remove [package]

4. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes Security - Seccomp

MR. ZERO — Sat, 16 Mar 2024 23:06:44 +0900

1. 개념

Seccomp는 secure computing mode 의 줄임말
리눅스 커널의 보안기능 중 하나로 syscall 실행을 허용/거부/로깅 할 수 있음
K8s "전용" 보안 기능은 아니고 ASLR과 같이 리눅스에 구현된 보안 기능임
AppArmor와 비슷한 기능으로 느껴져서 chatGPT한테 차이점을 질의한 결과 아래와 같은 컨셉으로 느껴졌음
- AppArmor : 특정 프로세스의 시스템 리소스 접근에 대한 허용/거부
- Seccomp : 모든 프로세스의 syscall 호출에 대한 허용/거부

2. Seccomp 사용 팁

seccomp 정책
- SCMP_ACT_ALLOW : 허용
- SCMP_ACT_ERRNO : 거부
- SCMP_ACT_LOG : 로깅
seccomp 기본 경로
- /var/lib/kubelet/seccomp
seccomp 적용 여부 확인
- grep -i seccomp /boot/config-$(uname -r)
- mode 0 : disabled
- mode 1 : strict
- mode 2 : filtered

3. Seccomp 적용 방법

seccomp 경로(/var/lib/kubelet/seccomp)에 seccomp 룰 생성(예시)
pod 수준의 securityContext에 seccomp 설정("/var/lib/kubelet/seccomp" 경로를 기본으로 하며 예시의 profiles/audit.json의 의미는 절대 경로로 표현하자면 " /var/lib/kubelet/seccomp/profiles/audit.json" 임)

중요한 점은 securityContext에서 privileged: true로 설정된 경우 seccomp를 적용할 수 없음

4. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes Security - AppArmor

MR. ZERO — Sat, 16 Mar 2024 01:08:22 +0900

1. 개념

컨테이너의 특성상 VM과는 다르게 Host의 커널 영역에 접근 가능
이런 리스크를 낮추기 위해 유저 영역과 커널 영역의 중간에 AppArmor, Seccomp와 같이 Security Layer를 만들어 일종의 방화벽 역할을 하는 장치를 구성할 수 있음(다만 컨테이너 런타임이 AppArmor를 지원해야 사용 가능)

AppArmor는 Profile을 정의를 통해 시스템 콜을 운영자가 원하는대로 허용/거부할 수 있음
Profile에는 3가지의 Modes(제한 수준)을 설정할 수 있음

AppArmor는 모든 노드에 설치되어야 하고 AppArmor의 Profile 또한 모든 노드에서 사용 가능해야 함
AppArmor Profile은 컨테이너 단위로 적용
따라서 디플로이먼트에 AppArmor를 적용하고자 할때 파드 레벨에 적용해야함(spec.template.metadata.annotations)

2. AppArmor 사용 팁

기본 프로파일 경로 : /etc/apparmor.d/
실행 여부 확인 : cat /sys/module/apparmor/parameters/enabled
프로파일 확인 : cat /sys/kernel/security/apparmor/profiles
apparmor 유틸 설치 : apt install apparmor-utils
프로파일 상태 확인 : aa-status
프로파일 생성 : aa-genprof [target_path]
프로파일 적용 : apparmor_parser -q /etc/apparmor.d/[prof_name]
프로파일 해제 : apparmor_parser -R /etc/apparmor.d/[prof_name]

3. AppArmor 적용 방법

Profile 생성 후 pod의 anontations에 Profile을 지정(Profile이 /etc/apparmor.d/ 경로에 있을경우 localhost이고 다른곳에 위치하는 경우는 그에 맞춰 수정)
- container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>

4. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes Audit Logs 설정

MR. ZERO — Fri, 15 Mar 2024 00:21:37 +0900

1. 개념

K8s는 API 요청을 기록하는 Audit Logs가 존재
보안과 운영 측면에서 Audit log를 활용 가능

2. Stage and Level

K8s API 요청에 대한 로깅을 기록할 때 로깅을 위한 stage(리소스 요청 단계)와 level(로깅 수준)이 존재

Stages

RequestReceived : kube-api가 요청을 받은 것
ResponseStarted : kube-api가 응답 헤더만 보내고 바디는 전송하지 않은 것
ResponseComplete : kube-api가 응답 헤더까지 전송한 것
Panic : 패닉 발생한 것

Level

None : 규칙에 부합하는 로그를 남기지 않음
Metadata : 요청에 대한 메타데이터만 로그로 기록
Request : 요청의 메타데이터 + 바디를 기록
RequestResponse : 메타데이터 + 요청/응답 바디를 기록

3. audit 정책 예시

4. Audit log 설정 실습

audit policy 생성

kube-api에서 policy 및 log path 지정(로그 사이즈와 백업 기간도 설정 가능)

볼륨 및 볼륨 마운트 설정

kube-api 재가동까지 대기
- watch crictl ps 로 모니터링
- 이상있을 경우 /var/log/containers/kube-apiserver-controlplane_kube-system_kube-apiserver-* 로그 확인

5. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes 컨테이너 불변성(Immutability of Containers) 개념

MR. ZERO — Thu, 14 Mar 2024 23:36:00 +0900

1. 개념

컨테이너는 생성된 후 life time 동안 변경이 발생해서는 안됨
이를 제어하지 않으면 쉘에 접속해 설정을 변경하는 등 의도치않은 행위가 가능해지기 때문이고, 결론적으로 관리자가 컨테이너의 상태를 파악하지 못할 가능성이 발생
Immutability of Containers의 목적은 궁극적으로 관리자가 모든 컨테이너의 상태를 파악하고 핸들링하기 위함
따라서 컨테이너에 변경이 필요한 경우 반드시 기존의 컨테이너를 삭제하고 새로운 컨테이너를 생성해야 함

2. Immutability 적용 방법

bash / shell 제거
- command 또는 startupProbe 활용

startupProbe:
  exec:
    command:
    - rm
    - /bin/bash

root 파일시스템 read only
- SecurityContexts의 readOnlyRootFilesystem 설정 활용
- init container 활용(임시로 writable하고자 하는 경우)
non root user 실행
- - SecurityContexts의 runAsNonRoot 설정 활용

3. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes Falco 개념 및 설치

MR. ZERO — Thu, 14 Mar 2024 00:38:14 +0900

1. 개념

Falco는 Cloud Native Runtime Security 오픈소스로서 CNCF 재단에 속해있음
리눅스 커널 호출을 트레이싱해 의도하지 않거나 비정상적인 행위를 탐지하고 차단 가능
공식 사이트

2. 설치 방법

curl -s https://falco.org/repo/falcosecurity-packages.asc | apt-key add -
echo "deb https://download.falco.org/packages/deb stable main" | tee -a /etc/apt/sources.list.d/falcosecurity.list
apt-get update -y
apt-get install -y linux-headers-$(uname -r)
apt-get install -y falco=[falco_version]
service falco start

3. 참고 사항

설정 파일 : /etc/falco/falco.yaml
기본 규칙 : falco_rules.yaml
커스텀 규칙 : falco_rules.local.yaml
로그 확인 : cat /var/log/syslog | grep falco 또는 journalctl -fu falco
falco output 필드

4. falco rule custom 실습

1. /etc/falco/falco.yaml 파일에서 토대가 되는 룰 확인 및 복사

2. falco_rules.local.yaml 파일에 붙여넣기 및 output 수정

3. custom 결과 확인

5. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes private docker registry 접근

MR. ZERO — Sat, 9 Mar 2024 00:12:20 +0900

1. 개념

pod 생성 시 이미지를 public docker hub가 아닌 자체적으로 구성한 private docker registry에서 다운받도록 구성 가능
이때 private docker registry 접근 시 로그인 정보는 docker-registry 타입 secret의 imagePullSecrets 인자값으로 전달

2. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes 안전한 Dockerfiles 작성

MR. ZERO — Sat, 9 Mar 2024 00:03:09 +0900

1. 개념

Dockerfile을 작성할 때 RUN, COPY, ADD 명령은 레이어를 추가해 용량을 증가시키므로 최대한 지양하는 것이 좋음
도커 컨테이너의 보안을 위해서 다음의 사항을 유념하면서 Dockerfile을 작성해야 함
- 패키지 버전 명시
- root로 실행 금지
- 파일시스템 read only 설정
- shell 접근 삭제
구체적인 내용은 공식 문서 참고(Overview of best practices for writing Dockerfiles)

2. 실습

Dockerfile BP에 따른 예시

FROM ubuntu:20.04 # 패키지 버전 지정
RUN chmod a-w /etc 
RUN add group -S tmpgroup & adduser -S tmpuser -F appgroup -h /home/tmpuser
RUN rm -rf /bin/* # shell 접근 불가 
COPY --from=0 /app /home/tmpuser # 실행 경로 지정
USER tmpuser # root로 실행 금지
CMD ["/home/tmpuser/app"]

3. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes OPA 개념

MR. ZERO — Fri, 8 Mar 2024 00:30:14 +0900

1. 개념

Admission Control 단계에서 사용하는 정책 강제 도구
오픈소스 정책 적용 엔진으로서 K8s에서만 사용할 수 있는 것은 아님
OPA 정책을 K8s가 해석할 수 있도록 CRDs로 정의(ConstraintTemplate)하고, 실제 정책 실행 대상 및 조건은 Constraint에 정의

2. OPA

정책 예시 - 모든 파드 생성 차단

# ConstraintTemplate
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8salwaysdeny
spec:
  crd:
    spec:
      names:
        kind: K8sAlwaysDeny
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          properties:
            message:
              type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8salwaysdeny

        violation[{"msg": msg}] {
          1 > 0
          msg := input.parameters.message
        }
---
# Constraint
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAlwaysDeny
metadata:
  name: pod-always-deny
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    message: "ACCESS DENIED!"

정책 예시 - default 네임스페이스 사용 차단

# ConstraintTemplate

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequirednamespace
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredNamespace
        listKind: K8sRequiredNamespaceList
        plural: k8srequirednamespace
        singular: k8srequirednamespace
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequirednamespace

        violation[{"msg": msg}] {
          namespace := input.review.object.metadata.namespace 
          namespace == "default"
          msg := "you must provide a namespace other than default"
        }
---
# Constraint

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredNamespace
metadata:
  name: namespace-policy
spec:
  match:
    kinds:
      - apiGroups: ["batch", "extensions", "apps", ""]
        kinds: ["Deployment", "Pod", "CronJob", "Job", "StatefulSet", "DaemonSet", "ConfigMap", "Service"]

3. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes SecurityContext 개념 및 설정2

MR. ZERO — Wed, 6 Mar 2024 00:26:02 +0900

1. 개념

SecurityContext를 통해 Pod 혹은 Container의 보안 설정을 적용할 수 있음
Pod 수준의 통제와 Container 수준의 통제를 별개로 설정 가능하지만, capabilities 설정은 Container 수준에서만 설정 가능
SecurityContext로 설정할 수 있는 옵션은 공식 문서를 참고

2. 주요 옵션

privileged
- host OS의 root와 동일한 권한을 허용
- 기본 설정은 false
allowPrivilegeEscalation
- 부모 프로세스보다 더 많은 권한을 얻도록 허용
- Privileged == true or CAP_SYS_ADMIN 권한을 보유한 경우 항상 true
capabilities
- 컨테이너에 사용 가능 / 불가능한 POSIX capabilities를 지정
readOnlyRootFilesystem
- root 파일 시스템에 read-only 권한 부여
- 기본 설정은 false
runAsGroup
- 특정 그룹으로 컨테이너 실행
runAsNonRoot
- root로 실행 금지
runAsUser
- 특정 유저로 컨테이너 실행

3. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes Container Runtime Sandbox 개념

MR. ZERO — Wed, 6 Mar 2024 00:02:19 +0900

1. 개념

하이퍼바이저를 활용해 가상화를 구현한 VM과 달리 컨테이너는 Host OS를 공유하는 형태이므로 컨테이너의 시스템콜이 Host OS로 요청됨
이러한 escaping을 통제하기 위해 샌드박싱 기법을 활용하게 되는데 seccomp, apparmor를 적용하는 것은 현실적으로 불가능(각 애플리케이션별로 허용 가능한 syscall을 판별하고 허용해줘야 해서)

2. gVisor

이러한 문제의 현실적 대안으로서 gVisor 활용
gVisor는 컨테이너를 위한 애플리케이션 커널 역할을 수행하면서 Application(Container)의 System Call Layer 역할을 수행함으로서 Application과 Host OS의 Kernel을 분리

gVisor는 Sentry와 Gofer로 구성
Sentry
- Application(Container)으로부터의 syscall에 대한 요청/응답을 인터셉트하는 애플리케이션 커널 역할
- User 레이어에 커널의 형태로 구현한 것이므로 Host에 syscall을 요청하지 못함(예를들어 File들을 직접 Open하지 못하고, sandbox를 넘어서는 File System들에 대해 권한이 없음)
Gofer
- Sentry에 권한이 없는 File System 리소스에 접근할 수 있도록 돕는 매개체 역할
gVisor의 단점은 모든 애플리케이션에 대해 동작하는 것이 아니고, 중간에서 일종의 MITM을 하다보니 CPU 사용량이 증가함
gVisor를 적용하려는 경우 사진과 같이 RuntimeClass를 정의 후 yaml에 명시해주면 됨

3. Kata Containers

VM 기술을 일부 차용하는 방식의 컨테이너 샌드박싱 기법

4. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes ETCD 암호화 개념 및 실습

MR. ZERO — Tue, 5 Mar 2024 00:43:22 +0900

1. 개념

Secert 리소스는 이름과 다르게 값을 base64로 인코딩해 저장한다.
따라서 secret 값을 secret, 컨테이너 런타임, etcdctl 등에서 평문으로 확인할 수 있다.
이러한 특성으로 인해 ETCD를 반드시 암호화해야 하고 혹은 Vault와 같은 3rd-Party 오픈소스를 사용해 크레덴셜을 저장해야 한다.
ETCD 암호화에 관한 자세한 방법은 공식 문서에 잘 설명되어 있다.

2. 실습

암호키 생성

head -c 32 /dev/urandom | base64

EncryptionConfiguration 작성

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE 64 ENCODED SECRET>
      - identity: {}

ETCD 암호화 옵션 활성화(kube-apiserver.yaml)

spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --encryption-provider-config=/etc/kubernetes/enc/enc.yaml  # add this line
    volumeMounts:
    ...
    - name: enc                           # add this line
      mountPath: /etc/kubernetes/enc      # add this line
      readOnly: true                      # add this line
    ...
  volumes:
  ...
  - name: enc                             # add this line
    hostPath:                             # add this line
      path: /etc/kubernetes/enc           # add this line
      type: DirectoryOrCreate             # add this line

암호화 확인
- 임의의 secret 생성 후 값을 확인하면 암호화된 것을 확인 가능

ETCD 암호화를 적용하기 이전에 생성된 secret의 경우 값을 확인 가능

기존 시크릿 암호화 적용

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

암호화 적용 후 secret 값(admin)이 암호화됨을 확인

3. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes CertificateSigningRequests 개념 및 실습

MR. ZERO — Fri, 1 Mar 2024 01:14:02 +0900

1. 개념

클러스터의 오브젝트 및 서비스에 접근하기 위해 유저에 대한 인증/인가를 위해 인증서를 사용
인증서를 생성하기 위한 작업의 일환으로 유저의 개인키에 대한 사이닝을 K8s의 CA에 요청할때 CertificateSigningRequests API를 사용
인증서를 사이닝하는 방법에는 매뉴얼힌 방법과 API를 활용하는 방식이 존재
대략적인 프로세스는 다음과 같음

2. 실습(CertificateSigningRequests API 활용)

key 생성

openssl genrsa -out [name].key 2048

CSR 생성(Common Name에 유저 이름 입력)

openssl req -new -key [name].key -out [name].csr

CertificateSigningRequest 생성 및 요청1 - (CSR base64 인코딩)

cat 60099.csr | base64 -w 0

CertificateSigningRequest 생성 및 요청2 - (CSR yaml 파일 작성 및 apply)

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: 60099@internal.users # Common Name에 입력한 유저 이름
spec:
  groups:
  - system:authenticated
  request: LS0tLS1CRUdJTiBD... # base64로 인코딩한 CSR 값
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

CSR 승인

k get csr 
k certificate approve [csr_name]

CSR로부터 CRT 생성

k get csr [csr_name] -o yaml # certificate 부분을 별도 파일에 저장
cat [file] | base64 -d > [name].crt

config 설정 및 사용

k config set-credentials [name] --client-key=[name].key --client-certificate=[name].crt --embed-certs # config에 유저 추가
k config set-context [name] --cluster=[cluster_name] --user=[name] # config에 context 추가
k config use-context [name] # context 변경

3. 실습(CA를 활용해 직접 승인)

CertificateSigningRequests API를 활용하는 방법과 대부분 동일하나 "CSR 생성" 이후부터 "config 설정 및 사용" 이전까지 단계가 생략(쉽게말해 CRT 파일을 수동으로 만드는 부분이 생략됨)
CertificateSigningRequest 생성 및 요청대신 다음과 같이 CA 인증서를 활용해 직접 승인

openssl x509 -req -in [name].csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out [name].crt -days 500

4. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes 서비스어카운트(ServiceAccount) 개념 및 설정2

MR. ZERO — Thu, 29 Feb 2024 23:25:37 +0900

1. 개념

모든 네임스페이스에는 default SA가 존재
파드 생성 시 SA를 지정하지 않은 경우 default SA가 자동으로 설정
custom SA를 생성할 수 있고, custom SA 파드에 지정한 후 컨테이너 내부에서 토큰 값도 확인 가능

2. ServiceAccount 보안

automountServiceAccountToken: false 옵션을 pod 또는 SA에 추가하면 토큰이 자동으로 pod에 마운트되는 것을 방지할 수 있음
default SA의 권한을 제거 또는 최소화하고 이를 사용하는 것이 가장 좋다
SA 사용이 필요한 경우 custom SA를 생성하고 최소권한으로 ClusterRole 또는 Role 할당하여 사용
K8s 1.24 버전부터 SA 생성 후 토큰을 별도로 생성해야 함(이전에는 SA 생성 시 토큰도 자동으로 생성)

3. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes RBAC 개념 및 설정2

MR. ZERO — Thu, 29 Feb 2024 23:12:37 +0900

1. 개념

RBAC을 다양하게 조합해 리소스에 대한 권한 제어 가능
RBAC의 적용 범위는 네임스페이스 단위(role) vs 클러스터 단위(cluster role)로 나뉨

2. Role 조합

role / clusterRole / roleBinding / clusterRoleBinding 조합 가능
- role + roleBinding = 유저 X에게 하나의 NS의 권한을 할당
- clusterRole + clusterRoleBinding = 유저X에게 모든 NS의 권한을 할당
- clusterRole + roleBinding = 유저 X에게 두 개 이상의 NS의 권한을 할당

3. 우선순위

role의 중첩이 발생하는 경우 additive한 RBAC의 특성으로 인해 아래와 같은 상황에서 유저 X는 get, delete 권한을 보유하게 됨

4. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes 취약점 점검 오픈소스

MR. ZERO — Thu, 29 Feb 2024 22:35:17 +0900

1. 소개

K8s 클러스터와 Pod의 이미지에 대한 취약점을 점검하는 다양한 오픈소스가 존재
대표적인 몇 가지를 소개
- kube-bench
- trivy
- kubesec

2. kube-bench

공식 레포
CIS 벤치마크를 기반으로 클러스터의 취약점을 점검

3. trivy

공식 레포
클러스터 및 pod 이미지에 대한 취약점을 점검

4. kubesec

공식 홈페이지
스코어링 기반으로 yaml 내용의 취약점을 점검

5. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes Pod IMDS 접근제어

MR. ZERO — Thu, 29 Feb 2024 00:45:36 +0900

1. 개념

관리형 쿠버네티스의 Node(EC2)에서 IMDS에 접근 가능할 경우 Pod에서도 접근 가능
IMDS에 크레덴셜이 저장되어 있을 가능성이 존재하므로 NetworkPolicies를 활용해 metadata 접근제어 필요

2. NetworkPolicies 설정

(1) 모든 파드의 egress 통신은 허용하되 IMDS 접근은 차단

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pol1
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32

(2) 모든 파드의 IMDS 접근이 차단된 상황에서 특정 파드만 IMDS 접근 허용((1)의 정책이 적용됐다는 가정)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pol2
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: metadata-accessor
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 169.254.169.254/32

(3) 모든 파드가 아니라 특정 파드만 IMDS 접근 차단

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pol3
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: deny
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32

3. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes Ingress TLS 적용

MR. ZERO — Thu, 29 Feb 2024 00:33:35 +0900

1. TLS 인증서 생성

(Ingress는 생성되었다고 가정)

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout cert.key -out cert.crt -subj "/CN=[host_name]/O=[host_name]”

2. TLS Secret 생성

k create secret tls [name] --key cert.key --cert cert.crt

3. Ingress 수정

공식문서를 참고해 spec.tls 추가

4. 접속 테스트

curl -kv https://[host_name]:[node_port]/[path]

5. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes 네트워크 정책(NetworkPolicy) 개념 및 설정2

MR. ZERO — Thu, 29 Feb 2024 00:18:10 +0900

1. 개념

K8s에서 작동하는 방화벽 개념
네임스페이스 단위로 적용
Ingress / Egress 방향에 대해 정책을 설정할 수 있고 label, IP를 기준으로 세부 설정 가능
CNI(Calico, Weave)에 의해 작동하므로 CNI에서 지원하지 않을 경우 NetworkPolicie 사용 불가
동일한 pod에 여러개의 NP를 적용할 수 있고, 이러한 경우 각 NP의 순서는 영향을 미치지 않으며 모든 NP의 총합이 반영

2. 예시

3. 실습1(DNS를 제외한 모든 Egress 트래픽 기본 차단)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-out-default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

podSelector 필드를 지정하지 않을 경우 네임스페이스의 모든 파드에 적용
DNS 서비스만 egress 허용

3. 실습2(모든 Egress 트래픽 기본 허용)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - {}

egress 필드를 지정하지 않는 것이 핵심

4. TIP

파드의 레이블 확인하는 방법
- k get po --show-labels
NetworkPolicy 테스트 도구

5. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

Kubernetes 보안 기초

MR. ZERO — Wed, 28 Feb 2024 00:52:02 +0900

1. 개념

K8s의 보안은 On-prem 보안과는 접근방법이 다르고 Cloud 보안과도 차이가 존재
Cloud Native Security의 기본은 4C
- Cloud
- Cluster
- Container
- Code

2. K8s Attack / Security Surface

공격 표면을 반대로 이야기하면 보안 표면으로 볼 수 있음
K8s에는 3개의 공격 / 보안 표면이 존재
- Host OS Security
- Cluster Security
- Application Security

3. Host OS Security

K8s 클러스터가 구동되는 Host의 운영체제를 의미(EKS라면 Node가 구동되는 EC2의 AMI)
Host OS를 안전하게 관리하는 방법은 일반적인 서버 보안과 동일한 층위로 접근
- CCE 점검
- K8s 노드 서비스만 가동
- 불필요 애플리케이션 삭제
- 주기적 패치 / 업데이트 적용
- 런타임 보안 도구 실행
- 불필요 / 악성프로세스 모니터링 및 삭제
- SSH / IAM 접근제어

4. Cluster Security

K8s 클러스터를 설정하고 운영하는 측면에서 적용할 수 있는 보안(Cluster 자체의 보안)
- K8s 컴포넌트 버전의 주기적 업데이트
- 엄격한 접근제어 및 인증 / 인가
- AdmissionControllers 적용
- NetworkPolicy 적용
- Audit 로그 활성화
- 주기적 Security Benchmark 점검
또한 ETCD에 대한 보안도 필요
- ETCD 암호화(또는 Vault 사용)
- ETCD로의 접근제어
- ETCD로 향하는 트래픽 암호화

5. Application Security

컨테이너에 대한 보안
- 시크릿 / 크레덴셜 관리
- RBAC 적용
- 컨테이너 샌드박싱
- 컨테이너 하드닝(securityContext 등)
- SAST / DAST
- mTLS
- ServiceMeshes

6. 참고

https://www.youtube.com/watch?v=d9xfB5qaOfg&ab_channel=KillerShell

boto3를 활용한 EC2 IMDS v1 취약점 점검 및 조치

MR. ZERO — Mon, 13 Nov 2023 01:00:32 +0900

0. IMDS(Instance Metadata Service)

EC2 인스턴스의 메타데이터에 접근할 수 있는 서비스로 인스턴스 자체 혹은 내부에서 실행되는 애플리케이션과 AWS 또는 모니터링 도구간의 상호작용을 돕는 역할을 합니다.

IMDS를 통해 다음과 같은 정보를 얻을 수 있습니다.

- 인스턴스 메타데이터: 인스턴스 유형, IP 주소, 보안그룹 등
- IAM 역할 및 권한: 인스턴스에 할당된 IAM 역할 및 권한
- 보안 정보: 암호화된 볼륨 사용 여부, 키 페어 사용 여부 등

IMDS v1의 가장 큰 위험은 공격자가 EC2에 할당된 IAM 권한을 취득해 활용할 수 있다는 점입니다. 설령 IAM이 할당되어 있지 않다 하더라도 상술한 것과 같이 상당히 많은 유용한 정보를 획득하여 이를 공격에 활용할 수 있습니다.

1. IMDS 취약점 살펴보기

인스턴스 내부 또는 EKS Pod에서 실행되는 애플리케이션에서 curl을 활용해 IMDS api를 호출할 수 있습니다.

curl http://169.254.169.254/latest/meta-data/

간단한 확인을 위해 인스턴스에서 IMDS를 확인해보면 IAM 권한을 비롯한 다양한 정보를 확인할 수 있습니다.

IMDS를 활용한 공격 시나리오를 잘 설명한 블로그(링크)가 있어 참고하면 좋을 것 같습니다.

2. 취약점 조치 방법

가장 단순한 방법은 IMDS v1을 v2로 변경하는 방법입니다. 그러나 근본적인 위험을 해결하기 위해서는 EC2에 IAM 권한을 최소화하여 할당하거나 IRSA를 적용하는 방법을 고려할 수 있습니다. 또한 IaC를 사용해 인프라를 운영하는 경우 IMDS v2 설정을 강제화하도록 프로세스를 개선해야 합니다.

IMDS v1으로 설정된 인스턴스를 확인해 v2로 변경하는 파이썬 도구를 깃헙(링크)에 올려두었습니다. aws configure 설정 후 다음과 같이 AWS Profile과 리전을 입력하면 자동으로 IMDS v1을 v2로 변경하고 해당 인스턴스 ID를 출력합니다.

python3 check_imds.py --profile [profile_name] --region [region_name]

Certified Kubernetes Application Developer(CKAD) 자격증 취득 후기(23.09. 시험)

MR. ZERO — Sun, 3 Sep 2023 23:34:55 +0900

1. 취득 계기

정보보호 담당자로서 쿠버네티스에 대한 지식을 쌓고 보안을 적용하기 위해 CKAD를 취득하게 되었습니다. 작년에 취득한 CKA에 이어서 쿠버네티스 3종을 모두 취득해보자는 목표도 있었구요.

2. 공부 방법

1. 강의

빛과 소금같은 유데미 강의를 열심히 들었습니다.(링크) 개념과 적절한 실습을 함께 공부할 수 있어서 도움이 많이 됐었고 해당 강의를 3회차 수강하고 블로그에 관련 내용을 정리하는 식으로 복습했습니다.

2. 실습

유데미 강의에서 제공해주는 KodeKloud의 모든 실습 문제를 2회씩 풀었고 Lightning Labs와 Mock Exams, Challenges를 각각 5번 넘게 풀어 봤습니다.
CKAD 시험 등록 후 Linux Foundation에서 제공해주는 killer.sh의 경우 1회차는 제한시간 동안 최대한 풀어보고, 못 푼 문제는 답지를 3번정도 정독 했습니다.
killer.sh 2회차 때도 마찬가지로 제한시간 내에 최대한 풀어보는 연습을 했구요. 다만 2회차에는 모든 문제를 풀고 시간이 남았습니다.

3. 요약

유데미 강의 3회차 수강(모든 실습 문제 풀이) → 강의 내용 블로그 정리 → Lightning Labs, Mock Exams, Challenges 각각 5회 이상 풀이 → killer.sh 1회차 풀이 → killer.sh 답지 3회 정독 및 부족한 개념 익숙하게 만들기 → killer.sh 2회차 풀이

3. 팁

Docker 명령어 익숙해지기 : 기본적인 도커 명령어를 능숙히 다룰 수 있다면 좋습니다. build, run, pull, push 이외에 save 등의 명령어도 시험보기 전에 한번씩 실습해보면 좋습니다.
이외에 팁은 CKA의 내용과 동일합니다.

Keycloak 구축 및 AWS SAML 연동

MR. ZERO — Sun, 18 Jun 2023 01:50:58 +0900

1. Keycloak 개념

Keycloak은 Red Hat에서 개발한 오픈소스 IAM 솔루션입니다. OAuth 2.0 및 OpenID Connect와 같은 표준 프로토콜을 기반으로 사용자 인증ㆍ인가 기능과 SSO를 제공합니다.

기업에서 사용하는 무수히 많은 서비스에 대한 인증을 개별적으로 관리하는 것은 보안담당자 뿐만 아니라 사용자로서도 무척 불편한 부분입니다. 이런 불편함을 극복하고 중앙 집중식의 통합된 사용자 관리 기능을 Keycloak를 통해 달성할 수 있습니다.

Keycloak을 이해하기 위해 필요한 개념은 다음과 같습니다.

Realm
애플리케이션 그룹을 "Realm"으로 정의합니다. 각 Realm은 독립된 사용자 그룹, 클라이언트 애플리케이션, 인증 및 접근 제어 설정을 가집니다.

클라이언트
애플리케이션 또는 서비스를 나타냅니다. 각 클라이언트는 고유한 클라이언트 ID와 시크릿 키를 가지며, 사용자 인증 및 접근 제어를 위해 Keycloak과 통신합니다.

사용자
애플리케이션에 접근하는 개별 계정을 의미합니다. 사용자는 Realm 내에서 관리되며, 그룹화, 역할 할당, 사용자 프로필 관리 등이 가능합니다.

2. Keycloak 구성

2.1. 설치

Keycloak을 구축할 수 있는 방법은 다양합니다. 도커 또는 K8s를 활용할 수 있고 설치형으로 직접 구축할 수 있습니다. 테스트를 위해 간편하게 설치하는 것이 목적이므로 도커를 활용하도록 하겠습니다. 다음 명령어를 통해 컨테이너를 실행합니다.

docker run -p 8080:8080 -e KEYCLOAK_ADMIN=[admin_id] -e KEYCLOAK_ADMIN_PASSWORD=[admin_password] quay.io/keycloak/keycloak:21.1.1 start-dev

2.2. Realm 생성

Keycloak 어드민 페이지(http://localhost:8080/admin)로 접속하여 컨테이너 생성 시 설정한 계정 정보를 입력해 로그인 합니다. 왼쪽 드롭다운 메뉴에서 "Create Realm"을 클릭합니다. Realm 이름을 입력하고 Create를 클릭합니다.

2.3. 유저 생성

생성한 Realm에서 User - Create new user를 클릭합니다. Username을 비롯한 유저 정보를 입력합니다. Required user actions을 지정해 OTP 설정 패스워드 변경 등을 강제할 수 있습니다.

Credentials - Set password를 클릭해 유저의 패스워드를 설정하고 저장합니다. Temporary 옵션을 활성화할 경우 유저가 최초로 로그인했을 때 패스워드 변경을 강제할 수 있습니다.

유저 계정 생성 후 사용자 페이지(http://localhost:8080/realms/[렐름이름]/account)로 접속해 "Sign in"을 클릭하여 정상적으로 로그인되는지 확인합니다.

3. AWS SAML 연동

AWS와 Keycloak간에 SAML을 구성하여 별도의 AWS 어카운트 없이 IAM Role 기반으로 AWS 리소스에 접근할 수 있는 환경을 구성할 수 있습니다.

3.1. AWS IAM Role 생성

Realm settings 메뉴에서 SAML 2.0 Identity Provider Metadata를 다운로드 합니다.

AWS IAM 자격 증명 공급자에서 공급자를 추가합니다. 방금전 다운로드 받은 IdP metadata를 업로드 합니다.

SAML을 통해 AWS 리소스에 허용해주고자 하는 역할을 생성합니다.

3.2. Keycloak clients 생성

AWS의 SAML metada를 다운로드하고 Keycloak clients로 등록합니다.

curl -O https://signin.aws.amazon.com/static/saml-metadata.xml

3.2. Keycloak clients 설정

AWS의 SAML metada를 clients 설정에 추가해야 합니다. 조금전 생성한 clients(urn:amazon:webservices)에서 Home URL과 IDP URL을 설정합니다.

AWS IAM Role과 맵핑할 clients의 Role을 생성합니다.

AWS clients의 scopes에서 role_list를 삭제합니다. 그리고 urn:amazon:webservices-dedicated을 클릭해 Scope 메뉴에서 Full scope allowed 설정을 off 합니다.

Mappers 메뉴로 돌아가 Add mapper를 클릭하고 By configuration을 선택 후 Role list를 추가합니다. 사진과 같이 값을 설정합니다.

Name : Session Role
Role attribute name : https://aws.amazon.com/SAML/Attributes/Role
Friendly Name : Session Role
Single Role Attribute : On

Mappers 메뉴로 돌아가 Add mapper를 클릭하고 By configuration을 선택 후 User Property를 추가합니다. 사진과 같이 값을 설정합니다.

Name : Session Name
Property : username
Friendly Name : Session Name
SAML attribute name : https://aws.amazon.com/SAML/Attributes/RoleSessionName

Mappers 메뉴로 돌아가 Add mapper를 클릭하고 By configuration을 선택 후 Hardcoded attribute를 추가합니다. 사진과 같이 값을 설정합니다.

Name : Session Duration
Friendly Name : Session Duration
SAML attribute name : https://aws.amazon.com/SAML/Attributes/SessionDuration
Attribute value : 43200

Mappers 메뉴로 돌아가 Add mapper를 클릭하고 By configuration을 선택 후 Role Name Mapper를 추가합니다. 사진과 같이 값을 설정합니다.

3.3. Keycloak Group 생성

Group을 만들고 2.3. 유저 생성 단계에서 생성한 유저를 추가합니다.

생성한 Group에 3.2. 단계에서 생성한 Role 맵핑합니다.

4. AWS SAML 접속

4.1. 콘솔 로그인

Clients 메뉴의 Target IDP initiated SSO URL로 접속합니다. 유저 정보를 입력하면 Keycloak 페더레이션 사용자로 로그인되는 것을 확인할 수 있습니다.

4.2. CLI 로그인

saml2aws를 다운로드 합니다.

CURRENT_VERSION=$(curl -Ls https://api.github.com/repos/Versent/saml2aws/releases/latest | grep 'tag_name' | cut -d'v' -f2 | cut -d'"' -f1)
$ wget -c https://github.com/Versent/saml2aws/releases/download/v${CURRENT_VERSION}/saml2aws_${CURRENT_VERSION}_linux_amd64.tar.gz -O - | tar -xzv -C /usr/local/bin
$ chmod u+x /usr/local/bin/saml2aws

saml2aws configure를 설정합니다.

saml2aws login을 합니다.

AWS 리소스에 정상적으로 접근되는지 확인합니다.

5. 참고

C-TAS에서 위협 IP를 자동으로 수집해 슬랙으로 전송하기 - (4) 자동화 스크립트

MR. ZERO — Mon, 24 Apr 2023 00:36:59 +0900

0. 전체 스크립트

앞선 분석과 준비 과정을 통해 코드를 작성할 준비를 모두 마쳤습니다. 전체 코드를 본 다음에 기능별로 설명을 이어나가겠습니다.

import time, os
import pandas as pd
from glob import glob
from datetime import date
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.options import Options
from slack_sdk import WebClient
from slack_sdk.errors import SlackApiError

chrome_options = Options()
chrome_options.add_argument('--headless')
chrome_options.add_argument('--window-size=1920,1080')
driver = webdriver.Chrome(options=chrome_options)
params = {'behavior': 'allow', 'downloadPath':'파일 다운로드 경로'}
driver.execute_cdp_cmd('Page.setDownloadBehavior', params)
driver.get("https://ctas.krcert.or.kr/index")
driver.find_element(By.NAME, 'userId').send_keys('c-tas ID')
driver.find_element(By.NAME, 'userPassword').send_keys('c-tas PW')
driver.find_element(By.CLASS_NAME, 'btn_login').click()

driver.get("https://ctas.krcert.or.kr/threatnew/worker/sharesCombine")
driver.find_element(By.XPATH, "/html/body/div[1]/div/div/div[2]/div[2]/fieldset/div/form/div/select/option[2]").click()
driver.find_element(By.XPATH, "/html/body/div[1]/div/div/div[2]/div[2]/fieldset/div/form/div/button").click()
driver.find_element(By.XPATH, "/html/body/div[1]/div/div/div[2]/div[2]/div[2]/ul/li[1]/span[3]/a[1]").click()
time.sleep(2)
driver.quit()

csv_file = glob('파일 다운로드 경로\\*.csv')
csv_file = str(csv_file).replace("\\", "").replace("파일 다운로드 경로", "").replace("'", "").replace("[", "").replace("]", "")
df = pd.read_csv("파일 다운로드 경로\\"+csv_file)
black_ip_list = str(df['threat_info'].values).replace("[", "").replace("]", "").replace("\n", "").replace("' '", ",").replace("'", "")
os.remove("파일 다운로드 경로\\"+csv_file)
result_list = black_ip_list.split(",")
result_list = [f' - "{ip}' for ip in result_list]
result_list = [ip + '/32"' for ip in result_list]

def send_message(result_list):
    channel_id = "채널ID"
    channel_name = "#채널이름"
    bot_token = "봇 토큰"
    client = WebClient(token=bot_token)
    today = str(date.today()).replace("-", "")
    client.chat_postMessage(channel=channel_name, text=today+" 유해 IP목록(cc.<@유저ID>)")
    response = client.conversations_history(channel=channel_id)  
    latest_timestamp = response["messages"][0]["ts"]
    message = "\n".join(result_list)
    client.chat_postMessage(channel=channel_name, text=message, thread_ts=latest_timestamp)

send_message(result_list)
time.sleep(1)

1. Selenium 설정

chrome_options = Options()
chrome_options.add_argument('--headless')
chrome_options.add_argument('--window-size=1920,1080')
driver = webdriver.Chrome(options=chrome_options)
params = {'behavior': 'allow', 'downloadPath':'파일 다운로드 경로'}
driver.execute_cdp_cmd('Page.setDownloadBehavior', params)

headless 설정과 headless로 작동 시 파일을 다운로드 하기 위한 옵션을 설정합니다.

2. C-TAS 홈페이지 로그인

chrome_options = Options()
chrome_options.add_experimental_option("detach", True)
driver = webdriver.Chrome(options=chrome_options)
driver.get("https://ctas.krcert.or.kr/index")
driver.find_element(By.NAME, 'userId').send_keys('c-tas_ID')
driver.find_element(By.NAME, 'userPassword').send_keys('c-tas_PASS')
driver.find_element(By.CLASS_NAME, 'btn_login').click()

Selenium을 활용해 C-TAS 홈페이지에 접속 후 계정 정보를 입력하고 로그인합니다.

3. 위협IP 정보 파일 다운로드

driver.get("https://ctas.krcert.or.kr/index")
driver.find_element(By.NAME, 'userId').send_keys('c-tas ID')
driver.find_element(By.NAME, 'userPassword').send_keys('c-tas PW')
driver.find_element(By.CLASS_NAME, 'btn_login').click()
driver.get("https://ctas.krcert.or.kr/threatnew/worker/sharesCombine")
driver.find_element(By.XPATH, "/html/body/div[1]/div/div/div[2]/div[2]/fieldset/div/form/div/select/option[2]").click()
driver.find_element(By.XPATH, "/html/body/div[1]/div/div/div[2]/div[2]/fieldset/div/form/div/button").click()
driver.find_element(By.XPATH, "/html/body/div[1]/div/div/div[2]/div[2]/div[2]/ul/li[1]/span[3]/a[1]").click()
time.sleep(2)
driver.quit()

위협IP 정보를 담고있는 CSV 파일을 다운로드하기 위한 XPath 까지 접근하여 파일을 다운로드하고 Selenium을 종료합니다. 파일이 다운로드되는 도중 Selenium이 닫히는 것을 방지하기 위해 sleep을 설정했습니다.

4. 위협IP 추출 및 형식 다듬기

csv_file = glob('파일 다운로드 경로\\*.csv')
csv_file = str(csv_file).replace("\\", "").replace("파일 다운로드 경로", "").replace("'", "").replace("[", "").replace("]", "")
df = pd.read_csv("파일 다운로드 경로\\"+csv_file)
black_ip_list = str(df['threat_info'].values).replace("[", "").replace("]", "").replace("\n", "").replace("' '", ",").replace("'", "")
os.remove("파일 다운로드 경로\\"+csv_file)
result_list = black_ip_list.split(",")
result_list = [f' - "{ip}' for ip in result_list]
result_list = [ip + '/32"' for ip in result_list]

다운로드 한 CSV 파일의 파일명을 추출하고 → CSV 파일 중 위협IP가 기록된 특정 컬럼의 모든 내용을 파싱한 후 → CSV 파일을 삭제하고 → 위협IP의 포맷을 원하는 형태로 수정하는 부분입니다.

5. 슬랙 메세지 전송

def send_message(result_list):
    channel_id = "채널ID"
    channel_name = "#채널이름"
    bot_token = "봇 토큰"
    client = WebClient(token=bot_token)
    today = str(date.today()).replace("-", "")
    client.chat_postMessage(channel=channel_name, text=today+" 유해 IP목록(cc.<@유저ID>)")
    response = client.conversations_history(channel=channel_id)  
    latest_timestamp = response["messages"][0]["ts"]
    message = "\n".join(result_list)
    client.chat_postMessage(channel=channel_name, text=message, thread_ts=latest_timestamp)

send_message(result_list)
time.sleep(1)

특정 채널에 "유해 IP 목록"이라는 메세지를 발송하고 해당 메세지의 댓글에 위협IP를 기록하는 부분입니다. IP의 수가 많을 경우 채널의 가독성을 저해할 우려가 있어 댓글에 기록하였습니다. 또한 메세지가 누락되지 않도록 관련 엔지니어를 호출합니다. 아래와 같이 예쁘게 내용을 확인할 수 있습니다.

C-TAS에서 위협 IP를 자동으로 수집해 슬랙으로 전송하기 - (3) 크롤링 분석

MR. ZERO — Sat, 22 Apr 2023 02:13:49 +0900

0. 크롤링을 위한 사이트 분석

Selenium을 사용하기 위한 작업과 Slack bot 설정을 모두 마쳤으니 이제는 크롤링을 할 대상을 파악할 단계입니다. IP정보를 크롤링 해올 C-TAS 홈페이지는 로그인이 필요하기 때문에 먼저 로그인 페이지에 대한 분석을 먼저 시작합니다. 개발자 도구에서 확인해보니 "idPWWrap"이라는 div에서 userId와 userPassword에 각각 아이디와 패스워드를 입력받고 있습니다.

request 요청에서도 주의깊게 살펴볼 부분은 없어보이기 때문에 간단한 파이썬 코드를 작성해 로그인 테스트를 해봅니다.

1. 로그인 테스트

다음과 같은 파이썬 코드를 실행하면 안타깝게도 유효하지 않은 접근으로 차단이 되는 것을 확인할 수 있습니다.

import requests
from fake_useragent import UserAgent

url = "https://ctas.krcert.or.kr/index"

login_info = {
    "userId": "",
    "userPassword": ""
}

headers = { 
    'User-agent': UserAgent().chrome,
    'Referer' : 'https://ctas.krcert.or.kr/index',
}

with requests.session() as s:
    res = s.post(url, login_info, headers=headers)      
    print(res.content.decode('UTF-8'))

크롤링을 방지하기 위한 조치가 적용되어 있거나 제가 놓친 부분 때문에 정상적으로 로그인이 되지 않는 것으로 생각됩니다. 빠르게 도구를 만들기 위해 추가적인 분석보다는 Selenium을 활용해 문제를 우회하는 방법을 선택했습니다.

2. Selenium 활용

다음과 같이 파이썬 코드를 작성하면 간편하게 로그인이 성공하는 것을 확인할 수 있습니다.

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.options import Options

chrome_options = Options()
chrome_options.add_experimental_option("detach", True)
driver = webdriver.Chrome(options=chrome_options)

driver.get("https://ctas.krcert.or.kr/index")
driver.find_element(By.NAME, 'userId').send_keys('c-tas_ID')
driver.find_element(By.NAME, 'userPassword').send_keys('c-tas_PASS')
driver.find_element(By.CLASS_NAME, 'btn_login').click()

3. 위협IP 파일 다운로드 분석

CSV 파일을 다운로드하는 request 헤더 값에서 규칙성을 발견할 수 있습니다. date 필드의 값만 수정하면 수고스럽게 xpath를 일일히 찾아서 파싱하지 않아도 될 것이라는 강력한 확신이 드는데요.

해당 URL 그리고 date 값을 변조한 URL을 웹브라우저에서 직접 호출하니 CSV 파일이 정상적으로 다운로드됨을 확인했습니다. 일종의 URL 변조 취약점을 활용한 것인데요. 이렇게 수집한 정보를 기반으로 본격적인 파이썬 스크립트 작성을 시작할 수 있습니다.

C-TAS에서 위협 IP를 자동으로 수집해 슬랙으로 전송하기 - (2) Slack bot 생성 및 권한 부여

MR. ZERO — Fri, 21 Apr 2023 01:24:18 +0900

0. Slack Bot

slack-sdk를 활용해 위협 IP를 슬랙 메세지로 발송하기 위해서는 파이썬의 요청을 수행하기 위한 전용 bot이 필요합니다. 이를 위해 Slack API 홈페이지에서 bot을 생성하고 적절한 권한을 부여해야 합니다.

1. Slack Bot 생성

Slack API 홈페이지에서 "Create an app"을 클릭하고, 곧바로 뜨는 팝업창에서 "From scratch"를 클릭합니다.

뒤이어 나오는 화면에서 bot의 이름과 bot을 사용할 슬랙 워크스페이스를 지정하고 "Create App"을 클릭합니다. 참고로 bot의 이름은 언제든 수정할 수 있습니다. 이후 "Bots"을 클릭합니다.

2. Bot 권한 부여

bot 생성 후 "OAuth & Permissions" 메뉴의 "Scopes"에서 bot이 워크스페이스에서 활동할 수 있도록 필요한 권한을 부여합니다. 해야 합니다. "Add an OAuth Scope" 버튼을 클릭해 아래 사진과 동일한 권한을 모두 부여합니다.

3. Bot Token 확인

권한 부여 후 스크롤을 위로 올려 "OAuth Tokens for Your Workspace"에서 "Install App to Workspace"를 클릭합니다. 워크스페이스에 bot이 설치되면 xoxb로 시작하는 bot 토큰 값을 확인할 수 있습니다. 해당 토큰은 유·노출되지 않도록 주의합니다.

4. 슬랙 채널에 Bot 초대

bot을 사용하고자 하는 채널로 이동한 후 "@bot 이름"을 작성해서 엔터를 치면 bot이 채널에 초대됩니다.

5. slack_sdk 파이썬 라이브러리 설치

마지막으로 cmd 또는 powershell에서 pip를 통해 파이썬에서 사용할 slack-sdk 라이브러리를 설치합니다.

pip install slack_sdk

C-TAS에서 위협 IP를 자동으로 수집해 슬랙으로 전송하기 - (1) Selenium 설치

MR. ZERO — Fri, 21 Apr 2023 00:43:42 +0900

0. Selenium

Selenium은 파싱 또는 크롤링을 막기 위한 수단이 적용된 사이트에서 간단하게 스크래핑 할 수 있도록 도와주는 도구 입니다. 사용자가 정의한 행위를 WebDriver API를 사용자 대신 수행하는 일종의 웹 브라우저라고 이해하면 좋을 것 같습니다.

1. Chrome 브라우저 버전 확인

Selenium이 사용 할 브라우저의 드라이버를 다운받아야 하는데요. 이를 위해 현재 내 PC에 설치된 Chrome의 버전을 확인하고 이에 맞는 드라이버를 설치해야 합니다.

이를 위해 Chrome을 실행한 후 오른쪽 상단 점 3개 → 도움말 → Chrome 정보에서 아래와 같은 형식의 빌드 버전을 확인합니다.

111.0.*
112.0.*
113.0.*

2. Chrome 드라이버 다운로드

해당 버전에 맞는 Chrome 드라이버를 다운로드 한 후에 실행할 파이썬 스크립트와 같은 경로에 저장합니다. Selenium과 드라이버의 정상 동작을 확인하기 위해 아래와 같은 예시 코드를 실행하여 작동 여부를 테스트 합니다.

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.options import Options

chrome_options = Options()
chrome_options.add_experimental_option("detach", True)
driver = webdriver.Chrome(options=chrome_options)
driver.get("https://mr-zero.tistory.com/")

3. Selenium 파이썬 라이브러리 설치

마지막으로 cmd 또는 powershell에서 pip를 통해 파이썬에서 사용할 Selenium 라이브러리를 설치합니다.

pip install selenium

C-TAS에서 위협 IP를 자동으로 수집해 슬랙으로 전송하기 - (0) 계기

MR. ZERO — Fri, 21 Apr 2023 00:16:50 +0900

0. 예산도 없고 귀찮지만 일은 해야지

최근에 비정상적인 서비스 접근 요청을 어떻게 처리하고 예방할지에 대한 논의를 하게 되었습니다. 전문업체를 통해 관제 서비스를 받거나 고가의 TI를 구독하면 좋겠지만 비용 측면을 고려했을 때 여러모로 효율적인 선택은 아니라는 생각이 들었습니다.

아무튼 공격으로 의심되는 IP를 비롯해 잠재적인 위협 리스크를 어떻게 사전에 감소시킬지에 대한 고민이 시작됐는데요. 이때 고민스러웠던 지점이 "위협 IP를 어디서 수집하고" "차단을 적용할 DevOps팀에 어떻게 공유할지"였습니다. KISA에서 운영하는 위협정보공유 서비스인 C-TAS를 알고 있었기에 첫 번째 고민은 바로 해결했지만, 두 번째가 여전히 고민이었습니다.

자칫하면 매일 아침 C-TAS에 접속해서 위협 IP가 기록된 엑셀을 다운로드하여 IP만 복사해서 슬랙 채널에 메시지를 작성하고 동료 엔지니어를 태그하는 행위를 해야 했기에 "일단 자동화를 하자" 라는 생각이 들었습니다.

1. 자동화를 향해

귀찮은 작업을 자동화 시켜 여유로운 아침 시간을 확보하고자 파이썬의 힘을 빌리게 되었습니다. 이어질 네 편의 글은 스크립트를 작성하기 위해 시행착오를 겪었던 과정을 정리한 내용을 설명하고, 마지막으로 스크립트에 대한 로직을 설명하고 있습니다.

2. Next step

아직까지는 매일 아침마다 cmd를 열고 스크립트를 실행하는 반쪽짜리 자동화 도구에 머물러 있는데요. 이를 개선하고 사람이 필요 없는 완전 자동화로 나아가기 위해 스크립트를 수정 + 개선하기 위해 고민하고 있습니다.

~~특히 스크립트를 인스턴스에 올려서 cron으로 실행시키고 싶지만 selenium으로 CSV 파일을 파싱하고 있어서 어떻게 하면 가능할지 생각 중이고,~~

→ Selenium headless 옵션을 활용해 개선 완료

위협 IP 목록을 DevOps 엔지니어에게 전달하는 것이 아닌 설정에 직접 추가하고 PR까지 하는 프로세스가 될 수 있도록 고민하고 있습니다.

23.9.15. 시행 개인정보 보호법 개정 검토

MR. ZERO — Wed, 22 Mar 2023 00:47:20 +0900

0. 들어가며

21년 1월에 입법예고 되었던 개인정보 보호법(이하 "개보법") 전면 개정안이 올해 3.7.에 국무회의에서 의결되어 3.14.에 공포되었습니다. 입법예고부터 의결까지 2년 여가 걸린 개정안은 오는 9.15.부터 본격적인 시행을 앞두고 있습니다.

정보보호 담당자로서 실무적으로 어떤 변경사항이 있는지 짚어보기 위해 관련 내용을 확인해 보았습니다.

1. 개정안 요약

[표_개인정보 보호법 개정 주요내용 요약(출처: 개인정보보호위원회)]

전면 개정이라는 표현에서 보듯이 많은 부분이 바뀌었는데요. 개정법 전문은 국가법령정보센터에서 확인할 수 있습니다.

개인적으로 개정법 중 실무자 입장에서 주목할 부분은 다음 5가지라고 생각이 됩니다.

개인정보 전송요구권 신설
온·오프라인 규제 일원화
개인정보 처리방침 평가제 도입
국외이전 요건 다양화 및 중지명령권 신설
과징금·벌칙 규정 정비

2. 주목할 부분

2.1. 개인정보 전송요구권 신설(제35조의2)

제35조의2(개인정보의 전송 요구) 

① 정보주체는 개인정보 처리 능력 등을 고려하여 대통령령으로 정하는 기준에 해당하는 개인정보처리자에 대하여 다음 각 호의 요건을 모두 충족하는 개인정보를 자신에게로 전송할 것을 요구할 수 있다.
	1. 정보주체가 전송을 요구하는 개인정보가 정보주체 본인에 관한 개인정보로서 다음 각 목의 어느 하나에 해당하는 정보일 것
		가. 제15조제1항제1호, 제23조제1항제1호 또는 제24조제1항제1호에 따른 동의를 받아 처리되는 개인정보
		나. 제15조제1항제4호에 따라 체결한 계약을 이행하거나 계약을 체결하는 과정에서 정보주체의 요청에 따른 조치를 이행하기 위하여 처리되는 개인정보
		다. 제15조제1항제2호ㆍ제3호, 제23조제1항제2호 또는 제24조제1항제2호에 따라 처리되는 개인정보 중 정보주체의 이익이나 공익적 목적을 위하여 관계 중앙행정기관의 장의 요청에 따라 보호위원회가 심의ㆍ의결하여 전송 요구의 대상으로 지정한 개인정보
	2. 전송을 요구하는 개인정보가 개인정보처리자가 수집한 개인정보를 기초로 분석ㆍ가공하여 별도로 생성한 정보가 아닐 것
	3. 전송을 요구하는 개인정보가 컴퓨터 등 정보처리장치로 처리되는 개인정보일 것

② 정보주체는 매출액, 개인정보의 보유 규모, 개인정보 처리 능력, 산업별 특성 등을 고려하여 대통령령으로 정하는 기준에 해당하는 개인정보처리자에 대하여 제1항에 따른 전송 요구 대상인 개인정보를 기술적으로 허용되는 합리적인 범위에서 다음 각 호의 자에게 전송할 것을 요구할 수 있다.
	1. 제35조의3제1항에 따른 개인정보관리 전문기관
	2. 제29조에 따른 안전조치의무를 이행하고 대통령령으로 정하는 시설 및 기술 기준을 충족하는 자

③ 개인정보처리자는 제1항 및 제2항에 따른 전송 요구를 받은 경우에는 시간, 비용, 기술적으로 허용되는 합리적인 범위에서 해당 정보를 컴퓨터 등 정보처리장치로 처리 가능한 형태로 전송하여야 한다.

④ 제1항 및 제2항에 따른 전송 요구를 받은 개인정보처리자는 다음 각 호의 어느 하나에 해당하는 법률의 관련 규정에도 불구하고 정보주체에 관한 개인정보를 전송하여야 한다.
	1. 「국세기본법」 제81조의13
	2. 「지방세기본법」 제86조
	3. 그 밖에 제1호 및 제2호와 유사한 규정으로서 대통령령으로 정하는 법률의 규정

⑤ 정보주체는 제1항 및 제2항에 따른 전송 요구를 철회할 수 있다.

⑥ 개인정보처리자는 정보주체의 본인 여부가 확인되지 아니하는 경우 등 대통령령으로 정하는 경우에는 제1항 및 제2항에 따른 전송 요구를 거절하거나 전송을 중단할 수 있다.

⑦ 정보주체는 제1항 및 제2항에 따른 전송 요구로 인하여 타인의 권리나 정당한 이익을 침해하여서는 아니 된다.

⑧ 제1항부터 제7항까지에서 규정한 사항 외에 전송 요구의 대상이 되는 정보의 범위, 전송 요구의 방법, 전송의 기한 및 방법, 전송 요구 철회의 방법, 전송 요구의 거절 및 전송 중단의 방법 등 필요한 사항은 대통령령으로 정한다.

개정법에 따라 정보주체는 개인정보처리자에게 자신 또는 제3자에게 자신의 개인정보를 전송하도록 요구할 수 있습니다. 이때 정보주체가 전송을 요구할 수 있는 정보는 본인에 관한 개인정보로 한정되며, 개인정보처리자가 분석ㆍ가공하여 별도로 생성한 정보 또는 정보처리장치로 처리되지 않는 정보에 대해서는 전송을 요구할 수 없습니다.

개인정보 전송 대상으로 지정된 제3자에 대한 구체적인 내용은 시행령이 발표되어야 알 수 있겠지만, 추측하기로 KISA나 금융보안원이 개인정보관리 전문기관이 될 가능성이 클 것으로 생각됩니다.

개인정보 전송 요구를 받은 개인정보처리자는 정보주체의 본인 여부를 우선적으로 확인하고, 정당한 요구인 경우에는 시간, 비용, 기술적으로 허용되는 합리적인 범위내에서 정보를 전송할 의무가 있습니다. 따라서, 정보보호 담당자는 개인정보 전송 요구에 따른 ① 내부 절차와 정책 ② 개인정보관리 전문기관과의 마이데이터 계약 또는 표준 API 방식 구현 ③ 마이데이터 전송을 위한 시스템/백엔드 단의 검토 등을 수행해야 할 것으로 예상됩니다.

무엇보다 가장 중요한 부분은 다른 조문과 달리 시행일이 지정되지 않았다는 점인데요. 구체적인 시행령과 전문기관 지정 현황, 데이터 전송 규격 등 부수적인 내용이 정리되어야 시행일이 지정될 것으로 생각합니다.

2.2. 온·오프라인 규제 일원화(제6장 삭제)

제39조의3 개인정보의 수집ㆍ이용 동의 등에 대한 특례
제39조의4 개인정보 유출등의 통지ㆍ신고에 대한 특례
제39조의5 개인정보의 보호조치에 대한 특례
제39조의6 개인정보의 파기에 대한 특례
제39조의7 이용자의 권리 등에 대한 특례
제39조의8 개인정보 이용내역의 통지
제39조의9 손해배상의 보장
제39조의10 노출된 개인정보의 삭제ㆍ차단
제39조의11 국내대리인의 지정
제39조의12 국외 이전 개인정보의 보호
제39조의13 상호주의
제39조의14 방송사업자등에 대한 특례
제39조의15 과징금의 부과 등에 대한 특례

개인정보 파기, 이용내역 통지 등 온라인 사업자(정보통신서비스 제공자)의 규제를 별도로 정의한 제6장의 내용이 전부 삭제되었습니다.

그간 하나의 법 안에서 온·오프라인 사업자를 별도로 규정함에 따라 혼란이 야기되어 왔기에 바람직한 방향이라고 생각되는데요.

다만, 정보보호 담당자 입장에서는 챙겨야 할 부분이 있습니다.

제39조의8 → 제20조의2로 개정됨에 따라 개인정보 이용ㆍ제공 내역 또는 이용ㆍ제공 내역을 확인할 수 있는 정보시스템에 접속하는 방법을 정보주체에게 통지하여야 합니다. 해당 조문은 마이데이터 도입에 따른 사항이라고 추측됩니다.
제39조의6이 삭제됨에 따라 1년 또는 지정한 기간동안 서비스에 접속하지 않은 이용자의 개인정보를 삭제 또는 별도 보관 의무가 없어졌습니다.

2.3. 개인정보 처리방침 평가제 도입(제30조의2)

제30조의2(개인정보 처리방침의 평가 및 개선권고) 

① 보호위원회는 개인정보 처리방침에 관하여 다음 각 호의 사항을 평가하고, 평가 결과 개선이 필요하다고 인정하는 경우에는 개인정보처리자에게 제61조제2항에 따라 개선을 권고할 수 있다.
	1. 이 법에 따라 개인정보 처리방침에 포함하여야 할 사항을 적정하게 정하고 있는지 여부
	2. 개인정보 처리방침을 알기 쉽게 작성하였는지 여부
	3. 개인정보 처리방침을 정보주체가 쉽게 확인할 수 있는 방법으로 공개하고 있는지 여부

② 개인정보 처리방침의 평가 대상, 기준 및 절차 등에 필요한 사항은 대통령령으로 정한다.

개인정보 처리방침의 내용과 구성, 공개 방법의 적정성을 평가하고 개선을 권고할 수 있도록 개정되었습니다. 기존에도 KISA 또는 방통위가 처리방침에 대한 개선을 요청하고 있었으나, 이에 대한 법적 근거를 마련하기 위한 조치라고 생각됩니다.

개인정보 처리자는 개선 권고를 받은 경우, 권고임에도 불구하고 제61조제2항에 따라 개선의 이행을 성실하게 노력하여야 합니다.

평가 대상 등의 세부적인 사항은 시행령으로 정하고 있으나, 정보통신서비스 제공자의 경우 대부분 평가 대상에 포함될 것으로 생각됩니다. 따라서, 담당자는 개인정보 처리방침 작성지침 등을 참고해 적정성을 사전에 점검하여 개선 권고를 예방하는 것이 바람직할 것으로 생각됩니다.

2.4. 국외이전 요건 다양화 및 중지명령권 신설(제28조의8, 제28조의9)

제28조의8(개인정보의 국외 이전) 

① 개인정보처리자는 개인정보를 국외로 제공(조회되는 경우를 포함한다)ㆍ처리위탁ㆍ보관(이하 이 절에서 “이전”이라 한다)하여서는 아니 된다. 다만, 다음 각 호의 어느 하나에 해당하는 경우에는 개인정보를 국외로 이전할 수 있다.
	1. 정보주체로부터 국외 이전에 관한 별도의 동의를 받은 경우
	2. 법률, 대한민국을 당사자로 하는 조약 또는 그 밖의 국제협정에 개인정보의 국외 이전에 관한 특별한 규정이 있는 경우
	3. 정보주체와의 계약의 체결 및 이행을 위하여 개인정보의 처리위탁ㆍ보관이 필요한 경우로서 다음 각 목의 어느 하나에 해당하는 경우
		가. 제2항 각 호의 사항을 제30조에 따른 개인정보 처리방침에 공개한 경우
		나. 전자우편 등 대통령령으로 정하는 방법에 따라 제2항 각 호의 사항을 정보주체에게 알린 경우
	4. 개인정보를 이전받는 자가 제32조의2에 따른 개인정보 보호 인증 등 보호위원회가 정하여 고시하는 인증을 받은 경우로서 다음 각 목의 조치를 모두 한 경우
		가. 개인정보 보호에 필요한 안전조치 및 정보주체 권리보장에 필요한 조치
		나. 인증받은 사항을 개인정보가 이전되는 국가에서 이행하기 위하여 필요한 조치
	5. 개인정보가 이전되는 국가 또는 국제기구의 개인정보 보호체계, 정보주체 권리보장 범위, 피해구제 절차 등이 이 법에 따른 개인정보 보호 수준과 실질적으로 동등한 수준을 갖추었다고 보호위원회가 인정하는 경우

② 개인정보처리자는 제1항제1호에 따른 동의를 받을 때에는 미리 다음 각 호의 사항을 정보주체에게 알려야 한다.
	1. 이전되는 개인정보 항목
	2. 개인정보가 이전되는 국가, 시기 및 방법
	3. 개인정보를 이전받는 자의 성명(법인인 경우에는 그 명칭과 연락처를 말한다)
	4. 개인정보를 이전받는 자의 개인정보 이용목적 및 보유ㆍ이용 기간
	5. 개인정보의 이전을 거부하는 방법, 절차 및 거부의 효과

③ 개인정보처리자는 제2항 각 호의 어느 하나에 해당하는 사항을 변경하는 경우에는 정보주체에게 알리고 동의를 받아야 한다.

④ 개인정보처리자는 제1항 각 호 외의 부분 단서에 따라 개인정보를 국외로 이전하는 경우 국외 이전과 관련한 이 법의 다른 규정, 제17조부터 제19조까지의 규정 및 제5장의 규정을 준수하여야 하고, 대통령령으로 정하는 보호조치를 하여야 한다.

⑤ 개인정보처리자는 이 법을 위반하는 사항을 내용으로 하는 개인정보의 국외 이전에 관한 계약을 체결하여서는 아니 된다.

⑥ 제1항부터 제5항까지에서 규정한 사항 외에 개인정보 국외 이전의 기준 및 절차 등에 필요한 사항은 대통령령으로 정한다.

제28조의9(개인정보의 국외 이전 중지 명령) 

① 보호위원회는 개인정보의 국외 이전이 계속되고 있거나 추가적인 국외 이전이 예상되는 경우로서 다음 각 호의 어느 하나에 해당하는 경우에는 개인정보처리자에게 개인정보의 국외 이전을 중지할 것을 명할 수 있다.
	1. 제28조의8제1항, 제4항 또는 제5항을 위반한 경우
	2. 개인정보를 이전받는 자나 개인정보가 이전되는 국가 또는 국제기구가 이 법에 따른 개인정보 보호 수준에 비하여 개인정보를 적정하게 보호하지 아니하여 정보주체에게 피해가 발생하거나 발생할 우려가 현저한 경우

② 개인정보처리자는 제1항에 따른 국외 이전 중지 명령을 받은 경우에는 명령을 받은 날부터 7일 이내에 보호위원회에 이의를 제기할 수 있다.

③ 제1항에 따른 개인정보 국외 이전 중지 명령의 기준, 제2항에 따른 불복 절차 등에 필요한 사항은 대통령령으로 정한다.

온·오프라인 규제 일원화에 따라 제6장이 삭제되며 기존에 국외 이전을 규제하던 제39조의12를 대신하여 제28조의8, 제28조의9가 신설되었습니다.

기존에는 CSP나 CRM 등의 서비스를 이용하기 위해 개인정보를 국외로 이전하려는 경우 개인정보 처리방침에 이전 항목, 이전받는 자 등 관련 내용을 명시하였어야 했는데요. 개정법에서는 국외 이전을 가능케 하는 방법이 몇가지 추가되었습니다.

언뜻보면 개인정보를 제공받는 국외의 대상이 ISMS-P 인증을 취득하거나 GDPR을 준수할 경우, 현행과 동일하게 개인정보 처리방침에 관련 내용을 안내하면 국외 이전이 가능하기 때문에 실무적으로 편해진 것으로 생각될 수 있습니다.

다만, 23년 3월 현재 AWS, GCP, Azure 등 CSP를 비롯해 대부분의 해외 사업자가 ISMS 인증만 취득한 상황이기 때문에 상황에 따라서는 이용자로부터 국외이전에 따른 별도의 동의를 받아야 할 것으로 보입니다. 또한 세부적인 내용은 시행령으로 규정하고 있어 지속적으로 주시할 필요가 있습니다.

2.5. 과징금·벌칙 규정 정비(제64조의2)

제64조의2(과징금의 부과) 

① 보호위원회는 다음 각 호의 어느 하나에 해당하는 경우에는 해당 개인정보처리자에게 전체 매출액의 100분의 3을 초과하지 아니하는 범위에서 과징금을 부과할 수 있다. 다만, 매출액이 없거나 매출액의 산정이 곤란한 경우로서 대통령령으로 정하는 경우에는 20억원을 초과하지 아니하는 범위에서 과징금을 부과할 수 있다.

~ 생략 ~

현행법에서 과징금의 상한을 ‘위반행위와 관련한 매출액의 100분의 3’으로 규정하고 있으나 개정법에서는 ‘전체 매출액(전체 매출액에서 위반행위와 관련이 없는 매출액을 제외한 매출액)의 100분의 3'으로 상향하였습니다. 또한 과징금 부과 대상도 전보다 확대되었는데요.

실무자 입장에서는 반갑기도 하고 섬칫하기도 한 양가적인 감정이 들게하는 개정 항목인것 같습니다. 개인정보 교육이나 협업 과정에서 유용하게 활용될 수 있을 것 같다는 생각도 듭니다.

3. 참고

1. 개인정보 보호법 일부개정법률(안) 입법예고 - 법제처

2. 개인정보 보호법 전면 개정 - 법률신문

3. 개인정보 보호법 전면개정, 데이터 신경제 시대 열린다 - 개인정보보호위원회

4. 개인정보 보호법 전면개정: 주요 내용 살펴보기 - 법무법인 율촌

5. 「개인정보보호법」제2차전면개정안국회통과(1) - 법무법인 광장

Windows10 WSL2 환경에 minikube 구축하기

MR. ZERO — Thu, 16 Mar 2023 23:43:51 +0900

0. minikube란?

Minikube는 개발자가 로컬 머신에 Kubernetes 클러스터를 설정할 수 있는 오픈 소스 도구로서, 손쉽게 K8s를 구축할 수 있도록 지원하는 플랫폼입니다.

Minikube를 사용하면 개발자가 본격적인 프로덕션 환경을 설정할 필요 없이 로컬에서 Kubernetes를 구축 및 운영할 수 있어서 테스트 및 스터디에 적합합니다.

또한 클라우드 또는 매니지드 환경에 구축할 필요 없이 로컬에 구성이 가능하므로 비용적인 부담이 발생하지 않습니다.

Minikube 유사한 도구로는 K3s, K6s 등이 존재합니다.

1. WSL2 설치

1. 설치를 진행하기에 앞서 해당 글을 참고하여 WSL2 환경을 구성합니다.

2. 도커 설치

1. 공식 홈페이지를 통해 도커 데스크탑을 설치합니다.

2. 설치 과정 중 "Use WSL2 instead of Hyper-V"를 반드시 체크하고 진행합니다.

3. 설치가 완료되면 자동으로 PC가 재부팅되고 이후에 Docker Desktop을 실행합니다.

4. WSL에 접속해 "docker" 명령어 입력 후 정상적으로 작동하는지 확인합니다.

3. minikube 설치 및 실행

1. 공식 홈페이지를 통해 WSL에 minikube를 설치합니다.

2. WSL에 접속 후 아래 명령어를 입력합니다.

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

sudo install minikube-linux-amd64 /usr/local/bin/minikube

3. 설치 완료 후 `minikube version`을 입력해 정상 설치 여부를 확인합니다.

4. `minikube start --driver=docker` 명령어를 입력해 minikube를 실행합니다.

4. minikube 사용팁

1. alias 등록

k8s 명령 실행 시 매번 `kubectl`을 입력해야 하는 번거로움을 극복하기 위해 `k`를 alias로 등록합니다.

echo 'alias k=kubectl' >> ~/.bashrc
source ~/.bashrc

2. 명령어 자동 완성 등록

tab 키를 활용해 명령어가 자동 완성되도록 기능을 설정합니다.

kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl
echo 'complete -o default -F __start_kubectl k' >> ~/.bashrc
source ~/.bashrc

5. 참고

[kubernetes in action] WSL에 minikube 설치하기

wsl에 minikube 설치하기

velog.io

minikube start

minikube is local Kubernetes

minikube.sigs.k8s.io

AWS Private subnet에 ALB 구성

MR. ZERO — Thu, 16 Mar 2023 00:28:41 +0900

1. 구성도

2. 대상 그룹(Target Group) 생성

EC2 > 대상 그룹 > 대상 그룹 생성

유형 인스턴스
대상(Private 인스턴스) 선택

3. ALB 생성

EC2 > 로드밸런서 > 로드밸런서 생성

기본구성

네트워크 맵핑

리스너

4. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS Bastion Host 및 NAT Gateway 구성

MR. ZERO — Thu, 16 Mar 2023 00:28:29 +0900

1. 구성도

2. Private subnet EC2 생성

EC2 > 인스턴스 > 인스턴스 생성

Bastion Host 접속용 키페어 생성

Private subnet 설정 및 퍼블릭 IP 비활성화

3. Private subnet EC2 접속

Public EC2 접속 후
- Bastion Host 접속용 키페어를 .pem 확장자로 복사
- pem 파일 권한 수정 chmod 400 key.pem
- Private EC2 접속 ssh -i key.pem [user_name]@[private_ec2_ip]

4. NAT Gateway 구성

VPC > NAT 게이트웨이 > NAT 게이트웨이 생성

이름, 서브넷, EIP 등 설정

라우팅 테이블 설정

Private subnet 라우팅 테이블에 NAT GW 추가

NAT GW 구성 후 Private EC2에서 인터넷 통신 테스트

5. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS ALB를 통한 이중화 구성

MR. ZERO — Thu, 16 Mar 2023 00:28:13 +0900

1. 구성도

2. Target Group 생성

EC2 > 대상그룹 > 대상그룹 생성

그룹 세부 정보 지정

대상 등록

3. ALB 구성

EC2 > 로드밸런서 > 로드밸런서 생성

ALB 생성 확인

ALB 작동 확인

4. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS EFS 파일시스템 구성

MR. ZERO — Thu, 16 Mar 2023 00:28:01 +0900

1. 구성도

2. EFS 통신을 위한 SG 생성

EC2 > 보안 그룹 > EFS용 SG 생성(인스턴스에 적용된 SG를 인바운드 SRC로 설정)

3. EFS 구성

EFS > 파일 시스템 생성 > 사용자 지정

파일 시스템 설정(사용 목적에 따라 옵션을 다르게 설정 가능)

네트워크 액세스(퍼블릭 서브넷과 EFS SG 설정)

4. 인스턴스에 EFS 마운트

인스턴스 설정
- EFS 유틸 설치
  yum install amazon-efs-utils -y
- EFS 마운트 경로에 디렉터리 생성
  mkdir /var/www/html/efs

EFS 연결

DNS를 통한 탑재 > EFS 탑재 핼퍼 복사

인스턴스에서 명령어 실행

EFS 작동 테스트

파일 다운

브라우저 접근 확인

5. EFS 작동 확인

다른 인스턴스에 동일한 EFS 마운트
앞서 다운받은 파일이 존재하는지 확인

6. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS 커스텀 AMI 생성

MR. ZERO — Thu, 16 Mar 2023 00:27:48 +0900

1. 커스텀 AMI 생성

EC2 > 인스턴스 > AMI를 생성할 인스턴스 선택 > 작업 > 이미지 및 템플릿 > 이미지 생성

이미지 정보 설정

2. 커스텀 AMI를 활용한 인스턴스 배포

인스턴스 생성 시 커스텀 AMI 선택

AWS에 APM 웹서버 구성

MR. ZERO — Thu, 16 Mar 2023 00:27:34 +0900

1. 구성도

2. 인스턴스 배포

EC2 > 인스턴스 > 인스턴스 시작

인스턴스 이름 설정

AMI 설정

인스턴스 유형 설정

키 페어 설정(기존에 사용하던 키 페어가 없을 경우 생성)

네트워크 설정

SG 설정

스토리지 설정

사용자 데이터 설정(아래 배시 입력)

#!/bin/bash
yum update -y
amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2
yum install -y httpd mariadb-server
systemctl start httpd
systemctl enable httpd
usermod -a -G apache ec2-user
chown -R ec2-user:apache /var/www
chmod 2775 /var/www
find /var/www -type d -exec chmod 2775 {} \;
find /var/www -type f -exec chmod 0664 {} \;

Elastic IP 부여

탄력적 IP > 탄력적 IP 주소 할당 > 할당

EIP 선택 > 작업 > EIP 주소 연결 > 인스턴스 설정 > 연결

3. 인스턴스 접속

putty, xshell 등 터미널 도구를 활용해 인스턴스의 EIP로 접속

4. 웹서버 접근

브라우저에서 인스턴스의 EIP로 정상 접근 확인

5. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS 1분만에 기본 네트워크 구성하기

MR. ZERO — Thu, 16 Mar 2023 00:27:21 +0900

1. 구성도

2. VPC / Subnet / Internet Gateway / Route Table 생성

VPC > VPC 생성 > VPC 등 선택

VPC 설정 입력

AZ 설정 입력

서브넷 설정 입력

DNS 설정

설정 결과 확인

3. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS S3와 CloudFront를 활용한 정적 웹사이트 호스팅

MR. ZERO — Thu, 16 Mar 2023 00:27:09 +0900

1. 구성도

1.1. S3를 활용한 구성

1.2. S3 + CloudFront를 활용한 구성

2. S3 정적 웹사이트 구성

S3 생성

S3 > 버킷 만들기 > 버킷 이름과 리전 설정 > 버킷 만들기(속도 테스트를 위해 대한민국과 지리적으로 먼 임의의 해외 리전 선택)

생성한 버킷에 파일 업로드

S3 호스팅 기능 활성화

S3 > 속성 > 정적 웹 사이트 호스팅 편집 > 활성화 > 인덱스 문서 설정 > 변경사항 저장

버킷 엔드포인트로 접근 시 403 확인

버킷 접근권한 설정

S3 > 권한 > 퍼블릭 액세스 차단(버킷 설정) 편집 > 모든 퍼블릭 액세스 차단 체크 해제 > 변경 사항 저장

오브젝트 접근권한 설정

S3 > 권한 > 버킷 정책 편집 > 아래 정책 붙여넣기 > 변경 사항 저장

{
"Id": "Policy1677651198477",
"Version": "2012-10-17",
"Statement": [
  {
    "Sid": "Stmt1677651196313",
    "Action": [
      "s3:GetObject"
    ],
    "Effect": "Allow",
    "Resource": "버킷 ARN 입력/*",
    "Principal": "*"
  }
]
}

버킷 엔드포인트 정상 접근 확인

3. CloudFront 추가 구성

CloudFront 생성

CloudFront > CloudFront 배포 생성 > 원본 도메인에 정적 호스팅용 버킷 선택 > 웹 사이트 엔드포인트 사용 > 배포 생성

배포 도메인을 통해 접근 확인

4. S3 vs CloudFront 속도 비교

S3로만 서빙할 경우 5초 ~ 9초 소요
CloudFront

CloudFront를 구성하는 경우 1초 ~ 2초 소요

5. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS에 ELK 스택 구축(7.x)

MR. ZERO — Thu, 16 Mar 2023 00:26:52 +0900

1. ELK 스택 개념

beats
- 일종의 에이전트 역할로서 로그를 수집하고자 하는 서버에 설치
- 단순히 로그를 수집해서 output(전송)하는 역할
logstash
- ELK 서버 또는 클러스터에 설치
- beats로 부터 수신한 로그를 관리자가 원하는 형태로 재가공해서 es로 전송하는 역할
elasticsearch
- ELK 서버 또는 클러스터에 설치
- 대용량의 로그를 저장하고 검색하는 역할
kibana
- ELK 서버 또는 클러스터에 설치
- 수집한 로그를 다양하게 시각화해서 대시보드로 보여주는 역할

2. 구성도

3. ELK 스택 구축

3.1. ELK 인스턴스 생성

OS : Ubuntu 20.04 LTS 64bit x86
type : ELK가 메모리를 많이 요구하기 때문에 최소 t2.medium 이상

3.2. Elasticsearch 설치

# java 설치
sudo apt-get update
sudo apt install openjdk-11-jdk
 
# 설치
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
sudo apt-get install apt-transport-https
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list
sudo apt-get update && sudo apt-get install elasticsearch
 
# 메모리 수정
sudo vi /etc/elasticsearch/jvm.options
-Xms256m
-Xmx256m
 
# 설정 수정
vi /etc/elasticsearch/elasticsearch.yml
node.name: node-1
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ["127.0.0.1"]
cluster.initial_master_nodes: ["node-1"]
 
# 서비스 등록 및 시작
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service
curl -X GET "localhost:9200"
 
# 상태 확인
curl localhost:9200/_cat/indices?v
curl -X GET localhost:9200/_cat/health?v
curl -X GET localhost:9200/_cat/nodes?v

3.3. Kibana 설치

# 설치
sudo apt-get update && sudo apt-get install kibana
 
# 설정 변경
vi /etc/kibana/kibana.yml
server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: ["http://[es_ip]:9200"]
 
# 서비스 등록 및 시작
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable kibana.service
sudo systemctl start kibana.service

3.4. Logstash 설치

# 설치
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list
sudo apt-get update && sudo apt-get install logstash
 
# 설정
vi /etc/logstash/conf.d/logstash.conf
input {
  beats {
    port => 5044
    host => "0.0.0.0"
  }
}
 
filter {
 
}
 
output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
    #user => "elastic"
    #password => "changeme"
  }
}
 
# 서비스 등록 및 시작
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable logstash.service
sudo systemctl start logstash.service
 
# 상태 확인
tail -f /var/log/logstash/logstash-plain.log

3.5. 모니터링 대상 인스턴스에 Filebeat 설치

# 설치
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.17.8-amd64.deb
sudo dpkg -i filebeat-7.17.8-amd64.deb
 
# 설정 변경
vi /etc/filebeat/filebeat.yml
- type: log
  id: test_log
  enabled: true
  paths:
    - /var/log/*.log
 
filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: true
 
setup.dashboards.enabled: true
setup.kibana:
  host: "[kibana_ip]:5601"
 
output.logstash:
  hosts: ["es_ip:5044"]
 
# 모듈 설정
filebeat modules list
filebeat modules enable [모듈]
 
# 서비스 등록 및 시작
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable filebeat.service
sudo systemctl start filebeat.service
Colored by Color Scripter

4. Elasticsearch / Kibana 인증 설정

# 서비스 중지
sudo systemctl stop elasticsearch.service
sudo systemctl stop kibana.service
sudo systemctl stop logstash.service
 
# es 설정 추가
sudo vi /etc/elasticsearch/elasticsearch.yml
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
 
# es 서비스 실행
sudo systemctl start elasticsearch.service
 
# 패스워드 설정 
sudo /usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive
 
# kibana 설정 수정
sudo vi /etc/kibana/kibana.yml
elasticsearch.username: "elastic"
elasticsearch.password: "설정한 패스워드"
 
# kibana 서비스 실행
sudo systemctl start kibana.service
 
# logstash 설정 추가 
sudo vi /etc/logstash/conf.d/logstash.conf
output {
  elasticsearch {
    user => "elastic"
    password => "설정한 패스워드"
  }
}
 
# logstash 서비스 실행
sudo systemctl start logstash.service

5. AWS SG 설정

ELK 인스턴스 SG에 다음의 인바운드 규칙 추가

src : 모니터링 대상 인스턴스 또는 any / port : 5044 / proto : tcp
src : kibana 접근을 허용하고자 하는 IP / port : 5601 / proto : tcp
src : es 접근을 허용하고자 하는 IP 또는 any / port : 9200 / proto : tcp

6. ELK 동작 확인

"ELK 인스턴스 공인IP:5601" 접속 후 id : elastic / pass : 설정한 비밀번호 입력

왼쪽 메뉴 → Discover 클릭

7. 참고

Certified Kubernetes Administrator(CKA) 자격증 취득 후기(22.12. 시험)

MR. ZERO — Thu, 16 Mar 2023 00:26:40 +0900

1. 취득 계기

MSA가 대세아닌 대세가 된 현 시점에서 K8s는 산업계 표준이라고 해도 무방할 정도로 현업 깊숙이 자리잡고 있습니다.
따라서 보안 엔지니어 입장에서 보안적인 측면을 이해하고 적용을 요청하기 위해 자의반 타의반으로 공부를 시작하게 되었는데요.
네트워크 엔지니어로 커리어를 시작해서인지 공부하는 과정이 상당히 즐거웠고 재밌었네요.
앞으로 남은 CKAD와 CKS까지 천천히 공부하려고 목표를 잡고 있는데 벌써부터 설레는 마음입니다.
취득 기간은 하루에 최소 1시간씩 주 4~5일씩 공부했고 총 6개월이 소요됐습니다. 파드랑 노드가 뭔지도 모르는 제로 베이스에서 시작한 것 치고는 적절한 시간이라고 생각해봅니다. ㅎㅎ

2. 공부 방법

1. 강의

쿠버네티스에 대해 아무것도 모르는 상태였기 때문에 한글로 설명된 초보 수준에 맞는 강의를 듣고싶었고, 이런 조건에 부합하는 강의로서 조훈님의 강의를 처음 수강했었습니다.(링크)
조훈님 강의는 최대한 쉽게 설명해주시려고 노력하시지만 제가 좋아하는 스타일과는 결이 달라서 1회차 완강을 하고 곧바로 유데미의 강의를 들었습니다.(링크)
유데미 강의는 개념과 적절한 실습을 함께 공부할 수 있어서 도움이 많이 됐었고 해당 강의를 2회차 수강하고 블로그에 관련 내용을 정리하는 식으로 복습했습니다.

2. 실습

유데미 강의에서 제공해주는 KodeKloud의 모든 실습 문제를 2회씩 풀었고 Lightning Labs와 Mock Exams를 각각 5번 넘게 풀어 봤습니다.
CKA 시험 등록 후 Linux Foundation에서 제공해주는 killer.sh의 경우 1회차는 시간내에 제한시간 동안 최대한 풀어보고, 못 푼 문제는 답지를 3번정도 정독 했습니다.
killer.sh 2회차 때도 마찬가지로 제한시간 내에 최대한 풀어보는 연습을 했구요. 다만 2회차에는 1회차 때보다 훨씬 많은 문제를 풀 수 있었습니다.

3. 요약

유데미 강의 2회차 수강(모든 실습 문제 풀이) → 강의 내용 블로그 정리 → Lightning Labs, Mock Exams 각각 5회 이상 풀이 → killer.sh 1회차 풀이 → killer.sh 답지 3회 정독 및 부족한 개념 익숙하게 만들기 → killer.sh 2회차 풀이

3. 팁

시험 환경 : 모든 CKA 시험 후기에서 언급되던 열악한 시험환경(커맨드 반응 속도 느림, 연결 끊김 등)에 대해 걱정을 많이했지만 저는 관련 문제를 경험하지 못했습니다. Linux Foundation이 성능을 개선한 것인지 아니면 제가 시험을 봤었던 시간대가 응시자가 적어서 성능 이슈가 없었던 건지는 모르겠지만요. 다행히 killer.sh에서 문제풀이하는 것과 같은 느낌으로 시험을 치를 수 있었습니다.
시간 배분 : K8s 도큐먼트를 참고해야 풀 수 있을 정도로 익숙하지 않은 문제는 플래그 체크하고 바로 넘어갔습니다. 의도한 것인지는 모르겠지만 쉬운 문제들이 모두 뒷쪽에 있었기 때문에 바로 풀 수 있는 것들부터 풀고 어려운 문제들은 천천히 도큐먼트를 보면서 침착하게 풀어 나갔습니다. 그덕분인지 저는 2시간의 시험 시간이 촉박하지 않았고 오히려 남았었습니다.
문제 정독 : 문제 지문을 꼼꼼히 읽어서 실수를 방지해야 합니다. 가령 특정 노드에만 설정을 적용한다거나, 특정 노드는 배제한다거나 하는 요구사항이 있기 때문에 실수하지 않도록 조심해야 합니다.
SSH exit : 문제 지문에서 컨텍스트를 변경하는 명령어까지 제공해주고 있어 컨텍스트를 혼동할 위험은 없어졌으나, 노드에 ssh로 접근한 경우 다음 문제에서는 반드시 터미널을 exit해야 합니다. 자칫하면 왜 문제에서 말하는 네임스페이스가 없지? 왜 서비스가 없지? 하면서 엉뚱하게 시간 낭비를 할 수 있습니다.

WSL2 설치

MR. ZERO — Thu, 16 Mar 2023 00:26:23 +0900

1. WSL 설치

OS 버전 확인
- window + R → winver 입력 → 20H1 버전 이상인지 확인

WSL 설치(관리자 권한 powershell에서 명령어 실행)

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

2. version2 변환

파워쉘 관리자 권한 실행 후 명령어 입력

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

재부팅
파워쉘 관리자 권한 실행 후 명령어 입력

wsl --set-default-version 2

윈도우용 리눅스 커널 설치(링크)

3. 이미지 다운로드

window + S → microsoft store 입력 → 원하는 리눅스 이미지 검색 → 다운로드

4. WSL 명령어

WSL 목록 확인 : wsl -l
상세 정보 확인 : wsl -l -v
WSL 종료 : wsl -t [wsl_name]

5. 참고

Kubernetes Blue·Green / Canary 배포 방법

MR. ZERO — Thu, 16 Mar 2023 00:26:04 +0900

1. 개념

Blue·Green 및 Canary 배포 전략에 대한 개념은 앞서 작성한 글 참고
Blue·Green 배포 : Blue 리소스를 구성하고 Selector로 서비스와 맵핑한 상태에서 Green 리소스를 구성하고 서비스의 Selector를 Green으로 변경
Canary 배포 : v1과 v2 리소스를 구성하고 두 리소스를 Selector로 서비스와 맵핑한 상태에서 v2의 레플리카 개수를 점진적으로 증가시킴과 동시에 v1의 개수를 감소시키다 마지막에는 v1 리소스 삭제

2. Blue·Green 배포

Blue에 해당하는 nginx 웹서버 리소스 구성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: resource-blue
  namespace: default
spec:
  replicas: 5
  selector:
    matchLabels:
      app: resource-blue
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: resource-blue
    spec:
      containers:
      - image: nginx
        name: nginx
      restartPolicy: Always

서비스 생성 및 selector를 통해 Blue 리소스와 맵핑

apiVersion: v1
kind: Service
metadata:
  name: blue-green
spec:
  ports:
  - name: "80"
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: resource-blue
  type: NodePort

Blue 리소스 서비스 접근 테스트

Green에 해당하는 아파치 웹서버 리소스 구성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: resource-green
  namespace: default
spec:
  replicas: 5
  selector:
    matchLabels:
      app: resource-green
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: resource-green
    spec:
      containers:
      - image: httpd
        name: httpd
      restartPolicy: Always

서비스의 selector를 Green 리소스와 맵핑
Green 리소스 서비스 접근 테스트

3. Canary 배포

v1 리소스 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary-v1
  namespace: default
spec:
  replicas: 5
  selector:
    matchLabels:
      app: canary
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: canary
    spec:
      containers:
      - image: nginx
        name: nginx
      restartPolicy: Always

v2 리소스 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary-v2
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: canary
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: canary
    spec:
      containers:
      - image: httpd
        name: httpd
      restartPolicy: Always

서비스 생성 및 selector를 통해 v1과 v2 리소스를 서비스에 맵핑

apiVersion: v1
kind: Service
metadata:
  name: svc-canary
spec:
  ports:
  - name: "80"
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: canary
  type: NodePort

서비스 접근 테스트(현재 5:1 비율)

v2 레플리카 증가 및 v1 레플리카 감소 및 서비스 접근 테스트(현재 1:5 비율)

v1 리소스 삭제

Kubernetes Custom Resource 개념 및 설정

MR. ZERO — Thu, 16 Mar 2023 00:25:48 +0900

1. 개념

디플로이먼트, 레플리카셋 등 기본적으로 정의된 리소스 외에 Custom Resource를 활용하여 관리자가 원하는 리소스를 정의하고 사용 가능

2. Custom Resource 생성

crd 생성

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: internals.datasets.kodekloud.com
spec:
  group: datasets.kodekloud.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                internalLoad:
                  type: string
                range:
                  type: integer
                percentage:
                  type: string
  scope: Namespaced
  names:
    plural: internals
    singular: internal
    kind: Internal
    shortNames:
    - int

.metadata.name : crd의 이름. plural+group의 조합으로 구성
.spec.group : API 이름
.spec.versions.name : API 버전
.spec.versions.schema.openAPIV3Schema.properties.spec.properties : crd에서 요구하는 값
.spec.scope : crd 적용 범위. Namespaced 또는 Cluster
.spec.names.plural : URL로 호출 시 사용할 alias
.spec.names.singular : CLI로 핸들링 시 사용할 alias
.spec.names.kind : crd 매니페스트 생성 시 기입할 kind. 일반적으로 singular를 카멜케이스 형식으로 작성
.spec.names.shortNames : crd의 단축어

3. Custom Resource 사용

생성한 crd에 맞춰 리소스 생성

kind: Internal
apiVersion: datasets.kodekloud.com/v1
metadata:
  name: crd-test-internal
  namespace: default
spec:
  internalLoad: "high"
  range: 80
  percentage: "50"

.apiVersion : .spec.group/.spec.versions.name
.spec : .spec.versions.schema.openAPIV3Schema.properties.spec.properties에 정의한 값

4. Custom Resource 핸들링

k get crd : Custom Resource 목록 확인

k describe crd [crd_name] : Custom Resource 세부 정보 확인

k delete crd [crd_name] : Custom Resource 삭제

k get [shortNames] : crd를 통해 생성한 리소스 확인

Kubernetes Admission Controller(Mutating / Validating) 개념 및 설정

MR. ZERO — Thu, 16 Mar 2023 00:25:31 +0900

1. 개념

쿠버네티스에서 파드 등의 리소스를 생성하는 경우 접근권한은 3단계를 거치게 됨
- Authentication(인증) → Authorization(인가) → Admission Control
인증·인가에서는 인가된 사용자인지, 적절한 권한이 있는지를 확인함
Admission Control은 인가되고 권한을 보유한 이용자의 액션에 대해 관리자가 정의한 설정을 적용하도록 강제함
Admission Control로 핸들링이 가능한 액션(플러그인)은 링크에서 확인 가능

2. Admission Controller 예시

kube-api의 --enable-admission-plugins에 NamespaceAutoProvision 설정

ns 목록 확인

존재하지 않는 ns에 파드 생성

자동으로 ns가 생성 및 파드가 생성됨을 확인

3. Mutating / Validating

Admission Controller의 세부 동작 단계로서 Mutating이 먼저 수행되고 그 다음 Validating을 수행
- Mutating : API 요청을 검사해 관리자가 정의한 규칙에 어긋나는 경우 요청 내용을 수정
- Validating : API 요청의 유효성을 검사하여 요청을 거절 또는 승인

4. 참고

Kubernetes Statefulset 개념 및 설정

MR. ZERO — Thu, 16 Mar 2023 00:25:11 +0900

1. 개념

파드에 저장된 데이터 또는 파드의 설정을 stateful하게 유지해야 하는 경우 Statefulset 활용
Statefulset으로 생성한 파드는 재생성 시에도 랜덤한 문자열 이름이 아닌 관리자가 정의한 특정 규칙의 이름으로 생성
Statefulset으로 생성한 파드의 스토리지는 PVC로만 연결 가능
Statefulset에 접근하기 위해서는 headless service 생성 필요

2. Statefulset 생성

headless service 생성

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
  labels:
    app: headless-svc
spec:
  ports:
  - name: http
    port: 80
  clusterIP: None
  selector:
    app: test-sts

statefulset 생성

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: test-sts
spec:
  selector:
    matchLabels:
      app: test-sts
  serviceName: headless-svc
  replicas: 3
  template:
    metadata:
      labels:
        app: test-sts
    spec:
      containers:
      - name: zero
        image: nginx
        ports:
        - containerPort: 8080

3. statefulset 확인

파드의 이름이 랜덤한 문자열이 아닌 statefulset 생성 시 설정한 test-sts-n 형식으로 생성

sts의 파드가 삭제되어도 순차적으로 삭제

headless 서비스를 통해 sts 파드 접근