SEMINAR

CLOUDNATIVE SECURITYCON(CNCF) 참관 후기
작성일: 2024-07-16

1. 참가 배경

 

  • Linuxfoundation에서 진행하고 있는 CloudNatvie 보안관련 컨퍼런스인 CNCF SECURITYCON에 메가존클라우드의 글로벌 사업화와 클라우드 보안 사업에 대한 전문성을 확보하고자 당 컨퍼런스에 발표자로 2024년 2월 1일 부터 준비를 하였습니다.

 

  • 발표준비에 앞서, CNCF SecurityCON에 대한 정보를 찾아보았으나 기 발표 세션에 대한 내용이외에는 자료가 없어, 어떤 내용으로 발표준비를 하면 좋을지에 대한 정보 수집 과정, 그리고 CloudNatvie Open Source에 대한 많은 경험이 없어 이에 대한 확인 및 검증 과정에 예상보다 시간이 많이 소요가 되어, 현업을 진행하면서 위 과정을 같이 준비하기에는 다소 촉박하게 진행이 되었습니다.

 

  • 3월 말 경, SECURITYCON 발표 주제 중 하나인 Observability + Detections + Response 으로 발표 세션으로 등록을 했습니다. Monitoring and responding to cloud native vulnerabilities, attacks, and bugs. Minimizing downtime, discovering the root cause and preventing recurrences.

 

 

  • 준비한 내용은 Tetragon을 통해 eBPF를 활용하여 커널 레벨에서 발생 하는 이벤트와 Kubernetes 데이터를 fluenbit을 사용해 수집하고, 각 데이터 목적에 맞게 대시보드 구성이 가능한 OpenSearch와 Grafana로 전송하여 유료 솔루션 없이도 Pod의 OS행위와 Network Traffic을 탐지 할 수 있는 모니터링 및 알람 체계를 제언 하였습니다.

 

  • 참여 신청 시, 발표 주제에 대한 설명 및 발표자에 대한 정보를 기입하는 것으로 신청절차는 마무리가 되었습니다. 실제 발표자료는 발표자 선정 이후에 SECURITYCON 1주일 전까지 제출하도록 일정이 짜여져 있어, 발표 이후에 구체적인 자료는 만들 계획에 있었습니다.

 

 

  • 하지만 아쉽게도, 5월 중순에 최종 발표자 선정에 들지는 못하여, 이번 2024 SECURITYCON에서 발표하겠다는 목적을 달성하지는 못하였습니다.

 

 

하지만 감사하게도, 경험과 관련 기술 습득의 목적으로 SECURITYCON에 참석할 수 있는 기회를 주셔서, 이번 컨퍼런스에 참가하게 되었습니다. 참가하는 목적은 저희가 준비했던 발표내용에 대한 고도화, 고객사에게 제공될 수 있는 오퍼링 강화, 다음에는 발표자로 참석할 수 있도록 경험을 얻는 것이 목적이였습니다.

 

 

2024년 06월 26일 부터 27일까지 열리는 CNCF SECURITYCON에 다음과 같이 참석하게 되었습니다. 본 행사는 Seattle Convention Center SUMMIT에서 진행이 되었습니다. 이 Center는  2023년에 지어진 건물로 AWS 본사가 Seattle에 위치해 있는 만큼 다양한 행사가 열릴 것으로 기대됩니다.

 

 

SECURITYCON에서는 6개의 중규모의 클래스 룸과 2개의 큰 홀에서 키노트 및 세션을 지원하고 있었습니다. 우리는 사전에 관심있는 세션을 정의하여, 하루에 약 6개의 세션에 참석 하였습니다.

 

 

오전에는 6개의 키노트와 2개의 세션에 참석하였고 점심시간 이후에는 4개의 세션에 참석을 할 수 있었습니다. 쉬는시간에는 스폰서의 부스에 참석하여, 관심이 있었던 내용에 대해서 자유롭게 질의를 할 수 있었습니다.

 

 

 

본 행사장의 크기는 예상보다 크지 않았고, AWS SEOUL SUMMIT 2024에 비교를 하자면 약 ⅓~ ¼ 정도의 규모로 진행이 되었습니다. 타 CNCF의 행사에 비해 다소 한산한 모습입니다.

 

 

부스에는 Sysdig, ARMO, Isovalent, OpenSearch, Teleport 등이 참여했습니다.

 

 

 

2. 세션 내용

 

CNCF에서 시작한 보안 컨퍼런스 이지만 시작한지 얼마 되지 않은 관계로 기술적으로 깊은 내용은 없었으나, 신규 솔루션들을 접하거나 기존에 알고 있던 솔루션들에 대해 좀더 상세히 질문을 할 수 있었던 부분이 큰 성과 였다고 생각 합니다.  특히, 이번 컨퍼런스의 분위기와 CNCF에서 추구하는 철학 및 문화에 대해서 이해할 수 있었으며, 다음에 발표자로 지원할 때 이번 보다는 더 좋은 제안을 할 수 있을 것으로 기대합니다. 참석했던 세션 중 감명깊은 몇 가지 세션에 대해서 다음과 같이 소개드리려고 합니다.

 

가. 기술 세션

 

[CSI Forensics : Unraveling Kubernetes Crime Scenes]

 

  • 보안 업무를 하고 있으나, Forensics에 대한 경험이 없어, 이 세션에 대해서 매우 흥미가 있었습니다. 실제 문제가 발생했을 경우에 어떻게 Forensics을 진행하는지에 대한 내용을 예상하였으나 본 세션에서는 Forensics을 하기 위한 정보 수집을 어떻게 자동으로 할 수 있는가에 대한 내용이었습니다.

 

 

Kubernetes CheckPoint API는 2022년 말에 최초로 공개가 되었고, 실행 중인 컨테이너의 스테이트풀(stateful) 복사본을 생성하는 기능으로서, 포렌식에 필요한 정보를 백업하는데 사용할 수 있고, 초기 런타임이 오래 걸리는 컨테이너가 있을 경우, 런타임을 줄이는데, 사용 할 수 있습니다.

 

본 세션의 핵심은 Kubernetes CheckPoint API를 포렌식이 필요한 시점에 호출을 하여 복제본을 저장을 할 수 있는가에 있습니다.

 

호출에 대한 조건을 Falco의 Rule로 이용하고 있는데, Falco는 Linux 시스템용으로 설계된 클라우드 기반 보안 도구입니다. 컨테이너 및 Kubernetes 메타데이터로 강화된 커널 이벤트에 대한 사용자 지정 규칙을 사용하여 실시간 경고를 제공합니다. Falco는 비정상적인 동작, 잠재적인 보안 위협, 규정 준수 위반에 대한 가시성을 확보하여 포괄적인 런타임 보안에 기여합니다. 또한 많은 제품들이 Falco를 CNAPP의 엔진으로 많이 채택을 하고 있으며, 대표적인 사례는 Sysdig을 들 수 있습니다.

 

예를 들면, Falco룰에 취약한 IP로 알려져있는 List들과 통신을 할때 dectect하는 룰을 설정합니다. 설정된 룰에 해당되는 통신이 존재하는 경우에 Argo workflow를 이용하여, K8S CheckPoint API를 호출합니다.

CheckPoint는 Tar파일형식으로 압축된 파일을 생성하게 되며, 이 파일은 Buildah를 이용하여 Registry에 등록 후, 복원을 할 수 있습니다.

 

복원된 컨테이너는  다양한 분석툴을 이용하여 분석을 진행할 수 있으며, 특히 오픈소스인 checkpointctl을 이용할 수 있습니다.

따라서 기존 방식인 로그 감사 이외에, 적극적으로 활용할 수 있는 checkpoint 복사본을 이용하여 정적 및 동적 진단을 수행하여 침해사고에 적극적으로 대응 할 수 있습니다.

 

분석에 대한 데이터가 많이 쌓인다면, 이에 대한 부분도 자동화 하여 Kubernetes의 보안관리에 효율적으로 운영이 가능 할 것으로 판단됩니다.

 

아래는 자동화에 사용되는 Tool과 설명이 정리되어 있는 표입니다.

 

 

[Proactive Kubernetes Security : Anomaly Detection and Runtime Alerting in Kubernetes Workloads]

 

저희가 소개 하려고 했던 Tetragon과 fluentbit을 활용한 eBPF기반 모니터링과 비슷하게 오픈 소스 보안 플랫폼인 Kubescape의 ARMO사에서도 비슷한 내용으로 소개 했습니다. KubeCop이라는 PoC를 기반으로 Kubernetes 환경에서 실시간으로 위협을 감지하고 대응하는 방법을 소개 했습니다. KubeCop은 어플리케이션의 정상적인 프로파일을 구축하고 이를 기준으로 이상 행위를 감지(Anomaly Detection) 합니다. 주요 기능으로는 서명기반 및 이상 기반 악성 행동 감지, ClamAV(오픈소스 기반 안티바이러스 엔진)를 활용한 호스트 악성 코드 스캐닝이 있습니다.

 

 

해당 프로젝트는 다양한 외부 엔드포인트로 Alert를 보낼수 있으며, Prometheus로 메트릭을 전송할 수 있습니다. 규칙을 적용하여 AlertManager와 같은 시스템과 통합해 위협에 신속히 대응 할 수 있게 합니다.

KubeCop 내용 확인 및 설치를 진행하고 싶으신 분들께서는 아래 깃허브 링크를 통해 내용을 확인하거나 Helm을 통해 설치가 가능합니다.

 

Reference : https://github.com/armosec/kubecop?tab=readme-ov-file

 

[Leveraging CNCF Projects Against Kubernetes’ OWASP Top 10]

 

OWASP는 오픈소스 웹 어플리케이션 보안 프로젝트로서, 정기적으로 10개의 주요 어플리케이션의 취약점을 발표하는 것으로 많은 분께 친숙할 것으로 생각됩니다.

 

본 세션에서는 다음의 항목에 대하여 10개의 취약점을 Cloud Native Project로 어떻게 보완할 수 있을 것인가를 주제로 설명이 진행이 되었습니다.

 

K01: Insecure Workload Configurations

K02: Supply Chain Vulnerabilities

K03: Overly Permissive RBAC Configurations

K04: Lack of Centralized Policy Enforcement

K05: Inadequate Logging and Monitoring

K06: Broken Authentication Mechanisms

K07: Missing Network Segmentation Controls

K08: Secrets Management Failures

K09: Misconfigured Cluster Components

K10: Outdated and Vulnerable Kubernetes Components

 

K01: Insecure Workload Configurations

  • 안전하지 않은 설정으로 인해 발생될 수 있는 취약점입니다. 2022년 자료에 따르면 약 53%가 해당 취약점을 경험했다는 보고가 있습니다.
  • 잘못 설정 했을 경우 큰 영향을 미칠 수 있는 예는 다음과 같습니다.
    • Application Process를 Root로 실행하는 경우
    • 목적에 따라 읽기 전용 파일 시스템을 고려하지 않는 경우
    • 무 분별한 privileged를 설정하는 경우
    • 리소스 제약 조건을 고려하지 않은 경우
    • 적용 가능한 Open Source Project
      • Kyverno
      • Kubescape
      • Open Policy Agent
      • Falco
      • KUBEWARDEN

 

K02: Supply Chain Vulnerabilities

  • Legacy 시스템에서 Cloud 시스템으로의 변화 중 가장 큰 것 중 하나는 다변화일 것입니다.
  • 이미지를 빌드하고 배포하는 과정 중 수많은 패키지가 설치 되며, 이 중에는 신뢰성에 대한 담보가 되지 않은 패키지도 포함될 수 있습니다.
  • 또한 신뢰도가 높은 제품이더라도, 공격을 당해 백도어로 이미지가 변질이 될 가능성도 있기 때문에 이미지, 소프트웨어, 패키지 등에 대한 전반적인 검토가 요구됩니다.
  • 적용 가능한 Open Source Project
    • Kyverno
    • Open Policy Agent
    • Falco
    • HARBOR
    • TUF
    • in-toto

 

K03: Overly Permissive RBAC Configurations

  • 역할 기반 액세스 제어(RBAC)은 많은 권한관리 방법 중 권장 표준 처럼 자리 잡고 있습니다.
  • 모든 권한관리가 그렇듯이, 반드시 필요한 권한만 부여해야 하며 이는 주기적으로 검토하여 지속적으로 조정하려는 노력이 필요합니다.
  • Kubernetes의 RBAC에 대한 관리도 마찬가지입니다. 특히 많은 권한을 가지고 있는 cluster-admin의 불필요한 사용사례는 침해사고가 발생되었을 경우, 인프라 전체에 큰 영향을 미칠 수 있습니다.
  • 적용 가능한 Open Source Project
    • Kyverno
    • Open Policy Agent
    • Falco
    • KEYCLOAK

 

K04: Lack of Centralized Policy Enforcement

  • 인프라의 안전을 지키기 위해서는 지속적인 모니터링 및 검토, 개선이 이뤄져야 합니다.
  • 하지만 이런 행위들이 되지 않는다면 문제가 발생해도 쉽게 감지를 하지 못하고 적절한 시기에 대응이 어렵습니다.
  • 잘못 구성된 워크로드 뿐만 아니라, 객체레벨까지 생성 요청 시 차단할 수 있도록 해야 합니다.
  • 적용 가능한 Open Source Project
    • Kyverno
    • Open Policy Agent
    • Falco
    • argo
    • flux

 

K05: Inadequate Logging and Monitoring

  • Kubernetes에서도 Log적재는 매우 중요합니다.
  • 인증, 접근, 리소스 변경 등 인프라에 어떠한 문제가 생겼을 때, 원인을 찾기 위한 로그를 모두 적재를 했는지에 대한 검토가 필요합니다.
  • 또한 로그의 위변조, 삭제를 방지 하기 위해서는 반드시 별도의 장소에 보관해야 하며, 정기적으로 분석 가능한 방법까지 함께 마련해야 합니다.
  • 다음과 같은 로그를 활성화 하는 것을 권장합니다.
    • Kubernetes Events
    • Application & Container Logs
    • Operating System Logs
    • Cloud Provider Logs
    • Network Logs
  • 적용 가능한 Open Source Project
    • OpenTelemetry
    • cortex
    • flentd
    • JAEGER
    • Prometheus

 

K06: Broken Authentication Mechanisms

  • 인증에 대한 중요성은 몇번을 강조해도 지나침이 없습니다. 인증 과정이 안전하지 않다면 우리의 자산은 지키기에는 어려울것입니다.
  • Kubernetes의 인증 주체는 User와 Service Account로 나눌 수 있습니다.
  • 다음은 인증과 관련한 권장사항을 소개해드립니다.
    • 최종 사용자 인증에 인증서 사용은 피해야 합니다.
    • 자체 인증을 만드는 것을 권장하지 않습니다.
    • MFA를 반드시 사용하세요.
    • 클러스터 외부의 서비스 계정 토큰을 사용하지 마세요.
    • 단기 토큰을 사용자 및 외부 서비스 인증에 사용하세요.
  • 적용 가능한 Open Source Project
    • KEYCLOAK
    • Falco

 

K07: Missing Network Segmentation Controls

  • 전통적인 네트워크 보안방법론에 따라 우리는 인프라의 네트워크 영역을 분리해서 사용합니다. 주요 데이터가 있는 인프라는 외부와 통신이 되지 않는 Private 영역에, 외부와 통신을 해야 하는 서비스 인프라는 Public영역에 두고 운영합니다.
  • 주요 데이터를 외부의 침입에 구조상으로 방지 하기 위함입니다.
  • Kubernetes를 사용할때도 마찬가지입니다. 데이터 흐름에 따라 통신이 되어야 할 구간과 통신이 되지 않을 구간을 구분하여, 네트워크 정책을 설정해야 합니다.
  • 적용 가능한 Open Source Project
    • Istio
    • cilium
    • LINKERD

 

K08: Secrets Management Failures

  • 쿠버네티스에서 Secret은 비밀번호나 토큰과 같은 민감한 데이터를 포함하는 작은 객체입니다.
  • 값 및 디스크에 대한 암호화를 고려해야 하며, RBAC을 활용하여 접근 권한을 최소로 유지해야 합니다.
  • 물론, Secret에 대한 접근 로깅 및 감사도 같이 이뤄져야 합니다.
  • 적용 가능한 Open Source Project
    • LINKERD
    • SPIRE
    • spiffe

 

K09: Misconfigured Cluster Components

  • 설정값으로 인프라를 유지할수 있는 Kubernetes환경에서 설정값에 대한 중요성은 매우 높습니다.
  • 설정값에 대한 지속적인 점검을 하여, 의도한대로 인프라가 생성 및 유지될 수 있게 관리를 해야 합니다.
  • 적용 가능한 Open Source Project
    • Kyverno
    • Open Policy Agent
    • Falco
    • KEYCLOAK
    • spiffe

 

K10: Outdated and Vulnerable Kubernetes Components

  • Legacy에서도 패치관리는 알려진 취약점을 제거하는 중요하면서도, 운영환경에 적용하기는 어려운 일이였습니다.
  • 하지만 다양한 방법론을 통해 우리는 최대한 취약한 구성요소를 제거해야 합니다.
  • CVE 데이터베이스 활용 및 스캐닝 툴을 이용하여, 지속적으로 취약점을 관리 해야 합니다.
    적용 가능한 Open Source Project

    • flux
    • argo
    • Falco
    • Kubescape

 

OWASP Top10 에 대한 상세한 내용은 아래 링크를 통해 확인 가능 합니다.
Reference : https://owasp.org/www-project-top-ten/

 

 

나. 문화 관련 세션

 

[Championing Security: Generic Presentation Scaling Security At Every Level]

 

  • Security Champion(이하 보안 챔피언)을 들어본적 있으신가요? 보안 챔피언은 보안부서가 아닌 일반 부서에 1명을 지정하여, 팀 내 보안의식 개선 활동 및 의사소통을 할 수 있는 담당자를 의미합니다. 해당 인원은 주기적으로 교육기회 및 보상을 제공하며 회사의 보안수준을 높이는데 기여합니다.

 

  • 최근 대부분 발생되는 침해사고는 임직원의 실수로 인해서 발생되는데요, 본 세션에서도 Slack또는 Jira에 스미싱 URL주소를 공유하여, 발생했던 사례를 들었습니다.

 

  • 임직원의 보안의식 개선은 한국 Compliance에서도 중요하게 다뤄지는 항목이라, 더 흥미로웠는데요, 이러한 보안 챔피언 제도를 잘 유지하려면 어떻게 해야 할까요?

 

  • 다음은 성공적인 보안 챔피언 프로그램을 유지하기 위한 주요 요건 입니다.

 

A . 대상 팀 식별하기
  • 대상 팀의 업무 및 커뮤니케이션 프로세스를 확인하고, 현재 보안 상태와 사용되는 기술들을 파악하여, 현재의 보안 수준 진단 및 목표 수준을 설정하기 위한 자료를 수집합니다.

 

B. 역할 정의
  • 보안 챔피언이 수행해야 할 역할을 정의합니다. 식별 과정에서 도출된 내용 또는 목표수준에 도달하기 위해 해야 할 활동을 정의합니다.
  • 대표적인 활동들은 보안 표준 및 절차에 대한 의견을 제공 또는 조직원들의 보안 의식 개선, 보안 코드 검토 수행,보안 테스트 도구 사용등이 있을 수 있습니다.

 

C. 챔피언 추천하기
  • 보안 챔피언의 역할 책임과 소요 시간(역할의 20%)에 대한 경영진의 동의가 필요합니다.
  • 보안 챔피언은 보안 직원이 아닌, 개발자, 운영 또는 QA 역할등이 될 수 있습니다.
  • 보안 담당자 1명당 최대 5명의 보안 챔피언을 지원하며, 보안 챔피언은 자신의 팀을 지원하는 것을 권장합니다. 특히 기술 플랫폼별로 특정 기술력을 활용할 수 있는 것이 권장됩니다.
  • 보안 챔피언을 지정할 때, 역할과 그 혜택에 대해 논의하여 후보자가 적합한지 논의하고, 지정이 된다면 보안 챔피언 프로그램과 그 구성원을 조직에 알립니다.

 

D. 커뮤니케이션 채널 설정
  • 보안 담당자와 보안 챔피언이 자유롭게 논의할 수 있는 채널을 생성하고, 정기적인 미팅을 통해 모든 문제에 대해서 논의하고 필요에 따라 목표를 조정할 수 있습니다.

 

E. 견고한 지식 기반 구축
  • 보안 지침을 참조할 수 있는 단일 Database가 필요합니다. 조직의 보안 정책 및 절차, 그리고 활동으로 만들어진 모든 지식자료들을 공유하여, 모든 구성원이 업무에 참고할 수 있도록 합니다.

 

F. 관심 유지
  • 보안 챔피언이 지속적인 열정을 가지고 보안활동을 홍보할 수 있도록 동기를 부여하고, 성과에 대한 부분을 회사 내에 지속적으로 공유를 지원합니다.
  • 공식적으로 이러한 활동에 대해서 직책 부여 및 성과 반영을 하여 개인이 보안 챔피언에 참여할 수 있도록 동기를 부여할 수 있습니다.
  • 또한 보안 챔피언의 보안 목표와 주요 결과와 같이 목표를 설정하고 달성률을 확인 할 수 있도록 하여, 현재 진행상황에 대해서 지속적으로 점검할 수 있도록 지원합니다.

 

한국에 많은 보안 담당자들이 Compliance 유지 관리하는데 많은 시간과 노력을 들이고 있어, 적극적인 개선활동을 개진하기에는 어려운 것이 현실입니다만, 많은 보안사고가 내부 권한자의 실수로 이뤄지는 만큼 이러한 보안 활동들을 통해, 임직원의 보안 수준이 향상이 된다면 실질적인 기업 보안의 수준이 효과적으로 향상될 수 있는 방법이 아닐까 합니다.

 

 

 

3.참가 소감

 

CNCF의 행사 중 SecurityCon은 CloudNatvie 중 Security에 중점을 둔 행사입니다. 컨퍼런스를 참석을 한 경험은 많지는 않지만, 다양한 보안 경험이 있는 발표자의 주제가 흥미로웠습니다. 짧지만 강렬했던 2일간의 컨퍼런스를 참석한 뒤, 이런 생각들이 들었습니다.

 

  • 발표 신청하기 전에, 다양한 OpenSource의 Contributor로 참여한 경험이 있었으면 어땠을까?
  • 국내에서 대면 접촉이 어려운 솔루션 관계자 및 다양한 해외 기업의 담당자와의 네트워크 형성 기회가 있어 네트워킹이 넓어지는 기회였습니다.
  • 한국에 대비하여, 발표 문서의 표현방식이 자유로웠고, 재미있는 GIF를 이용하거나 핸드폰을 이용하여 배경음을 넣는 등 농담을 섞어 설명하는 분위기가 인상 깊었습니다.
  • 주제에 대해서 너무 편협하게 생각하였던 부분들이 있어, 조금 더 폭넓게 우리의 전문성을 표현할 수 있는 주제로 준비해도 좋을것 같았습니다.
  • 많은 CNCF의 opensource project를 알게 되었고, 창립자 및 CNCF 주요 멤버들을 보고 그들의 생각을 들을 수 있어, 커리어에 대한 생각의 전환을 할 수 있는 계기가 되었습니다 .

작성 ｜메가존클라우드 Cloud Technology Center Cloud Security Team & Office of CTO Team