AEWS 6주차 - EKS Security(x.509, k8s config)

 

본 글은 가시다님이 진행하시는 AEWS(AWS EKS Workshop Study)를 참여하여 정리한 글입니다.  모르는 부분이 많아서 틀린 내용이 있다면 말씀 부탁드리겠습니다!

 

 

 

 

 

 

 

---

X.509

 

 

X.509란?

x.509는 공개 키 인프라(PKI, Public Key Infrastructure)에서 사용되는 표준입니다. 이 표준은 디지털 인증서를 정의하고, 인증서의 형식과 인증서 검증 방법을 규정합니다. x.509는 주로 SSL/TLS, 이메일 보안(S/MIME), 코드 서명 등 다양한 보안 프로토콜에서 사용됩니다.

 

 

x,509 인증서?

x.509 인증서는 디지털 문서로, 사용자, 서버 또는 장치의 신원을 확인하고, 공개 키를 안전하게 배포하는 데 사용됩니다. 인증서는 인증 기관(CA, Certificate Authority)에 의해 발급되며, 다음과 같은 정보를 포함합니다: 주체(Subject): 인증서가 발급된 엔티티(사용자, 서버 등)의 정보 발급자(Issuer): 인증서를 발급한 인증 기관의 정보 유효 기간(Validity Period): 인증서의 유효 시작 날짜와 만료 날짜 공개 키(Public Key): 주체의 공개 키 서명(Signature): 인증 기관의 개인 키로 서명된 인증서 데이터

 

 

 

x.509 인증서의 동작 원리

 

x.509의 동작 원리는 아래와 같습니다.

 

인증서 발급

1. 키 쌍 생성: 주체는 공개 키와 개인 키 쌍을 생성합니다.
2. 인증서 서명 요청(CSR, Certificate Signing Request): 주체는 공개 키와 자신의 정보를 포함한 CSR을 생성하여 인증 기관에 제출합니다.
3. 인증서 발급: 인증 기관은 CSR을 검토하고, 주체의 신원을 확인한 후, 주체의 공개 키와 정보를 포함한 x.509 인증서를 생성하여 서명합니다.
4. 인증서 수신: 주체는 인증 기관으로부터 서명된 인증서를 수신합니다.

인증서 검증

1. 인증서 수신: 클라이언트는 서버와의 통신을 시작할 때 서버로부터 x.509 인증서를 수신합니다.
2. 서명 검증: 클라이언트는 인증서의 서명을 검증하여 인증서가 신뢰할 수 있는 인증 기관에 의해 발급되었는지 확인합니다.
3. 유효성 검사: 클라이언트는 인증서의 유효 기간을 확인하고, 인증서가 만료되지 않았는지 확인합니다.
4. 신원 확인: 클라이언트는 인증서의 주체 정보와 서버의 도메인 이름이 일치하는지 확인합니다.

 

 

결론적으로 이 표준은 디지털 인증서를 통해 사용자와 서버의 신원을 확인하고, 안전한 통신을 가능하게 합니다

 

 

여기서 잠깐

 

PKI는 공개 키 암호화와 디지털 인증서를 사용하여 네트워크 상에서 안전한 통신을 가능하게 하는 전체 시스템입니다.

 

* 즉 x.509 인증서는 공개 키와 소유자의 신원을 인증하는 데 사용됩니다. PKI는 이러한 인증서를 발급, 관리, 철회하는 전체 시스템을 포함합니다.

 

 

 

---

x.509 in k8s

 

kind로 구성해서 실제 /etc/kubernetes/pki 아래에 보안 관련 파일들을 확인해보겠습니다.

 

# 인증서 확인
docker exec -it myk8s-control-plane ls -l /etc/kubernetes/pki
-rw-r--r-- 1 root root 1123 Mar  7 13:34 apiserver-etcd-client.crt
-rw------- 1 root root 1675 Mar  7 13:34 apiserver-etcd-client.key
-rw-r--r-- 1 root root 1176 Mar  7 13:34 apiserver-kubelet-client.crt
-rw------- 1 root root 1675 Mar  7 13:34 apiserver-kubelet-client.key
-rw-r--r-- 1 root root 1326 Mar  7 13:34 apiserver.crt # 루트인증서로부터 발급된 하위 인증서
-rw------- 1 root root 1675 Mar  7 13:34 apiserver.key
-rw-r--r-- 1 root root 1107 Mar  7 13:34 ca.crt # 루트인증서
-rw------- 1 root root 1675 Mar  7 13:34 ca.key # 루트인증서에 대응하는 비밀키
drwxr-xr-x 2 root root 4096 Mar  7 13:34 etcd
-rw-r--r-- 1 root root 1123 Mar  7 13:34 front-proxy-ca.crt
-rw------- 1 root root 1679 Mar  7 13:34 front-proxy-ca.key
-rw-r--r-- 1 root root 1119 Mar  7 13:34 front-proxy-client.crt
-rw------- 1 root root 1679 Mar  7 13:34 fron

 

 

각 파일의 용도를 설명드리겠습니다.

 

 

1. apiserver-etcd-client.crt / apiserver-etcd-client.key
   • 용도: Kubernetes API 서버가 etcd 서버와 통신할 때 사용하는 클라이언트 인증서와 키입니다.
   • 연관 관계: apiserver-etcd-client.crt는 공개 키 인증서이고, apiserver-etcd-client.key는 해당 인증서의 개인 키입니다.
2. apiserver-kubelet-client.crt / apiserver-kubelet-client.key
   • 용도: Kubernetes API 서버가 kubelet과 통신할 때 사용하는 클라이언트 인증서와 키입니다.
   • 연관 관계: apiserver-kubelet-client.crt는 공개 키 인증서이고, apiserver-kubelet-client.key는 해당 인증서의 개인 키입니다.
3. apiserver.crt / apiserver.key
   • 용도: Kubernetes API 서버가 클라이언트(예: kubectl)와 통신할 때 사용하는 서버 인증서와 키입니다.
   • 연관 관계: apiserver.crt는 공개 키 인증서이고, apiserver.key는 해당 인증서의 개인 키입니다.
4. ca.crt / ca.key
   • 용도: 클러스터의 루트 인증서와 키로, 다른 인증서를 서명하는 데 사용됩니다.
   • 연관 관계: ca.crt는 공개 키 인증서이고, ca.key는 해당 인증서의 개인 키입니다. ca.crt는 클러스터 내 다른 인증서들을 검증하는 데 사용됩니다.
5. etcd 디렉토리
   • 용도: etcd 서버와 관련된 인증서와 키 파일들이 저장됩니다.
   • 연관 관계: etcd 서버의 통신을 보호하기 위한 인증서와 키 파일들이 포함됩니다.
6. front-proxy-ca.crt / front-proxy-ca.key
   • 용도: 프론트 프록시 인증서와 키로, 클러스터 내 프록시 서버가 사용하는 인증서들을 서명하는 데 사용됩니다.
   • 연관 관계: front-proxy-ca.crt는 공개 키 인증서이고, front-proxy-ca.key는 해당 인증서의 개인 키입니다.
7. front-proxy-client.crt / front-proxy-client.key
   • 용도: 프론트 프록시 서버가 클라이언트로서 다른 서버와 통신할 때 사용하는 클라이언트 인증서와 키입니다.
   • 연관 관계: front-proxy-client.crt

 

그리고 sa.key, sa.pub이 있습니다.

 

왜 다른 것들은 crt(공개 키 인증서), key(개인 키)인데 sa(service account)는 key와 pub으로 이루어져있을까요??

 

 

pub 확장자?

반적으로 .crt 파일은 인증서 파일로, 공개 키와 함께 인증 기관(CA)의 서명이 포함된 파일입니다. 반면, .pub 파일은 단순히 공개 키만을 포함하는 파일입니다.

 

왜 sa만 pub인가?

서비스 어카운트(Service Account, SA) 키 파일의 경우, 공개 키를 인증서 형태로 저장할 필요가 없기 때문입니다. 서비스 어카운트 토큰을 서명하고 검증하는 데 사용되는 키는 단순히 공개 키와 개인 키 쌍으로만 필요합니다. 따라서 공개 키는 .pub 파일로 저장되고, 개인 키는 .key 파일로 저장됩니다.

 

 

 

그러면 또 왜 sa는 인증서 형태로 저장할 필요가 없는지가 꼬리로 궁금합니다.

이는 아래에 접은글로 Chatgpt 답변으로 대체하겠습니다.

질문 : sa는 key와 pub파일로 보안을 유지하는데 sa는 왜 crt와 같은 인증서가 필요가 없는거니?

 

답변 : 서비스 어카운트(Service Account)가 인증서를 필요로 하지 않는 이유는 그 사용 목적과 보안 요구사항이 다르기 때문입니다. 이를 이해하기 위해 몇 가지 중요한 점을 설명드릴게요.

서비스 어카운트의 역할

서비스 어카운트는 Kubernetes 클러스터 내에서 애플리케이션이나 파드가 API 서버와 통신할 때 사용하는 계정입니다. 주로 애플리케이션이 클러스터 내에서 인증 및 권한 부여를 받기 위해 사용됩니다.

인증서 vs. 공개 키

• 인증서 (.crt 파일): 인증서는 공개 키와 소유자의 신원 정보를 포함하며, 인증 기관(CA)에 의해 서명됩니다. 이는 주로 네트워크 상에서 통신하는 두 주체 간의 신뢰를 보장하기 위해 사용됩니다.
• 공개 키 (.pub 파일): 공개 키는 단순히 암호화된 데이터를 복호화하거나 디지털 서명을 검증하는 데 사용됩니다. 인증서와 달리 추가적인 신원 정보나 CA의 서명이 포함되지 않습니다.

서비스 어카운트의 보안 요구사항

서비스 어카운트는 주로 클러스터 내부에서 사용되며, 외부와의 통신보다는 클러스터 내의 리소스 접근을 위해 사용됩니다. 따라서 서비스 어카운트 토큰의 서명과 검증을 위해서는 공개 키와 개인 키 쌍만으로 충분합니다. 인증서가 필요하지 않은 이유는 다음과 같습니다:

1. 내부 사용: 서비스 어카운트는 클러스터 내부에서만 사용되므로, 외부와의 신뢰 관계를 형성할 필요가 없습니다.
2. 간단한 검증: 서비스 어카운트 토큰은 간단한 공개 키 암호화를 통해 서명되고 검증됩니다. 이를 위해서는 공개 키와 개인 키 쌍만 있으면 충분합니다.
3. 성능: 인증서를 사용하면 추가적인 검증 과정이 필요하지만, 공개 키만 사용하면 성능이 더 효율적입니다.

요약

서비스 어카운트는 클러스터 내부에서만 사용되며, 간단한 공개 키 암호화를 통해 인증과 권한 부여를 처리합니다. 따라서 인증서가 필요 없고, 공개 키를 .pub 파일로 저장하여 사용합니다.

 

 

 

ca.crt의 내용을 보겠습니다.

        X509v3 extensions:
            X509v3 Key Usage: critical #  클라이언트는 이 키 사용 용도를 반드시 준수
                Digital Signature, Key Encipherment, Certificate Sign
                # Digital Signature: 인증서가 디지털 서명에 사용됨.
                # Key Encipherment: 인증서가 키 암호화(예: TLS에서 세션 키 암호화)에 사용됨.
                # Certificate Sign: 이 인증서가 다른 인증서를 서명(즉, CA 역할)할 수 있음. 주로 인증 기관(CA) 인증서에서 사용됨.
            X509v3 Basic Constraints: critical # 인증서가 인증 기관(CA) 역할을 할 수 있는지를 나타냄.
                CA:TRUE
            X509v3 Subject Key Identifier:
                32:75:7F:9F:C2:C4:C8:25:8C:04:79:6A:B7:18:84:27:37:E2:4A:75
            X509v3 Subject Alternative Name: #  인증서가 적용되는 주체(Subject)의 대체 이름
                DNS:kubernetes

 

 

apiserver-kubelet crt도 확인해봅니다.

        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: # 클라이언트 인증용
                TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                9C:02:D8:8C:1D:C8:B2:76:4C:1C:35:2C:37:AE:E6:6B:1B:DB:31:80

 

 

이번에는 kind의 kubeconfig를 확인해봅니다.

 

users:
- name: kind-myk8s
  user:
    client-certificate-data: LS0tL... #클라이언트 인증서
    client-key-data: LS0tLS1CR.... #클라이언트 개인키
    의 형태로 이루어져 있는데, 이 Data를 decode 후 crt파일로 작성 예정

 

 

디코딩을 진행 후 작성합니다.

 

echo "LS0tL..." | base64 -d
vi myuser.crt
-----BEGIN CERTIFICATE-----

openssl x509 -in myuser.crt -noout -text # 인증서 확인

 

 

 

결과 화면

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3935979122202913559 (0x369f68286e422b17)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes #인증서 발급 기관
        Validity
            Not Before: Mar 12 06:21:12 2025 GMT
            Not After : Mar 12 06:26:12 2026 GMT
        Subject: O=kubeadm:cluster-admins, CN=kubernetes-admin
				# 주체 조직, 공통 이름
		X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE 
            X509v3 Authority Key Identifier:
                keyid:9C:02:D8:8C:1D:C8:B2:76:4C:1C:35:2C:37:AE:E6:6B:1B:DB:31:80

 

 

 

Subject 필드는 인증서의 소유자 정보를 나타내며, 다양한 속성들을 포함할 수 있습니다. 이 속성들은 인증서의 소유자를 식별하고, 때로는 권한을 나타내기도 합니다.

 

Subject: O=kubeadm:cluster-admins, CN=kubernetes-admin

 

항목

• O=kubeadm:cluster-admins:
  • 이 인증서는 kubeadm:cluster-admins 조직에 속한 주체에게 발급되었습니다.
  • 같은 조직 이름을 가진 주체들은 일반적으로 같은 권한을 가질 수 있습니다.
• CN=kubernetes-admin:
  • 이 인증서의 소유자는 kubernetes-admin이라는 공통 이름을 가지고 있습니다.
  • 이는 주로 Kubernetes 클러스터의 관리자 계정을 나타냅니다.

권한과 관련된 사항

• 같은 O (Organization):
  • 같은 조직 이름을 가진 주체들은 일반적으로 같은 권한을 가지는 경우가 많습니다. 예를 들어, O=kubeadm:cluster-admins 조직에 속한 모든 주체들은 클러스터 관리자 권한을 가질 수 있습니다.
  • 이는 조직 내에서 권한을 관리하고 분배하는 데 중요한 역할을 합니다.

 

 

 

 

---

신규 관리자를 위한 인증서 설정

 

 

 

 

CSR(Certificate Signing Request)란?

CSR은 인증서 서명 요청서로, 인증 기관(CA)에게 인증서를 발급받기 위해 제출하는 요청서입니다. CSR에는 인증서에 포함될 정보와 공개 키가 포함되어 있으며, 요청자의 개인 키로 서명됩니다.

CSR의 주요 구성 요소

1. 주체 정보 (Subject Information):
   • 인증서에 포함될 주체의 정보입니다. 예를 들어, Common Name (CN), Organization (O), Organizational Unit (OU), Country (C), State or Province (ST), Locality (L) 등이 포함됩니다.
2. 공개 키 (Public Key):
   • 요청자가 생성한 공개 키가 포함됩니다. 이 공개 키는 인증서에 포함될 것입니다.
3. 서명 (Signature):
   • 요청자의 개인 키로 CSR을 서명합니다. 이를 통해 CSR의 무결성과 요청자의 신원을 보장합니다.

CSR 생성 과정

1. 개인 키 생성:
   • 먼저, 요청자는 자신의 개인 키와 공개 키 쌍을 생성합니다.
2. CSR 생성:
   • 생성된 공개 키와 주체 정보를 포함한 CSR을 생성합니다.
   • CSR은 요청자의 개인 키로 서명됩니다.
3. CSR 제출:
   • 생성된 CSR을 인증 기관(CA)에 제출합니다.
4. 인증서 발급:
   • CA는 CSR을 검토하고, 요청자의 신원을 확인한 후, 요청된 정보와 공개 키를 포함한 인증서를 발급합니다.

 

 

 

실습 스터디의 내용을 그대로 발췌하겠습니다.

# 하위 인증서를 위한 비밀키 생성 : gasida 대신 자신의 닉네임으로 변경해서 실습해보세요!
openssl genrsa -out gasida.key 2048

# 확인
cat gasida.key
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCpb0u8E7Km0CkX
...

# 인증서 사인 요청 파일(.csr) 파일 생성
openssl req -new -key gasida.key -out gasida.csr -subj "/O=kubeadm:cluster-admins/CN=gasida-cert"

# 확인
cat gasida.csr
-----BEGIN CERTIFICATE REQUEST-----
MIICczCCAVsCAQAwLjEWMBQGA1UECgwNY2xvdWRuZXRhLW9yZzEUMBIGA1UEAwwL
...

# 출력 값을 아래 request 에 붙여넣기 : 끝에 == 빼먹지 말것!
cat gasida.csr | base64 | tr -d '\n'

# CSR 요청 : k8s 내부적으로 루트인증서의 비밀키로 서명해 반환. 즉 간접적으로 루트 인증서의 비밀키를 사용할 수 있음 셈.
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: gasida-csr
spec:
  signerName: kubernetes.io/kube-apiserver-client
  groups:
  - system:masters
  - system:authenticated
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ2ZEQ0NBV1FDQVFBd056RWZNQjBHQTFVRUNnd1dhM1ZpWldGa2JUcGpiSFZ6ZEdWeUxXRmtiV2x1Y3pFVQpNQklHQTFVRUF3d0xaMkZ6YVdSaExXTmxjblF3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLCkFvSUJBUURTOU9xRktsTCt6Z0RoQ2Qxb3QvS1h0Q1JTMWI5Y3p1YzVDdW5WcTUrdEtFRkIydzFpby9zQUtwOUMKSlo2UklLcXFydm85YXRzTkF1cGFybUNORnV5SHN1d1d3RjdNbTdCYzZpZk1uRElDSU1ybG5BUDhyYkllcHFuRwo4YkJxTXM1c3VoYXl6UlVMT3hkeEg5K1ZqOERoSjZsQ0FaL3ZTcEVtVXJlbjMyMGJIZzRUay9JTnE5a0REN2xJCjR2a0ZTQzlqeDVtRG9mT2FvNzhHZEl1c0lZK01wT3Vvb1I2ZWVmSlJOa3NPanBGQ1F5bGExTURWeHd1OVpDbG4KU3FXZWFmWHZiODNnSGdJYmRsSDRER2Z3bzQrRERQckpZak5oLzA1UVd2Zjh0UW5XTkpJdXRRblpOOGlxRVhrQQpBdG5UY0tWcDFTS2x3LzJ3azJuQkU5anE4VFN2QWdNQkFBR2dBREFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBCm00UGpaZGM1ZERlS3d2dk1qUlRMWmJNRVBTQkQ4QXlLMWEyU1k4QjU1MmFNWlhFekFGQ1Zob2xxWGFsWmhudWkKbDZzeHVTVWVkMWxKQyt4OURZcHlrTmNYTXI3NDgrNkR0dTQybklUVGRZcmg4bHh0cjNSWEFkVXNYSzZoNDBxcApJVEVVNXpkeXBxZmMyMmJpN0hhZWhxZEo0c1lsaGNYK2pJemYxVml6SHUyd25ET1BWdlQxQTFnS3NwRE9kK2NCCm9DeTF2cUNxVDkydjhjektmTHVYdFMvL2QwRkJaRjlqaU9vWnpnV0pUYTV5K1Nsak1oV0hTNU1MMEkrUk9KdW0KYi91NVRDYytKRnhpRFlIOVg3MlNWL3VJaXJVNVgwRmFnaUJ0bjRjVEF1cFVrNFRrYlN4QUxXcmNOeGFXdjZ4MgpqaEV4WThFOGFNeGRuaXRDeU56WjNBPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg==
  usages:
  - digital signature
  - key encipherment
  - client auth
EOF

# csr 확인 : 아직은 펜딩 상테
kubectl get csr
NAME         AGE   SIGNERNAME                              REQUESTOR              REQUESTEDDURATION   CONDITION
gasida-csr   1s    kubernetes.io/kube-apiserver-client     kubernetes-admin       <none>              Pending
...

# 'k8s 관리자' 입장에서 해당 서명 요청을 승인하자
kubectl certificate approve gasida-csr
certificatesigningrequest.certificates.k8s.io/gasida-csr approved

# 확인 : 정상적으로 하위 인증서가 발급됨
kubectl get csr
NAME         AGE    SIGNERNAME                              REQUESTOR             REQUESTEDDURATION   CONDITION
gasida-csr   2m4s   kubernetes.io/kube-apiserver-client     kubernetes-admin      <none>              Approved,Issued
...

# csr 에서 하위 인증서 추출
kubectl get csr gasida-csr -o jsonpath='{.status.certificate}' | base64 -d
kubectl get csr gasida-csr -o jsonpath='{.status.certificate}' | base64 -d > gasida.crt

#
openssl x509 -in gasida.crt -noout -text
...
        Issuer: CN=kubernetes
        Validity
            Not Before: Mar  7 14:03:06 2025 GMT
            Not After : Mar  7 14:03:06 2026 GMT
        Subject: O=kubeadm:cluster-admins, CN=gasida-cert
        ...
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication

# kubeconfig 에 새로운 사용자 등록
kubectl config set-credentials gasida-user --client-certificate=gasida.crt --client-key=gasida.key
kubectl config set-context kind-gasida --cluster=kind-myk8s --user=gasida-user
cat ~/.kube/config
kubectl config use-context kind-gasida # 혹은 kubectl ctx kind-gasida

# ctx kind-gasida 로 k8s 정보 확인 시도
kubectl get node

 

 

csr 승인전

 

관리자 승인

 

csr 승인