Primes's Infra Tech

Storage in Docker 쿠버네티스의 스토리지 구조를 알아보기 전, 그 기초를 이루는 도커의 스토리지 구조에 대해 먼저 학습한다. 도커의 스토리지는 2가지로 나뉜다. Storage Drivers / Volume Drivers 강의에서는 Storage Driver를 다룬다. docker를 처음 설치하면 설치된 경로는 /var/lib/docker 에 저장된다. 해당 경로 하위 폴더들에 도커의 모든 데이터가 저장된다. 도커는 이미지를 구축할 때, Layered architecture로 구축한다. dockerfile 내 각 명령어들은 docker이미지에 새 레이어를 생성한다. (FROM Ubuntu = Layer 1) 각 레이어들은 이전 레이어에서의 변경 사항을 저장해나간다. 이러한 구조로 인해, 비슷한..

네트워크 기본, 기초 부분은 알고있으니 지나간다. 네트워크 트래픽은 인, 아웃 트래픽에 대해 규칙을 설정해둬야 제대로 흐를 수 있음을 인지하면 된다. 쿠버네티스의 네트워크 부분의 보안을 알기 위해서 위 사항을 기억해두자. 쿠버네티스의 네트워킹의 전제조건 중 하나는 "어떤 솔루션을 구현하더라도 파드가 서로 통신할 수 있어야 함" 이다. 경로 설정과 같은 추가적인 설정 없이 통신이 가능해야 한다. 모든 파드는 IP, 파드 이름, 서비스 이름을 가지고 클러스터 내에서 노드에 관계없이 파드간에 통신에 애로사항이 없어야 한다. 하지만 위와 같은 상황을 예로 들면, 웹서버와 DB서버가 직접적으로 통신은 가능하지만 보안상의 요구로 인해 직접 통신은 불가하게 구성하길 원하면 어떻게 해야 하는지 알아본다. 이러한 경우에..

Security in Docker 쿠버네티스의 보안에 대해 알기 전, Docker의 보안에 대해 이해하고 넘어간다. 컨테이너는 호스트 OS와 격리되어 운영되는 구조가 아니다. 컨테이너는 OS에서 namespace를 이용해 격리된다. 컨테이너와 호스트는 같은 커널을 공유한다. 즉, 컨테이너에서 실행되는 프로세스는 호스트에서 실행되지만 고유의 namespace 공간에서 실행된다. 네임스페이스 내 리소스는 다른 네임스페이스에서는 볼 수 없다. ps aux 명령어를 통해 도커 컨테이너 목록을 확인할 수 있다. 여기서 PID 도 확인이 가능한데, 네임스페이스 내에서는 다른 네임스페이스의 프로세스를 확인할 수 없어 PID가 1로 보인다. 하지만 호스트에서 ps aux 명령어를 사용하면 모든 namespace의 컨테..

쿠버네티스의 계정은 두 유형으로 나뉜다. 사용자가 사용하는 사용자 계정과, 컴퓨터가 사용하는 서비스 계정이 있다. 사용자 계정 : 관리 작업을 수행하기 위해 클러스터에 액세스하는 관리자, 프로그램 배포를 위해 클러스터에 액세스하는 개발자가 사용 서비스 계정 : 프로그램이 k8s 클러스터와 상호작용 시 사용하는 계정 서비스 계정의 예로, 프로메테우스와 같은 모니터링 툴과 젠킨스와 같은 자동화 빌드 툴들이 서비스 계정을 활용한다. 어플리케이션이 쿠버네티스 API를 사용하려면 인증이 필요하다. 이 때 요구되어지는 것이 서비스 계정이다. kubectl create serviceaccount dashboard-sa 위 명령어로 서비스 계정 생성이 가능하다. 계정이 생성되면 토큰도 자동으로 생성된다. 해당 토큰은 ..

이제까지 쿠버네티스 내 인증에 대한 부분을 계속 학습하였다. 이제는 클러스터 내에서 인증을 어떻게 활용하는지 알아보자. 클러스터 관리자는 모든 종류의 작업을 수행할 수 있다. 배포 또는 파드 추가 및 삭제, 노드 관리 등의 작업을 모두 할 수 있다. 하지만 다른 관리자들도 모두 클러스터에서 위와같은 작업을 전부 수행할 수 있어서는 안된다. 각 사용자는 업무에 맞는 권한만을 가져야 한다. 각 관리자의 계정마다 접근 권한을 조정하여 제어할 수 있도록 해야한다. 쿠버네티스는 4가지의 인증 메커니즘을 지원한다. Node Authorizer / ABAC (Attribute Based Access Control) / RBAC(Role Based Access Control) / Webhook 하나씩 알아보자. 1. ..

앞서 학습을 하면서, 클러스터 내에서 어떤 작업을 하든 모든 명령은 kube-apiserver를 타고 간다는 것을 알았다. 쿠버네티스 API는 사용 목적에 따라 그룹화된다. /version : 클러스터 버전 확인 /metrics, healthz : 클러스터 상태 모니터링 /logs : 다른 로그와 통합할 때 사용 위 4 그룹을 제외하고, /api, /apis가 중요하기 때문에 별개로 학습한다. 해당 api는 core 그룹과 named 그룹 2가지로 분류된다. 여기서 핵심적인 기능들은 core 그룹에 속한다. namespaces, pods, nodes 등 중요 리소스들이 여기에 들어간다. named 그룹은 좀더 조직화 되어있고, 새로 추가되는 기능들은 named 그룹에 속하게 된다. API Groups >..

앞서 인증 과정을 학습하면서, 클러스터 내에서 인증서 파일이 어떻게 활용되는지 확인하였다. 클러스터 내 접속을 하기 위해서는 매번 인증이 유효한지와 같은 체크를 kubectl 명령어를 사용하여 진행해야 하는데, 이를 매번 입력하는 것은 어려운 일이다. 따라서 kubeconfig 이라는 구성 파일을 통해 명령을 모아 명시해둔다. 기본적으로 kubectl 도구는 아래 경로 내의 config 파일을 찾는다. $HOME/.kube/config 따라서 해당 경로에 kubeconfig 파일이 있기 때문에 kubectl 명령에 대해 별도로 옵션을 지정하지 않아도 되었었다. kubeconfig 파일은 3가지 영역으로 나뉜다. Clusters / Contexts / Users 세 영역으로 나뉜다. Clusters : 액..

이제까지 클러스터 관리자로써, 클러스터 내 통신 시 TLS 보안이 어떻게 적용되고 이 때 인증 과정이 어떻게 이루어지는지 확인하였다. 이 인증서는 CA(Certificate Authority) 기관이 보증한다는 것을 학습하였고, CA 서버가 인증서를 발급해줌을 확인하였다. 또한 앞서 관리자는 클러스터에 접속하기 위해서는 인증서와 개인키가 필요하다는 것을 학습했다. 그렇다면, 새로운 관리자가 클러스터에 접속하기 위해서는 어떻게 해야 하는가? 새로운 인증서와 키 쌍을 발급해서 줘야한다. 새로운 관리자는 개인키를 생성하여 인증서 서명 요청을 작성하여 기존의 관리자에게 보낸다. 기존 관리자는 인증서 서명 요청을 CA 서버로 가져가 CA 서버의 개인키와 루트 인증서를 통해 서명하고, 새로운 관리자에게 다시 돌려보..

앞서 쿠버네티스간 리소스의 통신은 TLS 보안이 적용되어 있음을 알아보았다. 그렇다면 TLS 보안은 어떻게 이루어지는가? TLS 는 대칭키, 공개키 암호화 방식을 복합적으로 사용한다. 공개키 방식은 한 쌍의 개인키, 공개키를 사용하며 공개키로 암호화하고 개인키로 복호화하는 방식이다. 대칭키 방식은 암, 복호화에 같은 키를 사용한다. 암호화된 통신을 진행할 때, 대칭키만 이용해서 암호화한다면 공격자가 키만 얻어낸다면 복호화를 쉽게 진행할 수 있다. 따라서 공개키 암호화 방식을 섞어 사용한다. 공개키 암호화 방식을 사용하여 대칭키를 상대에게 전달한다. 과정은 아래와 같다. openssl genrsa -out my-bank.key 1024 openssl rsa -in my-bank.key -pubout > m..

쿠버네티스는 여러 애플리케이션을 통합 관리할 수 있는 솔루션이기 때문에, 보안적 요소가 매우 중요해진다. 클러스터를 생성하는 호스트의 보안부터 중요하게 다루어야 한다. 비밀번호를 입력하여 접속하는 인증은 불가능해야 하며, SSH 키 기반의 인증을 사용하여야 한다. 이제 클러스터 보안에 대해 알아보자. 쿠버네티스의 모든 기능의 중심에는 kube-apiserver가 존재한다. 각 유틸리티가 서로 상호작용을 할 때, 항상 해당 서버를 통과하게 된다. 따라서 apiserver의 보안이 1차 보안 저지선이 된다. API 서버에 대한 액세스 접근 제어를 실행하는 것이다. 이러한 접근 제어는 인증 을 통해서 제어하게 된다. 인증은 사용자 ID, 암호, 토큰을 파일로 저장하여 인증하거나, LDAP와 같은 외부 인증 공..