CKA 자격증 따기 - day10
Security Primitives
kube-apiserver는 앞단에서 우리와 상호작용한다.
kube-apiserver는 첫번쨰 방어선으로써 API서버 자체에 대한 엑세스를 제어해야 한다.
kube-apiserver를 주축으로 kubelet, etcd, controller-manager, kube-proxy, kube-scheduler와의 통신에는 TLS인증이 필요하다.
기본적으로 모든 pod들은 클러스터 내 다른 모든 pod들에 접근 할 수 있지만, 네트워크 정책을 사용하여 엑세스를 제안할수 있음
인증
-
FIles: ID & PASSWORD, ID & TOKEN
-
Certificate, External Authentication provider - LDAP
-
Service Account
인증 완료 후 권한 부여
- RBAC(Role Based Access Control) Authorization
- ABAC(Attribute Based Access Control) Authorization
- Node Authorization
- Webhook Mode
Authentication
- 모든 사용자의 엑세스는
kube-apiserver를 거친다. -
kube-apiserver에는 정적 파일에 유저 정보와 유저 정보 + 토큰을 관리하는 기능을 제공 - 이는 가장 쉬운 방법이며
.csv파일에비밀번호, 유저이름, 유저ID순으로 기록 하고kube-apiserver에--basic-auth-file=user-details.csvc를 지정
password123,user1,u0001,{group}
# 직접 argument를 지정 후 재시작
kube-apiserver --basic-auth-file=user-detail.csv
# yaml파일 변경하면 자동으로 재시작
/etc/kubernetes/manifests/kube-apiserver.yaml
- command:
- --basic-auth-file=user-detail.csv
- 또한 token으로도 인증이 가능하다.
토큰, 비밀번호, 유저이름, 유저아이디순으로 기록하며--token-auth-file=user.details.csv로 지정 -
requst시Authorization: Token전달
방법은 위와 동일하다
- 정적파일에 일반 텍스트를 저장하는 이 인증은 안전하지 않으므로 권장되지 않음
TLS Basic
-
인증서는 거래중 두 당사자 간의 신뢰를 보장하는데 사용
-
유저가 로그인 하려 할 때 네트워크로 전송되는 유저의 정보는 중간에 가로챌 가능성이 반드시 존재한다.
-
http에서 사용자가 로그인 할 때 유저 정보와 비밀번호를 평문으로 전달하면 공격자가 탈취가 가능하기에https를 사용하여야 한다. - 데이터에 난수를 추가하고 인식할수 없는 형식으로 암호화하여 보내고 서버가 메시지를 해독하고 읽을 수 있도록 키 사본도 서버로 보내야한다. 하지만 공격자가 키 사본을 탈취하면 평문으로 해독이 가능함(
대칭암호화) - 유저정보를
공개키를 통해 암호화 하고개인키를 통해 복호화 할 수 있다.(비대칭암호화)
웹서버 예시
서버는 공개 SSL명령을 사용하여 개인 및 공개키 쌍을 생성한다.
-
클라이언트는 서버에게 지원 가능한 방식을 서버에게 알려준다(
client hello)-
32byte 난수 값 전달(master secret)
-
암호화 방식전달
-
- 서버는 TLS버전, Cihper suite, 압축 방식등 client에게 전달(
server hello)- 32byte 난수 값 전달(master secret)
- 서버는 유저에게
공개키전달(server certificate)- 이 인증서를 통해 클라이언트는 서버가 신뢰할 수 있는 서버인지 확인
- 서버는 키교환에 필요한 정보를 제공(
Server key exchange)- 생략가능
- 서버가 클라이언트 인증서요청 가능(
Certificate request)- 생략가능
- 서버 인사 종료(
Server hello done) - 클라이언트 인증서 전달(
Certificate)- 서버가
Certificate request를 요청한 경우
- 서버가
-
클라이언트 키 교환(
Client key exchange)-
이전에 서버한테 받은 난수와 클라이언트가 생성한 난수를 조합하여 서버에게 전달
-
서버에게 받은 공개키로 암호화 하여 전송
-
클라이언트와 서버는
master secret으로 세션에 사용할 키를 생성하게 되는데 이것이대칭키
-
- 클라이언트 인증 확인(
Certificate vertify)- 서버가
Certificate request를 요청한 경우 개인키로 디지털 서명하여 전송
- 서버가
-
클라이언트 보안 파라미터 적용(
Change ciper spec) -
클라이언트 끝(
Finished) -
서버 보안 파라미터 변경 알림(
Change chper spec) - 서버 끝(
Finished)
해커의 공격방법
- 동일한 웹서버를 구성하여 사용자가 키를 전달하게 하여 갈취함
- 이를 막기 위해 서버는
public key를 유저에게 전달할 때key만 전달하는 것이 아니라certificate라는 인증서와 함께 전달한다. - 이 인증서는 해당 서버가 안전하다는 것을 보장해주는 인증서이다.
- 브라우저에서는 인증서가 유효하지 않을 경우 사용자에게 경고를 내어 알려줌
보안에 취약한 사이트입니다.
- 인증서가 유효하다는 것을 인증하기 위해서는
CA기관에 인증을 받아야된다. - 해커는
CA기관에게 인증을 받기는 불가능하다. 웹 사이트의 진정한 주인인지 확인 -
CA기관들은 각자 자신들만의개인키와공개키를 갖는다. -
공개키들은 모두 브라우저에 내장되어 있으며, 브라우저는CA에공개키를 통해CA가 인증한 인증서인지 확인
Comodo global sign인 Symantec등등…
TLS in Kubernetes
구분법
”* key *” 가 없는 것은 공개키 또는 인증서
| Certificate(Public Key) | Private Key |
|---|---|
| server.crt | server.key |
| server.pem | server-key.pem |
| client.crt | client.key |
| client.pem | client-key.pem |
-
kubernetes간 모든 통신은 secure 해야 한다. -
kube-apiserver에 대한 통신도 sercure 해야 한다.
Server Certificates for Servers
-
kube-apiserver: apiserver.crt, apiserver.key -
etcd: etcdserver.crt, etcdserver.key -
kubelet: kubelet.crt, kubelet.key
Client Certificates for Clients
-
user(kubectl 명령을 사용하는 ADMIN): admin.crt, admin.key -
kube-scheduler: scheduler.crt, scheduler.key -
kube-controller-manager: controller-manager.crt, contorller-manager.key -
kube-proxy: kube-proxy.crt, kube-proxy.key -
kube-apiserver(서버들과 통신하는 유일한 서버): apiserver.crt, apiserver.key
인증서 그룹화
-
인증서가 너무 많기에 그룹화 하여 생성
-
모든 인증서에 서명할려면 하나 이상의
CA기관이 필요함
TLS in Kubernetes - Certificate Cration
다양 한 도구를 사용할 수 있음
- EASYRSA
- OPENSSL
- CFSSL
Client Certificates for Client 실습
괸리자 인증서 생성
# 개인 키 생성 (Generate Keys)
$ openssl genrsa -out ca.key 2048
> ca.key
# 인증서 생성 (Certificate Signing Request)
$ openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr
> ca.csr
# 서명 요청 (Sign Certificates)
$ openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt
> ca.crt
클라이언트 인증서 생성(만들어진 인증서를 가지고)
# 개인 키 생성 (Generate Keys)
$ openssl genrsa -out admin.key 2048
> admin.key
# 인증서 생성 (Certificate Signing Request)
# O=매개변수를 사용하여 그룹 세부정보를 추가함
$ openssl req -new -key ad,om.key -subj "/CN=kube-admin/O=system:masters" -out admin.csr
> admin.csr
# 서명 요청 (Sign Certificates)
$ openssl x509 -req -in admin.csr -CA ca.crt -CAKey ca.key -out admin
> admin.crt
kube-config.yaml
apiVersion: v1
clusters:
- cluster:
certificate=authority: ca.crt
server: https://kube-apiserver:6443
name: kubernetes
kind: Config
users:
- name: kubernetes-admin
user:
client-certificate: admin.crt
client-key: admin.key
Server Certificates for Server 실습
- etcd
cat etcd.yaml
--key-file=
--cert-file
--peer-cert-file=
--peer-client-cert=
--peer-key-file=
--peer-trusted-ca-file=
--trusted-ca-file=
- kube-apiserver
# 개인 키 생성 (Generate Keys)
$ openssl genrsa -out admin.key 2048
> admin.key
# 인증서 생성 (Certificate Signing Request)
# O=매개변수를 사용하여 그룹 세부정보를 추가함
$ openssl req -new -key ad,om.key -subj "/CN=kube-admin/O=system:masters" -out admin.csr
> admin.csr
$ vi openssl.cnf
[alt_names]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.local
IP.1 = 10.96.0.1
IP.2 = 172.17.0.87
View Certificated Details
-
kubeadm을 사용하면 손쉽게 클러스터 설치와 설정이 가능하다. -
kubeadm을 사용해 설치하면 각종 CA가 설정값에 잡혀있는것을 볼 수 있다. -
/etc/kubernetes/manifests/kube-apiserver.yaml을 보면CA파일 위츠를 알 수 있다.
인증서 내용 보기
$> openssl x509 -in /etc/kuber/netes/pki/apiserver.crt -text -noout
댓글남기기