개발자(엔지니어)에게 꼭 필요한 기초 암호학(X.509)

암호화란?

암호화란 정보를 보호하기 위해 평문(원본 데이터)을 특정 알고리즘을 통해 암호문(이해할 수 없는 형태)으로 변환하는 과정이다.
암호에 대해서 가장 중요한 것은 기밀성을 제공하는 것이다.

현대 사용하는 암호화 방식에는 대칭 암호화, 비대칭 암호화, 해쉬 크게 3가지가 있다.

대칭키 암호화

대칭키 암호화는 암호화와 복호화에 동일한 키를 사용하는 방식으로, 일반적인 자물쇠와 열쇠의 관계와 유사하다. 하나의 열쇠로 자물쇠를 잠그고 같은 열쇠로 여는 것처럼, 하나의 비밀키로 데이터를 암호화하고 같은 키로 복호화한다. 비대칭키 암호화에 비해 알고리즘이 단순하여 CPU 리소스 소모가 적고 처리 속도가 빠른 장점이 있다. 대표적인 알고리즘에는 DES, AES, SEED, ARIA 등의 있다.
 
암호화 실습(AES)
 
아래 사이트는 다양한 암호 기법을 실습해 볼 수 있는 사이트이다.
https://emn178.github.io/online-tools/aes/decrypt/

AES Decryption

 
 
대칭키 암호화의 대표적인 알고리즘인 AES 알고리즘으로 간단한 암호화 실습을 해보자.
 
암호화 실습(AES) - 암호화(Encryption)
원본 데이터에 암호화키를 넣고 암호화를 진행한다.

• input: 암호화할 값 -> chillhuy
• PassPharase: 암호화키 -> thisissecret
• output: 암호화된 값 -> 53616c7465645f5f460914a0d84c0253365d64f57f8afe0c3f03c633fb409106

 
 
암호화 실습(AES) - 복호화(Decryption)
암호화에서 사용한 동일한 암호화키(passpharase)를 넣고 복호화 시, 원본 데이터를 확인할 수 있다.

• input: 복호화할 값 -> 53616c7465645f5f460914a0d84c0253365d64f57f8afe0c3f03c633fb409106
• PassPharase: 암호화키 -> thisissecret
• output: 복호화 값 -> chillhuy
  
  

비대칭키 암호화

대칭키 암호화는 암호화와 복호화에 서로 다른 키를 사용하는 방식이다. 키페어(한 쌍) 즉, 하나의 키로 암호화하면 다른 하나의 키로 복호화할 수 있는 특징이 있다. 송신자는 수신자의 공개된 공개키를 가지고 암호화하여 데이터를 보내면, 개인키를 가지고 있는 수신자만이 복호화할 수 있다. 대표적인 알고리즘으로는 RSA 방식이 존재한다.
 
왜 이렇게 복잡하게 암호화를 해야 할까? 그 이유는 바로 대칭키 방식의 한계를 극복하기 위함이다. 대칭키 방식은 암복호화 시, 동일한 키를 사용하기 때문에, 키를 교환하는 과정에서 원하지 않는 사람에게 키가 노출될 수 있다.(키노출사고)
 
하지만, 그렇다고 해서 비대칭키 암호화가 장점만 존재하는 것은 아니다. 보안성이 뛰어난 만큼, 복잡한 로직(수학적 연산)으로 인해 대칭키 암호화보다 리소스 소모가 훨씬 크다. 그래서 실제 통신 환경에서는 두 방식을 효율적으로 조합하여 사용한다. SSL/TLS와 같은 보안 프로토콜에서의 경우 초기 연결 설정(핸드세이크) 단계에서만 비대칭키 암호화를 사용하여 안전하게 PMS(Pre-Master Secret)라는 임시 대칭키를 교환하고, 이후 실제 데이터 통신은 이 PMS를 기반으로 생성된 세션 키(대칭키)를 사용하여 암호화한다.
 
암호화 실습(RSA) - 키페어 발급 
먼저, 공개키와 비밀키를 생성하고 해당 내용을 저장한다.

 
 
암호화 실습(RSA) - 암호화(Encryption)
발급받은 공개키를 통해 배포 input(원본 데이터)를 암호화한다. 같은 원본데이터는 반복해서 암호화할 때마다 암호화된 값은 계속 바뀌는 것을 확인할 수 있다.

 
 
암호화 실습(RSA) - 복호화(Decryption)
개인키를 통해 암호화된 값은 Input에 넣고 복호화하면, 원본데이터가 출력됨을 확인할 수 있다.
 

Hash 함수

해시 함수는 임의 길이의 데이터를 고정된 길이의 값으로 변환하는 단방향 암호화 기술이다. 단방향이라는 것은 원본 데이터를 암호화할 수는 있지만, 복호화할 수는 없다는 의미이다. 이러한 단방향 암호의 주요 목적은 정보 은닉이 아닌, 데이터 무결성을 검증하기 위함이다.
 
해시 함수는 원본데이터를 조금이라도 변경하면, 출력되는 암호화 값이 아예 달라지므로, 원본 데이터를 추측할 수 없게 한다. 해시 함수는 데이터 무결성 검증에 이상적이지만, 치명적인 보안적 취약점도 존재한다.
 
해시 함수의 특성상 동일한 입력에는 항상 동일한 출력값이 생성되므로, 공격자가 미리 계산된 해시값 목록(레인보우 테이블)을 구축하여 역으로 원본 데이터를 찾아낼 수 있다. 이러한 취약점을 해결하기 위해 대표적으로는 솔트(Salt) 기법이 적용된다. 솔트는 해시하기 전 원본 데이터에 임의의 값을 추가하여 동일한 입력이라도 다른 해시값이 생성되게 한다.
 
이러한 무차별 대입공격과 레인보우 테이블 공격에 대응하기 위해서는 보다 강력한 해시 알고리즘을 사용하는 것이 중요하다. 실제로 대부분 보안 표준 기관들은 MD5, SHA-1과 같은 취약한 알고리즘 대신, SHA-256, SHA-512 같은 강력한 해시 알고리즘을 사용하도록 권고한다.
 
암호화 실습(Hash) - 암호화(Encryption)

별도의 키 없이 고정된 크기의 암호화된 값을 확인할 수 있으며, 알고리즘 강도에 따라 글자수가 길어진다.

원본데이터의 길이를 늘려보아도, 암호화된 데이터의 크기는 일정한 것을 확인할 수 있다.

메시지 인증 : 메시지의 무결성

메시지 인증은 데이터 전송 과정에서 원본 데이터의 무결성을 보장하기 위한 기술이다.  보낸 사용자의 원본 데이터가 변경되지 않았는지를 검증하기 위해 (원본데이터 + 해시 함수)를 더해 보낸다.
 
하지만, 해시 함수만 사용할 경우 중간자 공격에 취약하기 때문에, HMAC(Hash-based Message Authentication Code)이라는 보다 안전한 방식이 사용된다. HMAC은 메시지와 비밀키를 함께 해시 함수(원본데이터 + 해시 함수 + 비밀키)에 입력하여 인증 코드를 생성함으로써 메시지의 무결성과 송신자 인증을 동시에 제공한다. 송신자와 수신자만이 공유하는 비밀키를 사용하기 때문에, 키를 모르는 제3자는 유효한 HMAC 값을 생성할 수 없다. HMAC-MD5, HMAC-SHA256 등 다양한 해시 알고리즘과 조합하여 사용할 수 있으며, SSL/TLS, IPsec, VPN 등 많은 보안 프로토콜에서 메시지 인증을 위해 널리 활용된다.
 

디지털 서명 : 부인봉쇄의 필요성

디지털 서명은 메시지 인증의 한계를 넘어 부인방지(non-repudiation) 기능을 제공하는 암호화 기술이다. HMAC이 메시지 무결성을 검증할 수 있지만, 송신자와 수신자가 동일한 비밀키를 공유하기 때문에 누가 메시지를 생성했는지 제3자가 확인할 수 없다는 한계가 존재한다. 

부인방지(non-repudiation)는 디지털 서명을 통해 송신자가 자신의 개인키로 메시지에 서명함으로써, 나중에 해당 메시지를 보냈다는 사실을 부인할 수 없도록 하는 보안 기능이다.

 
디지털 서명은 이 문제를 해결하기 위해 비대칭키 암호화의 특성을 활용한다. 송신자는 자신의 개인키(오직 본인만 소유)로 데이터를 암호화하여 서명을 생성하고, 수신자는 송신자의 공개키로 이 서명을 복호화하여 검증합니다. 이 과정을 통해 해당 메시지가 개인키 소유자에 의해 작성되었음을 증명할 수 있으며, 송신자는 나중에 메시지 전송 사실을 부인할 수 없게 됩니다.
 
일반적으로 비대칭키 암호화에서 공개키를 이용하여 암호화하였다면 반대로 개인키를 가지고 암호화하여 자신의 신원을 보장한다는 것이 큰 특징이다. ( 계약서의 싸인 및 서명하는 것처럼, 자신의 개인키를 가지고 전자서명을 생성한다.)
이러한 디지털 서명, 즉 전자서명 값을 시그니처(Signature)라고 한다.
 
 
실제 구현에서는 RSA와 같은 알고리즘이 대용량 데이터 암호화에 비효율적이므로, 메시지 전체가 아닌 해시값만 암호화하는 방식을 사용합니다.
 
암호화 실습(Signature) - 전자서명 생성 
이전 실습에서 생성한 비밀키를 넣고, mysign!이라는 데이터의 Signature 데이터를 생성한다.

 
암호화 실습(Signature) - 전자서명 검증 
이제, 반대로 전자서명을 검증해 보자. 공개키를 이용해서 특정한 사용자의 개인키로 전자서명된 값이 맞는지 검증한다.

 
 

X.509 & PKI

X.509와 PKI(Public Key Infrastructure)는 현대 인터넷 보안의 핵심 요소로, 디지털 인증서와 공개키 암호화를 통해 안전한 보안 통신을 가능하게 한다.
 
X.509는 디지털 인증서의 표준 형식이며, 인증서 소유자의 신원, 공개키, 유효기간, 발급자 정보 등을 포함한다. 이 표준화된 형식을 통해 다양한 시스템과 애플리케이션 간의 호환성을 보장한다.
 
PKI(Public Key Infrastructure)는 이러한 디지털 인증서를 생성, 관리, 배포하는 전체 시스템과 인프라를 의미한다.
PKI의 특징은 다음과 같다.

• PKI는 기본적으로 RSA 암호화 알고리즘을 사용한다.
• 인증서 발급자(ISSUER)는 인증기관(CA, Certificate Authority)이다.
• CA가 자신의 개인키로 서명하여 스스로 인증한 인증서를 루트 인증서라고 한다.
• 제3의 공인된 인증기관을 통해 공개키 배포의 신뢰성 문제를 해결한다.

정리하자면, PKI의 주요 목적은 X.509라는 표준화된 인증서 형식을 활용하여 CA라는 인증 기관을 통해서 사용자의 공개키를 신뢰성 있게 배포하기 위한 환경을 제공하는 것이다.

실무에서 X.509 확인해 보기 

인증서 파일 확인 
이전에는 인증서의 세부정보나, 인증서를 만들 때, csr파일의 내용을 잘 모르고 지나갔다. 하지만, 아래와 같이 이제는 낯설지 않다.(부인방지, 전자서명 등)

# csr.conf
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

 

 
PKI의 인증서들을 다루면서  pem,. crt,. cer,. key와 같은 확장자의 파일과 base64로 인코딩 된 값 등이 머릿속에서 정리되지 않은 채 사용되고 있었다.
 
crt 파일은 즉, 신뢰성 있는 서버의 공개키를 배포하기 위해 , 인증기관으로부터 서명받은(CA의 개인키로 서명)한 값일 뿐이고, HTTPS가 아닌 SSH 프로토콜(신원증명이 필요 없는 상황)의 경우에는 그냥 공개키가 사용된다.(RSA)
 
그러니까, 인증서(crt 파일)는 본질적으로 공개키의 안전한 배포와 신뢰성을 보장하기 위한 인프라스트럭처라는 것을 알고 나니 정리가 좀 되는 것 같다
 
인증서 파일(.crt)

   -----BEGIN CERTIFICATE-----
   (인증서 내용)
   -----END CERTIFICATE-----

 
개인키 파일(.key)

   -----BEGIN RSA PRIVATE KEY-----
   (RSA 개인키 내용)
   -----END RSA PRIVATE KEY-----

 
CSR(.csr)

   -----BEGIN CERTIFICATE REQUEST-----
   (CSR 내용)
   -----END CERTIFICATE REQUEST-----

 
공개키 파일(.pub)

   -----BEGIN CERTIFICATE REQUEST-----
   (CSR 내용)
   -----END CERTIFICATE REQUEST-----

결론

아마 엔지니어, 개발자들을 비롯해서 컴퓨터를 사용하는 모든 사용자라면 알게 모르게 많은 암호화 기술을 접하고 있을 것이다. 보안 전문가가 아니라면 그 동작 메커니즘을 잘 알지도 못하고 관심도 없을 수 있다. 하지만, 대부분의 현대의 발전된 보안 기술도 결국, 기초적인 암호화 기술( 대칭키/비대칭키 암호화, 해시, 전자서명)의 연속된 조합일 뿐이다.  암호화의 전문적인 알고리즘까지는 아니더라 기초이론만 잘 알아도 현재 사용하는 인터넷, 통신에 있어서 충분한 도움이 될 것이라고 생각한다.

 

작성예정 

---

 

실습: OpenSSL을 통해 사설인증서 생성(작성 중)

openssl을 통해 사설인증서를 생성해 보자.
 
인증서 생성
CA 키 및 인증서 생성

# CA 개인키 생성
openssl genrsa -out ca.key 2048

# CA 인증서 생성
openssl req -x509 -new -nodes -key ca.key -subj "/CN=kubernetes" -days 10000 -out ca.crt

 
서버 키 생성
이 단계는 서버의 개인키를 생성

# 서버 개인키 생성
openssl genrsa -out server.key 2048

 
CSR(Certificate Signing Request) 생성
이 단계에서는 서버 개인키를 사용하여 인증서 서명 요청(CSR)을 생성합니다. csr.conf 파일에는 인증서에 포함될 정보(CN, 대체 이름 등)가 정의되어 있어 한다.

# 서버 CSR 생성
openssl req -new -key server.key -out server.csr -config csr.conf

 
서버 인증서 서명 및 생성
이 단계에서는 CA의 개인키를 사용하여 서버의 CSR에 서명하고, 서명된 서버 인증서(server.crt)를 생성한다.

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out server.crt -days 10000 \
    -extensions v3_ext -extfile csr.conf

 
PEM 파일 생성
이 단계에서는 서버 인증서와 개인키를 하나의 PEM 파일로 합칩니다. HAProxy와 같은 프록시 서버에서 사용하기 위함입니다.

# 서버 인증서와 개인키를 하나의 PEM 파일로 합치기
cat server.crt server.key > ssl.pem

 

• 공인 CA(예: DigiCert, Let's Encrypt 등)가 서명한 인증서를 사용하는 경우:
  • 클라이언트는 아무것도 설치할 필요가 없습니다.
  • 공인 CA의 인증서는 이미 브라우저/OS에 신뢰할 수 있는 인증서로 등록되어 있기 때문입니다.
• 사설 CA(직접 생성한 CA)가 서명한 인증서를 사용하는 경우:
  • 클라이언트는 CA 인증서(ca.crt)를 신뢰할 수 있는 인증서로 등록해야 합니다.

Haproxy 인증서 등록(TODO)
 
클라이언트 인증서 등록(TODO)
질문) 왜 클라이언트에서는 루트인증서(ca.crt) 파일만 등록하면 서버인증서를 등록하지 않고 https 통신이 가능한지?
두 가지 케이스가 있긴 함.

• 공인 CA(예: DigiCert, Let's Encrypt 등)가 서명한 인증서를 사용하는 경우:
  • 클라이언트는 아무것도 설치할 필요가 없습니다.
  • 공인 CA의 인증서는 이미 브라우저/OS에 신뢰할 수 있는 인증서로 등록되어 있기 때문입니다.
• 사설 CA(직접 생성한 CA)가 서명한 인증서를 사용하는 경우:
  • 클라이언트는 CA 인증서(ca.crt)를 신뢰할 수 있는 인증서로 등록해야 합니다.
  • server.crt는 등록할 필요가 없습니다.

# 정리  필요!
왜 CA 인증서만 등록해야 하나요?
신뢰 체인의 원리:
- 클라이언트는 서버가 제공하는 인증서(server.crt)를 받습니다.
- 이 인증서가 신뢰할 수 있는 CA에 의해 서명되었는지 확인합니다.
- 따라서 CA 인증서(ca.crt)가 신뢰할 수 있는 인증서로 등록되어 있어야 합니다.
서버 인증서는 서버가 제공:
- SSL/TLS 핸드셰이크 과정에서 서버는 자동으로 자신의 인증서(server.crt)를 클라이언트에게 전송합니다.
- 따라서 클라이언트가 미리 server.crt를 등록할 필요가 없습니다.
CA 인증서의 역할:
- CA 인증서는 서버 인증서의 서명을 검증하는 데 사용됩니다.
- 클라이언트는 CA 인증서를 사용하여 서버 인증서가 실제로 해당 CA에 의해 서명되었는지 확인합니다.

요약
HAProxy 설정: ssl.pem 파일(server.crt + server.key)을 사용
클라이언트 설정:
- 사설 CA를 사용한 경우: ca.crt 파일만 신뢰할 수 있는 인증서로 등록
- 공인 CA를 사용한 경우: 아무것도 등록할 필요 없음
server.crt 파일: 클라이언트가 미리 등록할 필요 없음 (서버가 SSL/TLS 연결 시 자동으로 제공)
따라서, 귀하의 시나리오에서는 클라이언트에 ca.crt 파일만 등록하면 됩니다. server.crt 파일은 등록할 필요가 없습니다.

PKI 실습 : Kubernetes(작성중)

1. 개인 키 생성
2. csr 생성
3. k8s csr 리소스 생성 : 쿠버네티스 루트 인증서로 요청(k8s 루트 인증서 비밀키로 서명해 반환)
4. csr 승인
5. crt 파일 추출
6. --client-certificate=gasida.crt --client-key 등록하여 사용하기.

결론 : 쿠버네티스는 내부적으로 루트 인증서를 승인하고 요청하는 Resource를 지원. 개별적으로
쿠버네티스 사용자 인증 인가 메커니즘

• 인증서의 CN 값으로 사용자 식별:
  • 쿠버네티스 API 서버는 클라이언트 인증서의 CN(Common Name) 필드를 사용자 이름으로 사용합니다.
  • O(Organization) 필드는 사용자가 속한 그룹으로 해석됩니다.
• 인가는 RBAC로 설정:
  • 식별된 사용자/그룹에 대한 권한은 RBAC(Role-Based Access Control) 시스템을 통해 설정합니다.
  • Role/ClusterRole과 RoleBinding/ClusterRoleBinding을 사용하여 권한을 정의하고 할당합니다.

CN 사용의 요약

• Docker 이미지 서명에서는 인증서의 CN을 서명자 식별

요약
CN의 원래 용도:
- 웹 서버 인증서에서는 도메인 이름
- 클라이언트 인증서에서는 개인/조직 이름
- 각 애플리케이션 도메인마다 다른 의미로 사용
쿠버네티스의 특별한 해석:
- CN을 사용자 이름으로 해석
- O를 그룹 멤버십으로 해석
- 이는 쿠버네티스가 정의한 규칙이며, X.509 표준의 원래 의도와는 다소 다름
다양한 시스템별 활용:
- 각 시스템은 자체적인 규칙에 따라 X.509 인증서의 필드를 해석
- 인증서는 유연한 구조로, 다양한 시스템에서 다양한 방식으로 활용 가능
- 따라서, CN의 쓰임은 인증서를 사용하는 애플리케이션이나 시스템에 따라 다르게 해석되고 활용됩니다. 쿠버네티스는 자체적인 인증 메커니즘에 맞게 CN을 사용-자 이름으로 해석하는 특별한 규칙을 정의했습니다.

 
쿠버네티스에는 User 객체가 없어 사용자 목록을 직접 확인할 수 없다는 점이 맞습니다. 이는 쿠버네티스가 사용자 관리를 외부 시스템에 위임하기 때문입

쿠버네티스에서 User 객체 없이 RBAC 권한 관리하는 방법

• 쿠버네티스는 사용자를 단순히 문자열 식별자로 취급합니다
• 사용자 이름으로 서비스 요청 시, rolebinding의 subject 목록들과 비교.
• 쿠버네티스는 사용자 관리를 외부 시스템에 위임하여 유연한 사용을 위함.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
subjects:
- kind: User          # 사용자 유형
  name: "developer"   # 사용자 식별자 (문자열)
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

 
그룹을 통한 인증 예시

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-binding
  namespace: default
subjects:
- kind: Group
  name: "dev-team"  # O 값과 일치
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

 
쿠버네티스 RBAC실습
RBAC(Role-Based Access Control)은 쿠버네티스에서 사용자와 그룹의 권한을 관리하는 메커니즘입니다. 이를 통해 특정 네임스페이스나 클러스터 전체에 대한 세분화된 접근 제어가 가능합니다.
팀에 신입 데브옵스 엔지니어가 합류할 때, 신입 엔지니어에게 온보딩을 위한 클러스터 권한을 부여하는 상황을 가정해 봅시다.
실습 설명

• 신입 엔지니어(junior-devops)가 우리 팀에 합류했습니다.
• 신입 엔지니어에게는 다음과 같은 권한을 부여하려 합니다:
  • test 네임스페이스: 모든 리소스를 자유롭게 생성/수정/삭제 가능 (연습용)
  • dev 네임스페이스: 읽기만 가능 (실제 개발 환경 참고용)
• 신입 엔지니어를 위한 인증서를 생성하여 안전하게 접근할 수 있도록 합니다.

user-facing role(공식문서 참고.)

• admin
• edit
• view

네임스페이스 생성

# 테스트 네임스페이스 생성 (신입 엔지니어가 자유롭게 사용)
kubectl create ns test

# 개발 네임스페이스 생성 (실제 개발 환경)
kubectl create ns dev

# 개발 환경에 샘플 애플리케이션 배포 (참고용)
kubectl run nginx --image=nginx:alpine -n dev 

RBAC 권한 설정

# junior-devops 그룹에 test 네임스페이스에 대한 admin 권한 부여
kubectl create rolebinding junior-test-admin \
  --clusterrole=admin \
  --group=junior-devops \
  --namespace=test

# junior-devops 그룹에 dev 네임스페이스에 대한 view 권한 부여
kubectl create rolebinding junior-dev-view \
  --clusterrole=view \
  --group=junior-devops \
  --namespace=dev

# 확인 
kubectl rbac-tool lookup junior-devops
  SUBJECT       | SUBJECT TYPE | SCOPE       | NAMESPACE | ROLE  | BINDING
----------------+--------------+-------------+-----------+-------+--------------------
  junior-devops | Group        | ClusterRole | dev       | view  | junior-dev-view
  junior-devops | Group        | ClusterRole | test      | admin | junior-test-admin

신입 엔지니어를 위한 인증서 생성

• 인증서 생성 시, O 혹인 CN 매우 중요 해당 값을 통해 RBAC 권한 확인.

# 1. 개인키 생성
openssl genrsa -out junior.key 2048

# 2. CSR 생성 - junior-devops 그룹 지정
openssl req -new -key junior.key -out junior.csr \
  -subj "/O=junior-devops/CN=junior-engineer"

# 3. CSR 내용을 base64로 인코딩
JUNIOR_CSR=$(cat junior.csr | base64 | tr -d '\n')

# 4. CSR 요청 생성 및 제출
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: junior-engineer-csr
spec:
  signerName: kubernetes.io/kube-apiserver-client
  groups:
  - system:authenticated
  request: ${JUNIOR_CSR}
  usages:
  - digital signature
  - key encipherment
  - client auth
EOF

# 5. CSR 승인
kubectl certificate approve junior-engineer-csr

# 확인 
kubectl get csr
NAME                  AGE    SIGNERNAME                            REQUESTOR          REQUESTEDDURATION   CONDITION
junior-engineer-csr   15s    kubernetes.io/kube-apiserver-client   kubernetes-admin   <none>              Approved,Issued

# 6. 승인된 인증서 추출
kubectl get csr junior-engineer-csr -o jsonpath='{.status.certificate}' | base64 -d > junior.crt

kubeconfig 설정

# 신입 엔지니어를 위한 인증 정보 설정
kubectl config set-credentials junior-engineer \
  --client-key=junior.key \
  --client-certificate=junior.crt

kubectl config set-context junior-test-context --cluster=kind-myk8s --user=junior-engineer

kubectl config use-context junior-test-context

kubectl get pod -n test

권한 확인 및 검증

kubectl get pod -n default 
Error from server (Forbidden): pods is forbidden: User "developer" cannot list resource "pods" in API group "" in the namespace "default"

kubectl get pod  -n test
No resources found in dev namespace.

kubectl get pod -n dev
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          3m

kubectl run nginx2 --image=nginx:alpine -n dev
Error from server (Forbidden): pods is forbidden: User "junior-engineer" cannot create resource "pods" in API group "" in the namespace "dev"

# krew 플러그인 rbac-tool을 활용하여 정보 조회.
kubectl rbac-tool lookup dev-team       
  SUBJECT  | SUBJECT TYPE | SCOPE       | NAMESPACE | ROLE | BINDING                   
-----------+--------------+-------------+-----------+------+---------------------------
  dev-team | Group        | ClusterRole | dev       | edit | dev-team-edit             
  dev-team | Group        | ClusterRole | prd       | view | dev-team-view-production 

Reference 

https://www.youtube.com/watch?v=MR4sCU82tgo