ARI

Kubernetes 환경에서는 Database Password, API Key, Token, Certificate 같은 민감한 정보를 관리해야 합니다. Kubernetes는 이러한 데이터를 Secret Resource를 통해 저장합니다. 하지만 기본 Kubernetes Secret은 단순히 Base64 Encoding 형태로 저장됩니다. 즉: Secret 생성 ↓ Base64 Encoding ↓ etcd 저장 Base64는 암호화가 아니라 단순한 인코딩 방식입니다. 따라서 Enterprise 환경에서는 추가적인 데이터 보호 방식이 필요합니다. 이를 해결하기 위해 … 더 읽기

현대 Kubernetes 환경에서는 Application 자체뿐만 아니라 Application이 만들어지고 배포되는 전체 과정의 보안이 중요합니다. 개발자가 작성한 Code부터 Container Image 생성, Registry 저장, Kubernetes 배포까지 여러 단계에서 보안 위협이 발생할 수 있습니다. 예: 개발자 Code 작성 ↓ Docker Image Build ↓ Image Registry 저장 ↓ Kubernetes Deploy ↓ 악성 코드 포함 Image 실행 위험 이를 해결하기 위해 … 더 읽기

Docker를 사용하다 보면 실행 중인 Container에서 Package를 설치하거나 설정 파일을 변경한 뒤 현재 상태를 그대로 Docker Image로 저장하고 싶은 경우가 있습니다. 이때 사용할 수 있는 명령어가 docker commit입니다. 하지만 docker commit을 처음 사용할 때 자주 발생하는 문제가 있습니다. Container 안에서 분명히 파일이나 Database를 변경했는데 새로운 Image를 생성한 후 다시 Container를 실행하면 일부 변경사항이 사라지는 경우입니다. … 더 읽기

Enterprise Kubernetes 환경에서는 단순히 Application이 정상 실행되는 것만으로 충분하지 않습니다. 기업 환경에서는 보안 기준 준수, 감사 기록 관리, 규정 요구사항 충족이 필요합니다. 예: Kubernetes Cluster 운영 ↓ 보안 설정 확인 ↓ 감사 기준 검사 ↓ 취약 설정 발견 ↓ 개선 적용 이를 위해 Kubernetes Compliance Architecture를 구성합니다. Compliance는 Kubernetes 환경이 정해진 보안 기준과 운영 규칙을 … 더 읽기

Kubernetes 환경이 Enterprise 규모로 성장하면 단순히 사용자의 권한을 제한하는 것만으로는 충분하지 않습니다. 수많은 개발자가 Application을 배포하고 여러 팀이 하나의 Cluster를 공유하는 환경에서는 일관된 보안 정책과 운영 기준이 필요합니다. 예: 개발자 ↓ Privileged Container 배포 시도 ↓ 보안 정책 검사 ↓ 위험한 설정 차단 이처럼 Kubernetes에서는 Resource가 생성되기 전에 정책을 검사하고 관리하는 Policy Management 구조가 필요합니다. … 더 읽기

현대 Kubernetes 환경에서는 Network 경계만으로 보안을 유지하기 어렵습니다. Cloud Native Architecture에서는 Application이 여러 Cluster와 Cloud 환경에 분산되고, Microservice 간 통신이 증가하면서 기존 방식의 보안 한계가 발생합니다. 기존 보안 방식: 외부 접근 차단 ↓ 내부 Network 신뢰 ↓ 서비스 운영 하지만 내부 사용자의 계정 탈취나 권한 오용이 발생하면 내부에서도 보안 위협이 발생할 수 있습니다. 이를 해결하기 … 더 읽기

기업의 서버와 서비스가 기존의 내부 네트워크 중심에서 Cloud 환경으로 이동하면서 보안 구조 역시 크게 변화하고 있습니다. 과거에는 회사 내부 네트워크와 외부 인터넷을 구분하고 내부에 접속한 사용자나 장비를 어느 정도 신뢰하는 방식이 일반적이었습니다. 하지만 AWS, Google Cloud, Kubernetes, SaaS 등 다양한 환경이 연결되면서 단순히 내부와 외부를 구분하는 것만으로는 충분한 보안 구조를 만들기 어려워졌습니다. 이러한 환경에서 중요하게 … 더 읽기

글로벌 서비스 환경에서는 하나의 Kubernetes Cluster만으로 모든 요구사항을 만족하기 어렵습니다. 사용자가 여러 지역에 존재하거나 서비스 가용성을 높여야 하는 경우 여러 Kubernetes Cluster를 운영하게 됩니다. 예: 한국 Region ↓ Kubernetes Cluster 미국 Region ↓ Kubernetes Cluster 유럽 Region ↓ Kubernetes Cluster 하지만 여러 Cluster를 운영하면 다음과 같은 관리 문제가 발생합니다. 이를 해결하기 위해 Kubernetes에서는 Cluster Federation과 … 더 읽기

Kubernetes 환경에서 외부 사용자가 Application에 접근하기 위해서는 Traffic 관리 계층이 필요합니다. 기존 Kubernetes에서는 Ingress Controller를 사용하여 HTTP와 HTTPS Traffic을 관리했습니다. 하지만 Microservice 환경과 Cloud Native Architecture가 발전하면서 더 복잡한 Traffic 제어 요구사항이 증가했습니다. 예: 사용자 요청 ↓ Ingress Controller ↓ Service ↓ Application 기존 방식은 단순한 Routing에는 적합하지만, 대규모 환경에서는 다음과 같은 한계가 발생합니다. 이를 … 더 읽기

AWS 환경에서 서버와 애플리케이션을 운영하다 보면 EC2, API Gateway, Lambda, Step Functions, IAM 등 다양한 리소스를 생성하고 관리하게 됩니다. 처음에는 AWS Management Console에서 직접 리소스를 생성해도 큰 문제가 없지만, 관리해야 하는 리소스가 많아지면 어떤 설정이 언제 변경되었는지 확인하기 어려워집니다. 이러한 문제를 해결하기 위해 AWS에서는 CloudFormation을 제공합니다. CloudFormation을 이해하면 AWS 리소스가 갑자기 변경되거나 삭제되는 것처럼 보이는 … 더 읽기