gitlab2026년 8월 6일

GitLab Secrets Manager, ESO·Terraform·API 지원 추가 (새 탭에서 열림)

GitLab Secrets Manager가 External Secrets Operator(ESO), Terraform/OpenTofu, CLI, API를 지원하면서 CI/CD 외의 환경에서도 하나의 비밀 저장소를 사용할 수 있게 되었다. OpenBao 기반의 Vault 호환 인터페이스를 통해 Kubernetes, 인프라 코드, 외부 자동화가 동일한 방식으로 비밀을 조회하며, 인증에는 단기 JWT를 사용한다. 이를 통해 여러 저장소와 인증 모델, 감사 로그를 따로 관리해야 하는 부담을 줄일 수 있다. ### GitLab Secrets Manager의 통합 비밀 관리 - 기존에는 CI/CD, Kubernetes, Terraform마다 별도의 비밀 저장소를 사용하는 경우가 많았다. - GitLab Secrets Manager는 OpenBao를 기반으로 다음 환경에 동일한 저장소를 제공한다. - Kubernetes 워크로드 - Terraform 및 OpenTofu 실행 - OpenBao 또는 Vault CLI - GitLab CI/CD 작업 - 외부 자동화 시스템 및 스크립트 - Vault 호환 KV v2 API를 제공하므로 기존 Vault 생태계 도구와 연동할 수 있다. - 중앙 집중식 저장소를 사용하면 접근 정책과 감사 추적을 일관되게 관리할 수 있다. ### Kubernetes와 External Secrets Operator 연동 - ESO는 Vault provider를 통해 GitLab Secrets Manager에서 비밀을 가져온다. - Kubernetes 워크로드는 단기 JSON Web Token(JWT)을 사용해 OpenBao에 인증한다. - `SecretStore` 리소스에서 다음 항목을 설정한다. - `server`: GitLab Secrets Manager의 Vault 호환 서버 주소 - `path`: KV v2 마운트 경로 - `namespace`: 조직·그룹·프로젝트 계층을 나타내며 접근 가능한 비밀 범위를 제한 - `auth.jwt.path`: JWT 인증 경로 - `auth.jwt.role`: 사용할 인증 역할 - `secretRef`: Kubernetes Secret에 저장된 JWT 참조 - `ExternalSecret`은 원격 비밀과 Kubernetes Secret 사이의 매핑을 정의한다. - `remoteRef.key`: GitLab Secrets Manager의 비밀 경로 - `property`: 원격 비밀 내부에서 가져올 필드 - `secretKey`: Kubernetes Secret에 저장될 키 - `target.name`: 생성할 Kubernetes Secret 이름 - ESO는 대상 Secret을 생성하고 소유하며, 설정된 `refreshInterval`마다 값을 다시 조회한다. - 비밀이 교체되면 애플리케이션을 재배포하지 않아도 Kubernetes Secret에 변경 사항이 반영된다. ### Terraform과 OpenTofu에서 비밀 조회 - Terraform의 `.tfvars` 파일이나 상태 파일에 인증 정보가 기록되면 자격 증명이 유출될 위험이 있다. - GitLab Secrets Manager를 Terraform data source로 조회하면 비밀을 `.tfvars`나 CI/CD 변수에 직접 저장하지 않고 실행 시점에 가져올 수 있다. - 일반적인 흐름은 다음과 같다. - 외부 스크립트로 GitLab 프로젝트의 단기 JWT를 발급 - Terraform Vault provider에 서버 주소, namespace, 인증 경로, role, JWT 전달 - `vault_kv_secret_v2` data source로 원하는 비밀 조회 - 필요한 경우 `sensitive = true`로 출력값을 민감 정보로 표시 - Terraform 실행 시점에 인증이 이루어지므로 장기 자격 증명을 코드나 설정 파일에 남기는 일을 줄일 수 있다. ### OpenBao 및 Vault CLI 사용 - 기존에 Vault용 CLI나 스크립트를 사용 중인 팀은 별도의 클라이언트를 도입하지 않아도 된다. - `VAULT_ADDR`와 `VAULT_NAMESPACE`를 설정한 뒤, 발급받은 JWT를 JWT 인증 엔드포인트에 전달한다. - 인증 결과로 받은 OpenBao 토큰을 `VAULT_TOKEN`에 설정한다. - 이후 `vault kv get` 명령으로 KV v2 경로의 비밀을 조회할 수 있다. - Vault 호환 방식을 사용하므로 기존 운영 자동화와의 통합 비용이 낮다. ### Secrets Manager API를 통한 외부 자동화 - GitLab CI/CD, Kubernetes, Terraform에 포함되지 않는 외부 시스템은 Secrets Manager API를 사용할 수 있다. - 서비스 계정 또는 액세스 토큰으로 프로젝트별 액세스 토큰 발급 API를 호출한다. - API 응답에는 다음과 같은 연결 정보가 포함된다. - Vault 서버 주소 - namespace - KV 마운트 경로 - 비밀 경로 - JWT 인증 경로 - 인증 role - JWT - 외부 시스템은 이 정보를 이용해 단기 인증을 수행하고 필요한 비밀만 조회한다. - 하드코딩된 비밀번호나 별도의 변수 파일을 유지하지 않아도 되는 것이 장점이다. ### 실용적인 적용 권장 사항 - Kubernetes에서는 ESO의 `SecretStore`와 `ExternalSecret`을 사용해 자동 동기화와 비밀 교체를 구성한다. - Terraform에서는 비밀을 `.tfvars`에 넣기보다 실행 시점의 data source 조회 방식으로 전환한다. - 기존 Vault 자동화가 있다면 OpenBao/Vault CLI 호환 기능을 우선 활용한다. - 외부 서비스에는 장기 토큰 대신 프로젝트 범위와 역할이 제한된 단기 JWT를 사용하고, 접근 범위와 감사 로그를 함께 관리하는 것이 좋다.

terraformk8sjwtsecrets-management+4

cloudflare2026년 7월 20일

Cloudflare 내부 DNS 정식 출시 (새 탭에서 열림)

Cloudflare Internal DNS는 퍼블릭 DNS와 프라이빗 DNS를 하나의 글로벌 플랫폼과 제어 평면에서 통합하는 서비스다. 이를 통해 스플릿-호라이즌 DNS의 동기화 문제를 줄이고, Zero Trust 정책·감사·가시성을 DNS에도 적용할 수 있다. Cloudflare Gateway를 사용하는 Enterprise 고객은 추가 비용 없이 사용할 수 있으며, 기존 DNS 어플라이언스와 클라우드별 DNS를 대체하는 것을 목표로 한다. ## 기존 내부 DNS 운영의 한계 - 퍼블릭 DNS, 사설 DNS, 클라우드별 DNS가 서로 다른 플랫폼에서 운영되는 경우가 많다. - 시스템마다 보안 정책과 관리 방식이 달라 전체 DNS 구성을 한눈에 파악하기 어렵다. - 스플릿-호라이즌 DNS에서는 같은 호스트명에 대해 내부 사용자와 외부 사용자에게 서로 다른 응답을 제공해야 한다. - 여러 DNS 환경의 레코드를 별도로 관리하면 설정이 서로 어긋나는 드리프트가 발생하고, 장애로 이어질 수 있다. - 레거시 DNS 장비는 하드웨어 교체 주기, 용량 확장, 유지보수 부담을 발생시킨다. ## Cloudflare Internal DNS의 핵심 가치 - 퍼블릭·프라이빗 DNS를 하나의 API, 감사 로그, 정책 관리 체계로 통합한다. - 공유된 존에 여러 DNS 뷰를 적용해 스플릿-호라이즌 DNS를 중복 구성 없이 구현한다. - Cloudflare Gateway의 사용자·기기 기반 정책으로 어떤 DNS 뷰를 사용할지 제어한다. - DNS 질의 필터링, 라우팅, 로깅을 기존 Zero Trust 정책과 동일한 체계로 관리한다. - 1.1.1.1을 운영하는 글로벌 인프라를 활용하므로 별도 장비 설치나 용량 사전 확보가 필요 없다. ## 두 가지 핵심 구성 요소 - **Gateway Resolver** - DNS 재귀 조회와 정책 평가를 담당한다. - 질의를 차단하거나 특정 업스트림으로 전달할 수 있다. - 유연한 조건식, 로깅, 감사 기능을 제공한다. - 정책에 따라 내부 DNS 뷰 또는 퍼블릭 DNS 경로를 선택한다. - **Internal Authoritative DNS** - 프라이빗 리소스의 권한 있는 DNS 레코드를 제공한다. - 애플리케이션, 서비스 엔드포인트, 데이터베이스 등의 내부 존을 관리한다. - Cloudflare의 기존 권한 있는 DNS 플랫폼 위에서 동작한다. ## 주요 객체: 존, 뷰, 리졸버 정책 - **Internal Zone** - 내부 리소스의 권한 있는 레코드를 저장한다. - 예: `corp.internal`, `db.corp.internal`. - **DNS View** - 특정 사용자·기기 그룹이 볼 수 있는 존과 레코드의 해석 맥락을 정의한다. - 내부 사용자에게는 사설 주소를, 외부 사용자에게는 퍼블릭 주소를 제공하는 데 사용된다. - **Resolver Policy** - Gateway에서 질의를 평가하고 특정 DNS View로 전달한다. - 조건에 따라 질의를 허용, 차단하거나 퍼블릭 DNS로 보낼 수 있다. - **Zone Reference** - 하나의 공유 존을 여러 뷰에서 재사용한다. - 동일한 레코드를 뷰마다 복사하지 않으므로 중복과 설정 불일치를 방지한다. ## DNS 질의 처리 과정 - 클라이언트의 질의는 먼저 Gateway Resolver에 도착한다. - 리졸버 정책이 내부 뷰를 지정하면 해당 질의는 Internal Authoritative DNS로 전달된다. - 정책이 질의를 차단하면 응답 없이 삭제된다. - 일치하는 정책이 없으면 1.1.1.1을 통해 퍼블릭 DNS 계층에서 조회한다. - 내부 뷰에서 이름을 찾지 못할 경우 퍼블릭 DNS로 폴백하도록 구성할 수 있어, 클라이언트는 내부·외부 이름을 구분할 필요가 없다. ## DNS 변경 사항의 전파 - 대시보드, Terraform, 직접 API 호출 등 모든 변경은 동일한 DNS Records API를 거친다. - 하나의 쓰기 경로를 사용하므로 변경 이력과 감사를 일관되게 관리할 수 있다. - 변경 내용은 Cloudflare 핵심 데이터센터에 저장되고 검증된 뒤 글로벌 네트워크로 복제된다. - 관련 캐시가 무효화되므로 TTL 만료를 기다리지 않고 수 초 내에 변경 사항이 반영된다. - Terraform 변경도 대시보드나 API 변경과 동일한 전파 경로를 따른다. ## 설정 방법 - Cloudflare 대시보드의 **Networking → Internal DNS**에서 시작한다. - 일반적인 구성 순서는 다음과 같다. 1. 내부 존 생성 2. 내부 DNS 레코드 생성 3. DNS View 생성 후 존 연결 4. Gateway Resolver Policy를 만들어 특정 트래픽을 해당 뷰로 라우팅 - 예시로 `corp.internal` 존을 만들고 `db.corp.internal`을 `10.0.1.50`으로 지정할 수 있다. - Cloudflare API와 Terraform을 모두 사용할 수 있다. - 현재 Cloudflare Gateway를 사용하는 Enterprise 고객이 이용 대상이다. ## Connectivity Cloud와의 통합 - 다음과 같은 DNS 연결 방식과 함께 사용할 수 있다. - Cloudflare One Client(WARP) - DNS over HTTPS(DoH) - DNS over TLS(DoT) - 표준 DNS 53번 포트 - PAC 파일 배포 - Cloudflare WAN - Cloudflare WAN을 사용하면 개별 단말에 One Client를 설치하지 않아도 연결된 네트워크의 장치가 내부 호스트명을 조회할 수 있다. - 원격 사용자, 지사, 데이터센터, 클라우드 환경을 하나의 제어 평면으로 연결해 일관된 DNS 경험을 제공한다. - Internal DNS는 독립적인 DNS 제품이라기보다 Zero Trust와 네트워크 연결을 포함한 Cloudflare Connectivity Cloud의 기능 확장이다. 내부·외부 DNS를 여러 시스템에서 따로 운영하고 있다면, 공유 존과 DNS View를 중심으로 구성을 통합하는 것이 유용하다. 특히 Cloudflare Gateway와 WAN을 이미 사용 중인 조직은 별도 DNS 장비를 줄이고, 정책·감사·전파 경로를 단일화하는 방안을 검토할 만하다.

terraformzero-trustdnscloudflare-gateway+4

cloudflare2026년 7월 10일

퍼블릭 클라우드 리전을 위한 스마트 계층형 캐시 개선 (새 탭에서 열림)

Smart Tiered Cache는 원본(origin)으로 향하는 캐시 미스를 가장 가까운 단일 Cloudflare 상위 티어(upper tier)로 모아 캐시 적중률을 높이는 기능이다. 그러나 AWS·GCP·Azure·Oracle Cloud처럼 anycast 또는 regional unicast를 사용하는 퍼블릭 클라우드 원본은 IP만으로 실제 위치를 판단하기 어려워, 여러 상위 티어를 사용하는 보수적 방식으로 동작했다. 이번 개선에서는 사용자가 클라우드 리전을 지정하면 Cloudflare가 해당 리전에 맞는 주·보조 상위 티어를 선택해 불필요한 대륙 간 우회(hairpin)와 원본 요청을 줄인다. ## Smart Tiered Cache의 목적과 발전 - 모든 요금제에서 무료로 제공되는 Cloudflare의 대표적인 tiered cache 토폴로지다. - 원본 IP의 실시간 지연 시간을 측정해 가장 빠른 Cloudflare 데이터센터 하나를 상위 티어로 선택한다. - 캐시 미스를 한 곳에 집중해 다음 효과를 얻는다. - 캐시 적중률 향상 - 원본으로 연결되는 요청 및 연결 수 감소 - 원본 데이터를 가져오는 지연 시간 감소 - 기존 확장 사례: - **R2 지원(2024년 11월):** R2 버킷의 실제 위치에 가까운 상위 티어를 자동 선택 - **Load Balancing 지원(2025년 1월):** 풀 전체에 동일한 상위 티어를 사용해 공유 캐시와 적중률 개선 ## 퍼블릭 클라우드 anycast 원본의 문제 - 고정된 unicast IP는 특정 물리적 위치에 대응하므로 지연 시간 측정만으로 최적 상위 티어를 고르기 쉽다. - 반면 클라우드 로드 밸런서나 regional ingress의 IP는 여러 클라우드 엣지에서 동시에 응답할 수 있다. - 같은 IP라도 Cloudflare 데이터센터마다 서로 다른 클라우드 엣지로 연결되므로, IP가 실제 백엔드 위치를 나타내지 않는다. - 그 결과 한 곳을 최적 상위 티어로 잘못 선택할 수 있다. - 예를 들어 싱가포르 원본에 대해 시카고 데이터센터가 가장 낮은 측정 지연을 보이면: - 아시아 사용자의 요청이 가까운 Cloudflare PoP에 도착 - 시카고 상위 티어로 대륙을 건너 이동 - 시카고에서 다시 싱가포르 원본으로 이동 - 이런 hairpin 트래픽은 대륙 간 왕복을 추가해 수백 밀리초의 지연을 만들 수 있다. ## anycast 감지와 기존 대응 - Cloudflare는 여러 전 세계 체크포인트에서 원본까지의 probe 지연을 측정한다. - 두 체크포인트 간 물리적으로 빛이 이동할 수 있는 시간보다 전체 경로가 빠르게 나타나면, 하나의 위치가 아니라 여러 위치에서 응답한다고 판단한다. - 이는 해당 원본이 anycast일 가능성이 높다는 의미다. - anycast로 감지되면 Cloudflare는 단일 상위 티어에 고정하지 않고 여러 상위 티어를 사용하는 방식으로 전환한다. - 이 방식은 안정적이지만 트래픽이 여러 티어로 분산되어: - 캐시가 한 곳에 모이지 않음 - 원본으로 전달되는 요청 증가 - 단일 최적 상위 티어를 사용할 때보다 캐시 효율 저하 ## 리전 힌트를 이용한 개선 - 사용자가 원본이 위치한 클라우드 리전을 직접 지정한다. - 예시: - `aws:us-east-1` - `gcp:europe-west1` - Cloudflare는 리전 정보를 바탕으로 IP 자체의 모호한 지연 측정 대신 해당 리전에 적합한 상위 티어를 선택한다. - 각 리전에 대해: - **Primary upper tier:** 가장 강한 신호를 가진 최적 상위 티어 - **Fallback upper tier:** 주 상위 티어와 다른 PoP에 위치한 보조 상위 티어 - 주·보조 티어를 서로 다른 PoP로 구성해 한 PoP 장애가 두 경로를 동시에 제거하지 않도록 한다. - AWS, GCP, Azure, Oracle Cloud에서 출시되며 향후 지원 제공자가 추가될 예정이다. ## 설정 방법과 운영 방식 - Cloudflare 대시보드에서 다음 경로로 설정한다. - `Caching > Tiered Cache > Origin Configuration` - 원본 IP 옆의 **Set Region Hint** 선택 - 클라우드 리전 입력 - 대시보드에서는 Cloudflare가 anycast로 감지한 원본 IP에만 리전 힌트를 설정할 수 있다. - IP별 개별 설정뿐 아니라 여러 원본 IP에 대한 일괄 편집도 가능하다. - API와 Terraform도 지원하므로 Infrastructure as Code 환경에 통합할 수 있다. ## 리전 매핑과 상위 티어 선택 방식 - Cloudflare는 지원 클라우드 제공자의 최신 IP 범위 파일을 몇 시간마다 가져온다. - 이 파일을 통해 각 클라우드 리전과 현재 IP prefix를 매핑한다. - 클라우드 제공자가 서브넷을 추가·삭제·재할당해도 최신 정보를 반영한다. - Cloudflare의 상위 티어 데이터베이스는 15분마다 갱신되는 지속적인 지연 시간 측정 결과로 구성된다. - 리전에 속한 각 서브넷은 현재 상위 티어 할당 결과에 따라 가중 투표를 제공한다. - 가장 강한 신호를 얻은 상위 티어가 해당 리전의 primary가 된다. ## 실용적인 권장 사항 퍼블릭 클라우드의 anycast 원본에서 캐시 효율이 낮거나 대륙 간 hairpin 지연이 발생한다면, 원본 IP에 정확한 클라우드 리전 힌트를 설정하는 것이 좋다. 여러 원본을 운영한다면 API나 Terraform으로 리전 정보를 관리하고, primary와 fallback이 서로 다른 PoP로 구성되는지 확인하면 장애 대응과 성능을 함께 개선할 수 있다.

terraformcloudflaretiered-cachinganycast+3

cloudflare2026년 6월 8일

Cloudflare의 위협 지표를 실시간 WAF 규칙으로 전환하기 (새 탭에서 열림)

Cloudflare는 Threat Events의 실시간 위협 인텔리전스를 WAF 규칙에서 직접 사용할 수 있도록 통합했다. 이제 보안팀은 위협 행위자, 공격 대상 산업·국가, 공격 유형과 같은 정보를 바탕으로 악성 IP를 사전에 차단할 수 있으며, 탐지와 차단을 분리해 가시성도 유지할 수 있다. 해당 기능은 WAF 사용자 정의 규칙과 Rate Limiting, API, Terraform, Security Analytics에 통합된다. ## 위협 인텔리전스를 WAF 차단으로 연결 - 기존에는 특정 IP가 Tycoon 2FA, RaccoonO365 같은 위협 행위자와 연관되었거나 특정 산업을 공격했다는 사실을 알아도, WAF에서 직접 차단하려면 수동으로 규칙을 작성해야 했다. - 새 기능은 요청 처리 초기 단계에서 위협 메타데이터를 필드로 채운다. - WAF는 다음 기준으로 트래픽을 평가할 수 있다. - 알려진 위협 행위자 이름 - 해당 IP가 과거 공격한 산업 - 공격 대상 국가 - 공격 발생 국가 - DDoS, WAF, 사이버 범죄 등 데이터셋 또는 공격 유형 - 초기 버전은 IP 기반 매칭에 초점을 두며, 향후 JA3 지문과 도메인 기반 매칭으로 확장될 예정이다. ## 항상 실행되는 탐지 구조 - 이 기능은 사전 규칙 없이도 공격 패턴을 탐지하는 Attack Signature Detection의 “always-on” 프레임워크를 사용한다. - 위협 인텔리전스 탐지는 백그라운드에서 지속 실행되며, 차단 여부를 결정하기 전부터 HTTP 요청에 위협 메타데이터를 추가한다. - 탐지와 완화(mitigation)를 분리해 기존의 “로그로 볼 것인가, 차단할 것인가”라는 선택 문제를 줄인다. - 차단하면 다른 탐지 시그니처가 해당 요청을 어떻게 판단했는지 확인하기 어렵다. - 항상 탐지하면 먼저 트래픽 패턴과 위협 행위자를 분석한 뒤 차단 규칙을 적용할 수 있다. - Cloudforce One 구독자는 Analytics에서 자사 사이트를 공격하는 위협 행위자와 해당 IP가 주로 공격한 산업을 확인할 수 있다. - 탐지 과정은 매우 낮은 지연 시간으로 실행되도록 설계되어 트래픽 처리 성능을 유지한다. ## WAF에 추가된 위협 인텔리전스 필드 - `cf.intel.ip.attacker_names` - 알려진 위협 그룹 이름 - 예: `CRAVENFLEA` - `cf.intel.ip.target_industries` - 해당 IP가 공격한 산업 - 예: `Cryptocurrency`, `Automotive` - `cf.intel.ip.attacker_countries` - 위협 이벤트의 발신 국가 - `cf.intel.ip.target_countries` - 공격 대상 국가 - `cf.intel.ip.datasets` - 데이터를 제공한 위협 피드 또는 공격 유형 - 예: `ddos`, `waf` ## 배열 필드와 WAF 표현식 - 하나의 IP가 여러 위협 행위자나 산업과 연관될 수 있으므로 관련 필드는 배열로 제공된다. - 배열 내부의 값은 `[*]` 와일드카드 및 `any()` 함수로 검사한다. - 프랑스에서 공격받은 이력이 있고 DDoS 데이터셋에 포함된 IP 차단: ```text any(cf.intel.ip.target_countries[*] == "FR") and any(cf.intel.ip.datasets[*] == "ddos") ``` - 금융 산업을 공격한 BLACKBASTA 관련 IP 차단: ```text any(cf.intel.ip.target_industries[*] == "Banking & Financial Services") and any(cf.intel.ip.attacker_names[*] == "BLACKBASTA") ``` - 특정 발신 국가의 고위험 IP를 광범위하게 차단: ```text any(cf.intel.ip.attacker_countries[*] == "IR") ``` ## API와 Terraform을 통한 자동화 - 새 `cf.intel` 필드는 WAF 사용자 정의 규칙과 Rate Limiting 규칙에서 사용할 수 있다. - 기존 WAF 표현식 문법으로 복합 조건을 작성할 수 있다. - Cloudflare API와 Terraform에서도 지원되므로 다음을 자동화할 수 있다. - 여러 도메인에 동일한 위협 차단 정책 배포 - 계정 전체에 정책 적용 - Infrastructure as Code 기반의 규칙 관리 - 위협 인텔리전스 조건 변경 및 배포 자동화 ## Security Analytics의 가시성 - 위협 인텔리전스 필드로 인해 발생한 모든 매칭은 Security Analytics에 기록된다. - 분석 화면에서 다음 정보를 확인할 수 있다. - 어떤 WAF 규칙이 실행되었는지 - 어떤 위협 지표가 일치했는지 - 해당 요청의 상세 트래픽 맥락 - 이 기록은 규칙 감사, 오탐 분석, 사고 후 검토를 빠르게 하는 데 활용된다. - 분석 결과에서 바로 사용자 정의 보안 규칙을 생성할 수도 있다. ## Threat Events 대시보드에서 원클릭 규칙 생성 - Threat Intelligence Dashboard에서 원하는 조건으로 Saved View를 만들 수 있다. - 예를 들어 “최근 7일 동안 금융 산업을 공격한 IP” 같은 필터를 저장할 수 있다. - IP 목록을 직접 복사하지 않고, Saved View의 조건을 한 번의 클릭으로 WAF 규칙으로 변환할 수 있다. - 조사 단계에서 확인한 위협 동향을 곧바로 운영 차단 정책으로 연결하는 workflow다. ## 글로벌 네트워크에 배포되는 인텔리전스 - Cloudflare는 수백만 개의 위협 지표를 고성능 형식으로 압축한다. - 압축된 데이터셋은 전 세계 Cloudflare 데이터센터로 배포된다. - 요청이 네트워크에 도착하면 Cloudflare WAF가 이 데이터를 이용해 지연 시간을 최소화하면서 위협 여부를 조회한다. - 글의 마지막 부분은 이러한 글로벌 배포와 고속 조회 구조가 대규모 위협 지표를 처리하는 방식으로 이어진다. 실무적으로는 먼저 Threat Events와 Security Analytics에서 위협 패턴을 관찰한 뒤, 신뢰도가 높은 조건을 Saved View나 Terraform 기반 WAF 규칙으로 전환하는 접근이 권장된다. 특히 산업·국가·공격 유형을 조합해 차단 범위를 좁히면 과도한 차단 위험을 줄일 수 있다.

terraforminfrastructure-as-codethreat-intelligencesecurity-analytics+3

aws2026년 5월 28일

생성형 AI 기반 SRE 복원력 여정을 위한 차세대 AWS Resilience Hub 소개 | Amazon Web Services (새 탭에서 열림)

AWS Resilience Hub 차세대 버전은 복원력 정책 설정부터 의존성 탐색, 생성형 AI 기반 장애 모드 분석, 조직 전체 보고까지 하나의 흐름으로 통합한다. 이를 통해 SRE와 개발팀은 애플리케이션별 복원력 목표를 일관되게 정의하고, 실제 장애 대응 수준을 평가하며, 규정 준수 여부를 대규모로 입증할 수 있다. AWS Organizations와 새로운 시스템·서비스 모델을 활용해 여러 계정과 애플리케이션의 복원력 상태를 중앙에서 관리하는 것이 핵심이다. ## 모듈형 복원력 정책 - 단일하고 경직된 정책 유형 대신 필요한 요구사항을 조합해 정책을 구성한다. - 설정 가능한 주요 항목은 다음과 같다. - 서비스 수준 목표(SLO) - 다중 가용 영역(Multi-AZ) 구성 - 다중 리전 재해 복구 - 복구 시간 목표(RTO) - 복구 시점 목표(RPO) - 백업에서 데이터를 복원하는 데 필요한 데이터 복구 시간 - 예를 들어 금융 애플리케이션용 정책에 다음 조건을 정의할 수 있다. - 가용성 SLO 99.95% - 다중 리전 재해 복구 RTO 15분 - RPO 5분 - RTO·RPO에 부합하는 재해 복구 방식 ## 비즈니스 관점의 애플리케이션 모델 - 새로운 모델은 기술 리소스가 아니라 비즈니스 애플리케이션과 사용자 경로를 중심으로 복원력을 표현한다. - 구성 요소는 다음과 같다. - **시스템(System):** 하나의 비즈니스 애플리케이션 - **사용자 여정(User journey):** 중요한 사용자 흐름과 비즈니스 경로 - **서비스(Service):** AWS 리소스, 코드, 관측성 구성으로 이루어진 배포 단위 또는 마이크로서비스 - Resilience Hub는 리소스 간 연결, 데이터 흐름, 포함 관계, 권한 관계를 자동으로 탐색해 토폴로지로 표시한다. - 서비스 토폴로지는 그래프, 테이블, JSON 형식으로 확인할 수 있다. ## 의존성 자동 탐색 - 서비스가 의존하는 AWS 서비스, 내부 엔드포인트, 외부 서드파티 엔드포인트를 자동으로 식별한다. - VPC 쿼리 로그의 DNS 질의를 분석해 설정 문서에 드러나지 않은 의존성도 찾는다. - 특히 다음과 같은 숨은 위험을 발견하는 데 유용하다. - 예상하지 못한 리전 간 호출 - 중요한 외부 서드파티 서비스 의존성 - 애플리케이션 구성에 누락된 내부 엔드포인트 - 서비스 생성 시 의존성 탐색을 활성화하며, 서비스 상세 페이지에서 언제든 비활성화할 수 있다. ## 생성형 AI 기반 장애 모드 분석 - 서비스가 정의된 복원력 정책, AWS Well-Architected 모범 사례, AWS Resilience Analysis Framework를 얼마나 충족하는지 분석한다. - 분석 과정에서 잠재적인 장애 모드를 식별하고 개선 권고사항을 제시한다. - 각 결과에는 다음 정보가 포함된다. - 어떤 장애 상황인지 - 해당 장애가 아키텍처에 중요한 이유 - 문제를 해결하는 방법 - 관련된 복원력 정책 요구사항 - 사용자는 **Failure mode guidance**에서 분석 에이전트를 위한 assertion을 추가하거나 수정할 수 있다. - 권고사항은 적용 후 **해결됨(Mark as resolved)**으로 표시하거나, 환경에 맞지 않으면 **무관함(Mark as irrelevant)**으로 처리할 수 있다. ## 서비스 생성과 평가 절차 - 먼저 Resilience Hub가 AWS 리소스를 읽을 수 있도록 invoker IAM 역할을 설정한다. - AWS Organizations를 사용하지 않는 경우에는 계정 간 역할을 구성할 수 있고, Organizations 환경에서는 서비스 연결 역할(SLR)을 활용할 수 있다. - 콘솔에서 다음 순서로 진행한다. 1. 재사용할 복원력 정책 생성 2. 비즈니스 애플리케이션을 나타내는 시스템 생성 3. 시스템에 서비스 추가 4. 서비스의 리소스 위치와 리전 지정 5. 복원력 정책과 IAM 역할 연결 6. 장애 모드 평가 실행 7. 결과와 권고사항 검토 및 조치 - 서비스 리소스는 리소스 태그, CloudFormation 스택, Terraform 상태 파일, Amazon EKS 클러스터·네임스페이스 등을 통해 지정할 수 있다. - 평가 중 Resilience Hub는 invoker 역할을 사용해 리소스를 읽고, 부모·자식 관계와 리소스 연결을 파악해 전체 토폴로지를 구성한다. ## AWS Organizations 기반 중앙 관리 - 위임된 관리자 계정에서 조직 전체의 복원력 상태를 평가할 수 있다. - 각 AWS 계정에 개별적으로 로그인하지 않고도 여러 애플리케이션의 복원력 수준과 개선 진행 상황을 관리할 수 있다. - 수백 개 애플리케이션에서 서로 다른 복원력 기준과 도구를 사용하는 문제를 줄이고, 조직 차원의 표준화와 규정 준수를 지원한다. ## 기존 고객을 위한 마이그레이션 - 기존 Resilience Hub 애플리케이션과 정책을 새 모델로 전환할 수 있는 마이그레이션 API를 제공한다. - 기존 평가 정책은 새로운 복원력 정책으로 변환된다. - 기존의 여러 관련 애플리케이션은 하나의 시스템과 여러 서비스 구조로 매핑할 수 있다. ## 제공 범위와 요금 - 차세대 AWS Resilience Hub는 Resilience Hub가 제공되는 AWS 상용 리전에서 정식 출시되었다. - 새로운 서비스 기반 요금 모델을 적용한다. - 서비스별 월 2회의 장애 모드 평가가 포함되며, 의존성 평가 기능은 선택적으로 사용할 수 있다. - 무료로 사용해 볼 수 있으며, 상세 요금은 AWS Resilience Hub 요금 페이지에서 확인해야 한다. 실무적으로는 먼저 핵심 비즈니스 서비스에 SLO·RTO·RPO를 정책으로 정의한 뒤, 의존성 탐색과 AI 장애 모드 평가를 실행하는 방식이 적절하다. 이후 조직 전체로 범위를 확대해 숨은 의존성과 반복되는 장애 패턴을 파악하고, 권고사항을 정기적인 복원력 개선 작업으로 연결하는 것이 효과적이다.

terraformgen-aiinfrastructure-as-codeamazon-eks+4

cloudflare2026년 4월 13일

클라우드플레어 전체를 위한 CLI 구축하기 (새 탭에서 열림)

Cloudflare는 100개 이상의 제품과 3,000여 개의 API 작업을 아우르는 거대한 생태계를 단일화하기 위해 Wrangler CLI를 전면 재구축하고 있습니다. 특히 AI 에이전트가 주요 사용자로 부상함에 따라, 모든 제품을 CLI, SDK, Terraform 등 다양한 인터페이스에서 일관되게 사용할 수 있도록 하는 것을 목표로 합니다. 이를 위해 새로운 TypeScript 기반 스키마 시스템을 도입하여 코드 생성 파이프라인을 자동화하고 개발 생산성을 높이고 있습니다. ### 통합 CLI 'cf'로의 진화 * Cloudflare의 방대한 API를 모두 수용하기 위해 차세대 Wrangler의 기술 프리뷰 버전인 `cf` 커맨드를 공개했습니다. * 기존 Wrangler가 일부 제품만 지원하던 한계를 극복하고, 인간과 AI 에이전트 모두에게 인체공학적인 출력을 제공하도록 설계되었습니다. * 현재 `npx cf` 또는 `npm install -g cf`를 통해 초기 버전을 미리 체험해 볼 수 있으며, 향후 기존 Wrangler 기능들과 통합될 예정입니다. ### TypeScript 기반의 새로운 스키마 엔진 * 기존 OpenAPI 스키마만으로는 로컬 개발 환경과 API 요청이 결합된 복잡한 CLI 명령어나 Workers 바인딩을 표현하는 데 한계가 있었습니다. * 이에 Cloudflare는 API, CLI 인자, 에이전트 기술(Agent Skills) 등을 포괄적으로 정의할 수 있는 새로운 TypeScript 기반 스키마 시스템을 구축했습니다. * 이 시스템은 일종의 '코드 생성기' 역할을 하며, 단일 정의로부터 OpenAPI 스키마, SDK, Terraform 제공자 등을 자동으로 생성하여 제품 업데이트 속도에 맞춘 신속한 동기화를 지원합니다. ### 일관성 확보와 컨텍스트 엔지니어링 * 수많은 제품군 사이에서 일관성 없는 명령어(예: `info`와 `get`의 혼용)는 특히 AI 에이전트의 오작동을 유발하므로, 스키마 계층에서 명칭 규칙을 강제합니다. * 모든 명령어에 `--force`, `--json`과 같은 표준 플래그를 적용하여 예측 가능성을 높였습니다. * 로컬 리소스와 원격 리소스 간의 동작 차이를 명확히 시그널링하여, 에이전트가 개발 중 리소스를 수정할 때 혼동하지 않도록 컨텍스트를 제공합니다. ### 로컬 익스플로러(Local Explorer) 도입 * 로컬 개발 환경에서 시뮬레이션되는 KV, D1, R2, Durable Objects 등의 리소스 내부를 쉽게 들여다볼 수 있는 'Local Explorer' 기능이 베타로 출시되었습니다. * Wrangler나 Cloudflare Vite 플러그인 실행 중 단축키 `e`를 눌러 활성화할 수 있으며, 기존처럼 `.wrangler/state` 디렉토리를 직접 분석할 필요가 없습니다. * 이를 통해 개발자와 에이전트는 로컬 데이터 상태를 즉각 확인하고, 테스트 레코드를 삽입하거나 스키마를 검증하는 등 상호작용 중심의 개발 사이클을 가질 수 있습니다. Cloudflare의 새로운 변화를 미리 경험해보고 싶다면 지금 바로 터미널에서 `npx cf`를 실행해 보세요. 또한 로컬 개발 중에는 `e` 키를 활용해 데이터 상태를 실시간으로 점검하며 개발 속도를 높일 수 있습니다.

terraformdatabase-designcloudflaretypescript+4

cloudflare2026년 3월 26일

연간 600시간을 절약한 쿠버네티스 한 줄 수정 (새 탭에서 열림)

쿠버네티스 환경에서 테라폼(Terraform) 운영 도구인 아틀란티스(Atlantis)의 재시작 시간을 30분에서 수 초 내외로 단축하여, 연간 600시간의 엔지니어링 대기 시간을 줄인 사례를 소개합니다. 문제의 원인은 수백만 개의 파일을 포함한 퍼시스턴트 볼륨(PV)을 마운트할 때 쿠버네티스가 기본적으로 수행하는 파일 권한 변경 작업이었습니다. 이를 해결하기 위해 `securityContext`에 단 한 줄의 설정을 추가함으로써 불필요한 재귀적 권한 검사를 방지하고 시스템 효율성을 극대화했습니다. ### 원인 불명의 느린 재시작 문제 아틀란티스는 테라폼 프로젝트의 상태를 유지하기 위해 퍼시스턴트 볼륨(PV)을 사용하는 싱글톤 스테이트풀셋(StatefulSet)으로 운영됩니다. 자격 증명 갱신이나 프로젝트 온보딩 시 재시작이 필수적인데, 이때마다 다음과 같은 심각한 지연이 발생했습니다. * **지속적인 지연:** 매 재시작 시 30분 동안 포드가 `Init:0/1` 상태에 머물며 인프라 변경 작업이 완전히 중단됨. * **운영 부담:** 매달 약 100회의 재시작이 발생하여 월 50시간, 연간 600시간의 엔지니어링 시간이 낭비되고 온콜 엔지니어에게 불필요한 알람이 전송됨. * **한계 도달:** 파일 시스템의 아이노드(Inode) 고갈로 볼륨 크기를 키워야 하는 상황에서, 재시작 지연 문제는 더욱 두드러짐. ### Kubelet 로그를 통한 기술적 병목 파악 일반적인 `kubectl events`로는 포드가 이미지를 풀링하기 전 단계에서 왜 멈춰 있는지 알 수 없었습니다. 팀은 노드 레벨의 `kubelet` 로그를 분석하여 구체적인 원인을 찾아냈습니다. * **로그 추적:** 로그상에서 볼륨 마운트 성공 메시지 이후 `context deadline exceeded` 오류가 반복적으로 발생하며 포드 생성이 지연됨을 확인. * **fsGroup 권한 설정:** 쿠버네티스는 볼륨을 마운트할 때 포드의 `fsGroup` 설정과 일치시키기 위해 볼륨 내의 모든 파일과 디렉토리에 대해 재귀적으로 `chown` 및 `chmod`를 실행함. * **파일 개수의 영향:** 아틀란티스 볼륨에 쌓인 수백만 개의 파일에 대해 매번 이 작업을 수행하면서 30분이라는 막대한 시간이 소요됨. ### 단 한 줄의 설정 변경으로 문제 해결 쿠버네티스 1.20 버전(GA 기준)부터 도입된 `fsGroupChangePolicy` 설정을 통해 이 문제를 간단히 해결할 수 있었습니다. * **기본값(Always):** 포드가 시작될 때마다 항상 모든 파일의 권한을 재귀적으로 변경함. * **해결책(OnRootMismatch):** 볼륨 루트 디렉토리의 권한이 `fsGroup`과 일치하지 않을 때만 재귀적 변경을 수행함. 이미 권한이 올바르게 설정되어 있다면 이 과정을 건너뜀. * **적용 코드:** ```yaml securityContext: fsGroup: 1000 fsGroupChangePolicy: "OnRootMismatch" ``` ### 실용적인 권장 사항 수백만 개의 작은 파일이 포함된 대규모 볼륨을 사용하는 애플리케이션(예: Prometheus, Atlantis, Jenkins 등)을 쿠버네티스에서 운영 중이라면, `fsGroupChangePolicy: "OnRootMismatch"` 설정을 기본적으로 적용하는 것이 좋습니다. 이를 통해 볼륨 마운트 시 발생하는 불필요한 디스크 I/O를 제거하고, 포드 시작 시간을 획기적으로 개선하여 인프라 운영의 가용성을 높일 수 있습니다.

terraformdatabase-designk8spersistent-storage+4

github2026년 3월 23일

깃허브, AI 기반 탐지 기능으로 애플리케이션 보안 범위 확장 (새 탭에서 열림)

GitHub는 AI 기반 보안 탐지를 도입해 CodeQL만으로는 충분히 다루기 어려운 언어와 프레임워크까지 애플리케이션 보안 범위를 확장한다. 이 기능은 풀 리퀘스트에서 취약점을 탐지하고 Copilot Autofix로 수정안까지 제안해, 코드 병합 전에 위험을 발견·해결하는 것을 목표로 한다. 공개 프리뷰는 2026년 2분기 초에 제공될 예정이다. ## CodeQL과 AI 탐지를 결합한 보안 검사 - CodeQL은 지원 언어에 대해 깊은 의미 분석을 제공하는 기존 정적 분석 엔진이다. - 현대 저장소에는 Shell/Bash 스크립트, Dockerfile, Terraform(HCL), PHP 등 다양한 생태계의 코드가 함께 포함된다. - GitHub는 CodeQL과 AI 기반 탐지를 결합한 하이브리드 모델로 이러한 영역까지 보안 검사 범위를 넓힌다. - AI 탐지는 전통적인 정적 분석으로 지원하기 어려운 코드에서 잠재적 취약점과 수정 제안을 찾아낸다. - 내부 테스트에서 30일 동안 17만 건 이상의 결과를 처리했으며, 개발자 긍정 피드백 비율은 80%를 넘었다. - 이 기능은 보안·코드 품질·코드 리뷰를 지원하는 GitHub의 에이전트형 탐지 플랫폼을 기반으로 한다. ## 풀 리퀘스트에서 취약점 조기 발견 - 풀 리퀘스트가 생성되면 GitHub Code Security가 변경 사항에 적합한 방식을 자동으로 선택해 분석한다. - 지원 언어에는 CodeQL 정적 분석을 사용한다. - 추가 생태계에는 AI 기반 보안 탐지를 적용한다. - 결과는 기존 코드 스캐닝 결과와 함께 풀 리퀘스트 안에 표시된다. - 탐지 대상에는 다음과 같은 문제가 포함된다. - 안전하지 않은 문자열 결합 방식의 SQL 쿼리나 명령어 - 취약한 암호화 알고리즘 - 민감한 리소스를 노출하는 인프라 구성 - 개발자는 별도 보안 도구로 이동하지 않고 코드 리뷰 과정에서 위험을 확인할 수 있다. ## Copilot Autofix를 통한 수정 자동화 - 취약점을 찾는 것뿐 아니라 빠르고 안전하게 수정하는 것도 보안 운영의 핵심이다. - Copilot Autofix는 탐지 결과를 바탕으로 개발자가 검토·테스트·적용할 수 있는 수정안을 제안한다. - 2025년 Autofix는 46만 건 이상의 보안 경고 해결에 사용됐다. - Autofix를 사용한 경우 평균 해결 시간은 0.66시간으로, 사용하지 않은 경우의 1.29시간보다 짧았다. - 탐지와 자동 수정 제안을 연결해 취약점 발견부터 해결까지의 시간을 줄인다. ## 병합 시점의 보안 정책 적용 - GitHub는 코드가 검토되고 승인되는 병합 지점에서 보안 결과를 통제할 수 있도록 한다. - 보안 탐지, 수정 제안, 정책 집행을 풀 리퀘스트에 통합하면 배포 이후가 아니라 병합 전에 위험을 차단할 수 있다. - 팀은 개발자가 기존 워크플로를 벗어나지 않으면서 보안 기준을 적용할 수 있다. - 장기적으로는 정적 분석의 정확성과 AI의 맥락 이해를 결합한 더 발전된 탐지 체계로 확장될 예정이다. 실무에서는 CodeQL이 지원하는 핵심 언어뿐 아니라 Shell, Docker, Terraform, PHP 등을 사용하는 저장소에도 해당 기능을 검토할 만하다. 다만 AI가 제안한 수정안은 반드시 개발자가 코드 의도와 테스트 결과를 확인한 뒤 병합하는 것이 좋다.

terraformdockerai-securitystatic-analysis+4

cloudflare2026년 3월 2일

백지 상태를 넘어: Cloudflare (새 탭에서 열림)

Cloudflare One은 강력한 SASE(Secure Access Service Edge) 플랫폼이지만, 모든 보안 기능을 최적으로 활용하기 위해서는 복잡한 설정 과정을 거쳐야 하는 '빈 캔버스'의 어려움이 존재합니다. 이를 해결하기 위해 Cloudflare는 전문가의 노하우를 코드화하여 자동 배포하는 '프로젝트 헬릭스(Project Helix)'를 도입했습니다. 이 프로젝트를 통해 고객은 수동 설정의 번거로움 없이 단 몇 분 만에 베스트 프랙티스가 적용된 제로 트러스트 환경을 구축할 수 있습니다. ### 초기 설정의 복잡성과 제로 트러스트 도입의 장벽 * Cloudflare One은 DNS 보호, 네트워크 보호, SWG 등 방대한 기능을 제공하지만, 초기 테넌트는 대개 운영 환경의 중단을 방지하기 위해 최소한의 설정만 되어 있는 '빈 상태'로 제공됩니다. * 고급 보안 기능인 TLS 검사, DLP(데이터 손실 방지), AV 스캔 등을 활성화하려면 수많은 스위치와 정책을 일일이 조정해야 하며, 이는 관리자에게 큰 부담이 됩니다. * 수동 설정 방식은 문서화가 어렵고 휴먼 에러의 가능성이 높으며, 특히 여러 시나리오를 동시에 적용해야 할 때 설정 간 충돌이나 누락이 발생하기 쉽습니다. ### 프로젝트 헬릭스: 전문가 노하우의 코드화와 자동화 * Cloudflare의 솔루션 엔지니어와 파트너들이 실제 구축 현장에서 겪은 베스트 프랙티스를 수집하여 이를 실행 가능한 코드(IaC) 형태로 변환했습니다. * 단순한 보안 정책 설정을 넘어, 신규 등록 도메인에 대한 원격 브라우저 격리(RBI), AI 애플리케이션 제어, 특정 SaaS 인스턴스만 허용하는 테넌트 제어(Tenant Control) 등 고도화된 설정을 포함합니다. * 사용자 경험 개선을 위해 Zoom과 같은 실시간 통신 앱의 트래픽 분리(Split Tunnel) 설정이나 공항·호텔의 캡티브 포털(Captive Portal) 접속을 위한 최적의 설정을 사전 구성으로 제공합니다. ### Terraform과 Cloudflare Workers를 활용한 기술적 구현 * **Terraform 기반 관리:** 확장 가능하고 유연한 Terraform 템플릿을 설계하여 복잡한 설정 파편과 정책을 일관되게 전달합니다. * **웹 기반 UI와 Workers:** Cloudflare Workers 및 Cloudflare Containers를 활용해 사용자가 기본 정보만 입력하면 테라폼 템플릿이 즉시 실행되는 웹 인터페이스를 구축했습니다. * **보안성 확보:** 실행 환경을 휘발성(Ephemeral)으로 구성하여 로그나 인증 토큰을 영구 저장하지 않으므로 보안 리스크를 최소화했습니다. * **효율성 극대화:** 수동으로 수 시간이 소요되던 구성 작업을 단 몇 분으로 단축하며, 클릭 한 번으로 권장 보안 정책 세트를 즉시 배포할 수 있습니다. Cloudflare One을 처음 도입하거나 환경을 재정비하려는 조직은 프로젝트 헬릭스를 통해 시행착오를 줄일 수 있습니다. 수동 설정 대신 자동화된 베스트 프랙티스 템플릿을 활용하여 보안 공백을 메우고 서비스 가동 시간을 빠르게 확보하는 것을 추천합니다.

terraformcloudflarecloudflare-workerszero-trust+4

cloudflare2026년 3월 2일

진정으로 프로그래밍 가능한 S (새 탭에서 열림)

Cloudflare는 단순한 설정 변경을 넘어 실시간 로직 주입이 가능한 진정한 의미의 프로그래밍 가능한 SASE(Secure Access Service Edge) 플랫폼을 지향합니다. Cloudflare One과 개발자 플랫폼(Workers)이 동일한 네트워크 인프라 위에서 기본적으로 통합되어 있어, 사용자는 대기 시간 없이 보안 이벤트를 가로채고 외부 컨텍스트를 결합하여 맞춤형 보안 결정을 내릴 수 있습니다. 이는 정적인 보안 정책의 한계를 극복하고 각 기업의 고유한 요구사항에 맞춘 유연한 보안 아키텍처 구축을 가능하게 합니다. **진정한 프로그래밍 가능성의 의미** - 업계에서 흔히 말하는 API 제공이나 Terraform 지원 같은 '기초적인 프로그래밍 가능성'을 넘어, 실시간으로 보안 이벤트를 가로채고 외부 데이터를 보충하여 즉각적인 조치를 취하는 능력을 의미합니다. - 예를 들어, 특정 앱 접속 시 사용자의 규정 준수 교육 이수 여부를 외부 시스템(LMS)에서 즉시 확인하여, 미이수자에게는 접속 차단 대신 교육 포털로 리다이렉트하는 동적인 정책 결정이 가능합니다. **SASE와 개발자 플랫폼의 결합** - Cloudflare One(SASE)과 Workers(개발자 플랫폼)는 동일한 전 세계 330개 이상의 도시 인프라 및 동일한 서버 자원 위에서 실행됩니다. - 별도의 외부 클라우드에서 자동화를 실행할 필요가 없어 불필요한 네트워크 왕복 지연(Latency)이 발생하지 않으며, 보안 정책 내에서 밀리초 단위로 커스텀 로직을 수행할 수 있습니다. - 웹 보호, 사용자 보안, 프라이빗 네트워크 보안 모두가 동일한 개발 도구와 기본 요소를 공유하므로 아키텍처의 일관성을 보장합니다. **확장된 보안 액션과 워크플로우** - 기존 보안 게이트웨이의 제한적인 옵션(허용, 차단, 격리 등)에서 벗어나, 사용자 정의 로직을 실행할 수 있는 '커스텀 액션' 기능을 제공합니다. - 사용자 ID 클레임에 기반한 동적 헤더 삽입, 외부 리스크 엔진의 실시간 판독 결과 반영, 근무 시간 및 위치에 따른 정교한 접근 제어 등을 구현할 수 있습니다. - '관리형 액션(템플릿)'을 통해 ITSM 통합이나 규정 준수 자동화를 쉽게 설정하거나, '커스텀 액션'을 통해 Cloudflare Worker를 직접 호출하여 정교한 코드를 실행할 수 있습니다. **실제 활용 사례: 자동화된 세션 관리** - 특정 고객은 정해진 시간 동안 활동이 없는 기기의 세션을 강제로 종료해야 하는 보안 요건을 Cloudflare Workers를 통해 해결하고 있습니다. - 'Scheduled Worker'가 주기적으로 실행되어 기기 API(Devices API)를 쿼리하고, 비활성 임계값을 초과한 기기의 등록을 자동으로 취소하여 사용자가 ID 공급자를 통해 다시 인증하도록 강제합니다. - 이는 표준 기능으로 제공되지 않는 복잡한 보안 요구사항도 프로그래밍을 통해 즉시 해결할 수 있음을 보여줍니다. 보안 요구사항이 복잡해질수록 단순한 설정 중심의 솔루션은 한계에 부딪힙니다. Cloudflare One의 프로그래밍 가능성을 활용하여 기업 고유의 비즈니스 로직을 보안 스택에 직접 통합하면, 성능 저하 없이도 가장 강력하고 유연한 제로 트러스트 환경을 구축할 수 있습니다.

terraformcloudflare-workerszero-trustnetwork-security+4

figma2024년 8월 7일

12개월 이내에 K8 (새 탭에서 열림)

Figma는 ECS에서 Kubernetes(EKS)로 이전해 플랫폼의 기능과 확장성을 높이기로 결정했고, 핵심 서비스 대부분을 12개월 이내에 안전하게 옮겼습니다. ECS의 StatefulSet·Helm 지원 부족과 운영상의 불편, CNCF 생태계 활용 한계가 주요 전환 이유였습니다. 특히 Figma는 수천 개의 마이크로서비스를 운영하는 구조가 아니었기 때문에 대규모 마이그레이션의 범위를 현실적으로 통제할 수 있었습니다. ## 기존 Figma의 컴퓨트 플랫폼 - 2023년 초 Figma의 모든 서비스는 이미 컨테이너화되어 있었고, AWS ECS에서 실행되고 있었습니다. - ECS는 컨테이너 워크로드를 빠르게 운영하기에 좋은 플랫폼이었지만, 장기적으로 필요한 기능을 확장하기에는 한계가 있었습니다. - Figma는 모든 기능을 별도 마이크로서비스로 분리하지 않았습니다. - 성능이나 격리가 필요한 경우에만 새 서비스를 만들었습니다. - 대부분의 제품 기능은 기존 핵심 서비스에 로직을 추가하는 방식으로 구현했습니다. - 따라서 Kubernetes 전환 대상 서비스 수가 수천 개에 달하지 않았고, 이전 작업의 범위를 관리할 수 있었습니다. ## ECS에서 겪은 기능적 한계 - **StatefulSet 부재** - ECS에는 Kubernetes의 StatefulSet처럼 파드에 지속적인 식별자와 네트워크 정체성을 제공하는 기능이 없었습니다. - Figma는 ECS에서 etcd 클러스터를 운영하기 위해 컨테이너 시작 시 클러스터 멤버십을 동적으로 갱신하는 커스텀 코드를 작성했습니다. - 이 방식은 취약하고 유지보수가 어려웠습니다. - Kubernetes에서는 StatefulSet을 이용해 etcd 인스턴스의 안정적인 네트워크 정체성을 제공할 수 있습니다. - **Helm 차트 활용 부족** - Temporal 같은 오픈소스 소프트웨어를 도입하려면 ECS 환경에 맞게 각 서비스를 Terraform으로 직접 포팅해야 했습니다. - Kubernetes에서는 Helm 차트를 통해 관련 서비스와 설정을 표준화된 방식으로 설치하고 관리할 수 있습니다. - **노드 장애 대응의 불편** - ECS on EC2에서 문제가 있는 EC2 인스턴스 하나를 우아하게 종료하는 작업이 복잡했습니다. - EKS에서는 노드를 cordon 처리한 뒤 API 서버가 파드를 다른 노드로 이동시키도록 할 수 있습니다. - 이 과정에서 파드의 정상 종료 절차도 준수할 수 있습니다. ## CNCF 생태계 활용 - ECS를 계속 사용하면 Kubernetes와 함께 발전한 CNCF 오픈소스 생태계를 충분히 활용하기 어려웠습니다. - Figma가 특히 관심을 가진 영역은 자동 확장이었습니다. - 당시 컨테이너 서비스에 자동 확장을 적용하지 않아, 야간이나 주말처럼 트래픽이 낮은 시간에도 최대 부하를 감당할 자원을 미리 provision해야 했습니다. - 그 결과 불필요한 인프라 비용이 발생했습니다. - Kubernetes 생태계의 KEDA는 다음과 같은 기준으로 자동 확장을 지원합니다. - CPU 사용률 - AWS SQS 큐 길이 - Datadog의 커스텀 메트릭 - ECS에도 일부 자동 확장 기능은 있지만, Figma는 Kubernetes 생태계의 성숙한 오픈소스 도구를 활용하는 편이 장기적으로 유리하다고 판단했습니다. ## 서비스 메시와 트래픽 처리 - Figma는 서비스 간 트래픽을 AWS ALB와 NLB를 통해 라우팅하고 있었습니다. - NLB에서 새 대상을 등록하거나 기존 대상을 제거하는 데 몇 분이 걸려 긴급 배포와 장애 복구가 느려지는 문제가 있었습니다. - Figma는 이미 주요 서비스 앞에 독립적인 Envoy 프록시 클러스터를 운영하고 있었습니다. - 장애 상황에서 부하를 줄이는 커스텀 필터를 적용하기 위한 목적이었습니다. - 장기적으로는 전체 서비스에 Envoy 기반 서비스 메시를 도입할 가능성이 있다고 보았습니다. - EKS에서는 Istio 같은 서비스 메시 솔루션을 활용할 수 있지만, ECS에서는 이런 생태계를 직접 구축하거나 많은 부분을 커스텀 구현해야 했습니다. ## 전환을 결정한 기준 - 단순히 새로운 기술을 도입하는 것이 아니라, 다음 세 가지를 종합해 판단했습니다. - 현재 ECS에서 발생하는 운영 및 개발 비용 - 자동 확장과 서비스 메시 등 미래 요구사항 - 마이그레이션을 합리적인 기간 안에 완료할 수 있는지 여부 - Figma는 대규모 작업이 플랫폼을 실제로 개선하고, 사용자에게 다운타임을 유발하지 않으면서 완료될 수 있어야 한다는 원칙을 강조했습니다. - 결론적으로 Kubernetes는 StatefulSet, Helm, 자동 확장, 서비스 메시 등 Figma가 필요로 하던 기능을 더 자연스럽게 제공하는 기반으로 평가되었습니다. Figma와 유사하게 컨테이너 기반 서비스를 운영하면서 ECS의 기능적 한계가 커지고 있다면 Kubernetes 전환을 검토할 수 있습니다. 다만 서비스 수와 운영 복잡도를 먼저 평가하고, 자동 확장·상태 저장 워크로드·트래픽 관리처럼 실제로 필요한 기능을 기준으로 이전의 효과를 판단하는 것이 바람직합니다.

terraformk8scontainershelm+4

figma2021년 8월 11일

피그마 내부 이야기: 내부 웹 (새 탭에서 열림)

Figma는 내부 웹 애플리케이션을 안전하게 공개하기 위해 AWS Application Load Balancer(ALB), Cognito, Okta, SAML, Lambda, Terraform을 조합한 중앙화된 접근 제어 시스템을 구축했다. 이 시스템은 사내 네트워크를 신뢰하지 않는 제로 트러스트 원칙을 따르면서도, 직원에게 빠르고 일관된 인증 경험을 제공하는 것을 목표로 한다. 또한 권한 관리를 중앙화하고 인프라 구성을 코드로 자동화해 보안팀의 운영 부담을 줄였다. ## 내부 웹 앱 보안의 요구사항 - 배포, 고객 지원 등 내부 웹 도구는 직원 업무에 필수적이지만 사용자 데이터에 접근할 수 있어 높은 보안 수준이 필요하다. - 공격자는 사용자 데이터를 노리기 위해 관리용 백엔드와 내부 애플리케이션을 주요 공격 대상으로 삼는다. - 시스템 설계 시 다음 요구사항을 우선했다. - 빠르고 안정적이며 사용하기 쉬운 인증 - 네트워크 위치만으로 신뢰하지 않는 제로 트러스트 접근 - WebAuthn 같은 최신 인증 기술 활용 - IT·보안팀이 관리하는 중앙화된 권한 부여 - 소규모 보안팀의 운영 부담 최소화 ## 사용한 핵심 기술 - **SAML** - 서비스 간 사용자 신원 정보를 전달하는 인증 프로토콜이다. - 사용자 신원뿐 아니라 그룹과 역할 정보도 assertion에 포함할 수 있다. - Okta와 AWS Cognito를 연결하는 기반으로 사용된다. - **AWS Application Load Balancer** - HTTP/HTTPS 요청을 받아 규칙에 따라 내부 인프라로 전달하는 관리형 리버스 프록시다. - 애플리케이션 앞단에서 사용자 인증을 수행할 수 있다. - **AWS Cognito** - 사용자 인증 및 관리 API를 제공한다. - SAML과 같은 외부 연합 로그인 기술과 통합할 수 있다. - **AWS Lambda** - 특정 이벤트나 조건에 따라 코드를 실행하는 서버리스 컴퓨팅 구성요소다. - **Terraform** - AWS와 Okta 설정을 코드로 관리한다. - 인증 인프라를 검토·자동화·재사용할 수 있게 해준다. ## ALB와 Okta를 이용한 인증 구조 - Figma는 클라우드 인프라에 AWS를, 직원 인증·권한 관리에 Okta를 사용한다. - ALB는 일반적으로 OIDC 인증을 구성할 수 있지만, Okta의 OIDC 지원 비용 문제로 다른 방식을 검토했다. - 대안으로 **ALB + Cognito 사용자 풀 + Okta SAML** 조합을 사용했다. - Cognito가 SAML 기반 Okta 로그인과 ALB 사이를 연결하므로, ALB가 인증된 트래픽만 내부 애플리케이션으로 전달할 수 있다. - 각 내부 앱마다 Okta에 SAML 애플리케이션을 만들고, 해당 앱과 연결된 Cognito Identity Provider를 구성한다. ## Terraform을 통한 표준화와 자동화 - Figma는 ALB와 Cognito를 올바른 설정으로 생성할 수 있도록 Terraform 모듈을 직접 만들었다. - 인프라 엔지니어는 모듈을 사용해 Okta 인증이 적용된 ALB를 빠르게 배포할 수 있다. - 인증 구성을 수작업으로 반복하지 않고 코드로 관리하므로 다음 효과가 있다. - 설정의 일관성 확보 - 변경 사항 검토 가능 - 여러 내부 앱에 동일한 보안 패턴 재사용 - 운영 및 유지보수 부담 감소 ## Cognito 사용자 풀 구성 - Cognito User Pool에서는 일반 사용자의 직접 회원가입을 허용하지 않는다. - 사용자는 Okta에서 인증되어야 하며, Cognito는 Okta용 SAML Identity Provider와 연결된다. - `email`과 `profile` 같은 속성 매핑을 설정해 Okta의 사용자 정보가 인증 과정에서 전달되도록 한다. - 결과적으로 내부 앱은 각자 복잡한 인증 로직을 구현하지 않고도, ALB 앞단에서 중앙화된 인증을 적용할 수 있다. ## 확장 방향 - 글에서는 기본 인증 구조 외에도 다음 기능 확장을 다룬다. - Okta Groups를 활용한 세밀한 권한 제어 - 엔지니어를 위한 CLI 인증 - 외부 게스트의 안전한 접근 허용 - 공통 인증 계층을 기반으로 웹 브라우저뿐 아니라 명령줄 도구와 제한된 외부 사용자 접근까지 동일한 보안 원칙으로 확장하려는 접근이다. 실무에서는 내부 앱마다 인증 기능을 따로 구현하기보다, ALB 같은 공통 진입점과 중앙 IdP, Terraform 모듈을 결합하는 방식이 효과적이다. 특히 네트워크 위치를 신뢰 기준으로 삼지 않고, 강력한 사용자 인증과 중앙화된 그룹·권한 관리를 적용하는 것이 중요하다.

terraformzero-trustaws-lambdasaml+4

datadog2017년 8월 23일

Vagrant와 Terraform을 통한 (새 탭에서 열림)

제공된 내용에는 본문이 아니라 Datadog 웹사이트의 제품·기능导航 목록과 “Vagrant와 Terraform으로 지원 확장” 링크만 포함되어 있습니다. 따라서 글의 핵심 주장, 기술적 구현 방식, 결론을 정확히 요약할 수 없습니다. ### 확인 가능한 정보 - 링크 제목: **Vagrant와 Terraform을 활용한 지원 확장** - 관련 제품 범주: - 인프라 모니터링 - 애플리케이션 성능 모니터링(APM) - 로그 관리 - 보안 - CI/CD 및 서비스 관리 - AI 기반 관측성 - 별도로 Datadog이 Gartner의 Observability Platforms 매직 쿼드런트에서 Leader로 선정되었다는 홍보 문구가 포함되어 있습니다. 본문 원문이나 링크의 실제 글 내용을 제공해 주시면 요청하신 형식에 맞춰 정확하게 요약하겠습니다.

terraformk8sdatadogobservability+2

datadog2017년 8월 23일

Vagrant와 Terraform으로 지원 확장 (새 탭에서 열림)

Datadog의 솔루션 팀은 고객이 사용하는 다양한 기술 스택과 복잡한 인프라 환경에서 발생하는 문제를 정확히 재현하기 위해 Vagrant와 Terraform을 활용한 자동화된 샌드박스 시스템을 구축했습니다. 인프라 구축 과정을 코드화하여 팀 전체가 공유함으로써, 개별 엔지니어가 생소한 기술을 매번 처음부터 학습하고 설치해야 하는 비효율을 제거하고 문제 해결 속도를 획기적으로 높였습니다. 결과적으로 로컬 가상 머신과 클라우드 인스턴스를 자유롭게 오가는 유연한 디버깅 환경을 통해 팀 간 협업과 고객 지원의 품질을 극대화할 수 있었습니다. **Vagrant 프로비저닝을 통한 환경 구축 자동화** * 고객의 특정 OS, 커널 버전, 복잡한 통합 도구(Kafka, MS SQL, RabbitMQ 등)를 수동으로 설치하는 것은 시간이 많이 걸리고 오류가 발생하기 쉽습니다. * Vagrant의 '프로비저닝(Provisioning)' 기능을 활용하여, 인프라 설치 및 설정에 필요한 모든 명령어를 `setup.sh`와 같은 쉘 스크립트에 담아 자동화했습니다. * 한 번 작성된 프로비저닝 스크립트는 팀 공용 GitHub 저장소에 저장되어, 다른 팀원들이 동일한 이슈를 처리할 때 `vagrant up` 명령어 하나만으로 즉시 동일한 환경을 갖출 수 있게 합니다. **샌드박스 저장소의 구조화 및 유연성 확보** * 저장소는 운영체제와 배포판, 서비스 이름에 따라 계층적으로 디렉토리를 나누어 관리하며, 각 디렉토리에는 `Vagrantfile`, `setup.sh`, 그리고 설정 파일 등이 담긴 `/data` 폴더를 포함합니다. * 엔지니어 개인별로 달라야 하는 설정(호스트 이름, API 키, 태그 등)은 `.sandbox.conf.sh`라는 로컬 설정 파일에 분리하여 관리함으로써 스크립트의 범용성을 유지합니다. * 이를 통해 새로운 환경이 필요할 때 기존 템플릿을 복사하여 빠르게 변형할 수 있으며, 팀 내 기술적 노하우가 코드를 통해 자연스럽게 축적됩니다. **Terraform을 이용한 클라우드 확장 및 협업** * 로컬 가상 머신 사용 시 발생하는 RAM 자원 부족 문제를 해결하고 팀원 간 환경을 쉽게 공유하기 위해 Terraform을 도입하여 AWS EC2 인스턴스를 활용합니다. * Vagrant에서 사용하던 `setup.sh`와 `/data` 파일을 그대로 재사용하면서, 인스턴스 생성을 위한 `.tf` 파일만 추가하여 로컬과 클라우드 환경 간의 일관성을 유지합니다. * 클라우드 기반 샌드박스를 활용하면 여러 시간대의 팀원들이 동일한 원격 환경에 접속해 조사를 이어갈 수 있으며, 고객과의 실시간 상담 중에도 미리 준비된 환경을 즉시 배포하여 대응할 수 있습니다. **실용적인 결론** 반복적인 환경 구축이 필요한 기술 지원이나 개발 팀이라면 인프라를 코드로 관리(IaC)하는 것이 필수적입니다. Vagrant로 로컬에서 가볍게 시작하되, 동일한 프로비저닝 스크립트를 Terraform과 공유할 수 있도록 설계하면 로컬의 편의성과 클라우드의 협업 능력을 동시에 잡을 수 있습니다. 특히 `setup.sh`와 같은 범용 스크립트를 중심에 두면 도구가 바뀌어도 재사용성을 높일 수 있습니다.

terraformpostgresqldockervirtual-machines+4

datadog2017년 8월 15일

ChatOps를 통한 클라우드 보안 가시성 향상 (새 탭에서 열림)

Datadog은 대규모 AWS 환경에서 발생하는 막대한 API 호출을 효율적으로 감시하기 위해 서버리스 기반의 보안 모니터링 및 알림 파이프라인을 구축했습니다. 이 시스템은 모든 API 활동을 실시간으로 분석하여 잠재적 위협과 설정 오류를 탐지하며, Slack과 Duo를 활용한 사용자 직접 확인 절차를 통해 보안팀의 운영 부담을 최소화합니다. 결과적으로 적은 인력으로도 수많은 계정의 보안 상태를 높은 가용성으로 유지할 수 있는 중앙 집중형 구조를 완성했습니다. ### 데이터 필터링과 위험도 분류 * **로그 중심의 선택적 집중:** 모든 API 호출을 실시간 감시하는 것은 불가능하므로, 보안상 의미 있는 API를 식별하여 로그(Log), 알림(Notify), 경고(Alert)의 세 단계로 분류했습니다. * **단계별 대응 체계:** 단순 변경(CreateGroup 등)은 추후 조사를 위해 로그로 남기고, 권한 변경(CreateUser 등)은 실행한 엔지니어에게 직접 확인을 요청하며, 치명적인 설정 오류(보안 그룹을 0.0.0.0/0으로 개방 등)는 즉시 보안팀에 경고를 보냅니다. * **엔지니어 직접 검증:** 알림 단계에서는 해당 API를 호출한 엔지니어에게 Slack 메시지를 보내 본인이 수행한 작업인지 확인하게 함으로써, 계정 탈취 여부를 확인하는 동시에 보안팀의 오탐(False-positive) 분석 업무를 획기적으로 줄였습니다. ### 중앙 집중형 아키텍처 및 파이프라인 * **교차 계정 데이터 통합:** 15개 이상의 AWS 계정에서 발생하는 이벤트를 하나의 중앙 보안 계정으로 수집하기 위해 CloudWatch 이벤트 규칙과 SNS, SQS를 조합했습니다. * **지연 및 비용 최적화:** CloudWatch가 SQS로 직접 데이터를 보내지 못하는 제약을 SNS를 통해 해결했으며, Lambda를 2분마다 트리거하여 SQS 큐의 데이터를 처리함으로써 실시간성과 알림 피로도 사이의 균형을 맞췄습니다. * **인프라 코드화:** Terraform을 사용하여 모든 AWS 계정에 동일한 데이터 수집 설정을 신속하고 일관되게 배포할 수 있는 구조를 갖췄습니다. ### 보안 오케스트레이션과 자동화 로직 * **워크플로우 자동화:** 보안 오케스트레이션 플랫폼인 Komand(현 Rapid7 InsightConnect)를 도입하여 복잡한 결정 트리와 브랜칭 로직을 구현했습니다. * **상세 분석 플러그인:** 커스텀 플러그인을 통해 호출자 identity, API 파라미터 내용, 요청 시간 등을 정밀하게 파싱하여 경고 여부를 결정합니다. * **다중 인증(MFA) 연동:** 엔지니어가 Slack 알림에서 본인의 작업임을 승인하면 Duo Push를 통해 2차 인증을 거치게 되며, 응답이 없거나 본인 작업이 아니라고 응답할 경우에만 보안팀에 비상 호출(PagerDuty)이 전달됩니다. * **가시성 확보:** 모든 워크플로우 실행 결과는 Elasticsearch로 전송되어 대시보드화되며, 이를 통해 보안 이벤트 추세와 시스템 효율성을 측정합니다. 대규모 클라우드 환경을 운영하는 조직이라면 모든 이벤트를 보안팀이 직접 처리하려 하기보다, 이처럼 자동화된 오케스트레이션과 사용자 참여형 검증 시스템을 구축하여 '확장 가능한 보안(Scalable Security)'을 실현하는 것이 권장됩니다.

terraformawsslacksecurity-monitoring+4