글을 쓰기 앞서 이 책을 참조하였습니다.

 

쿠버네티스 인증에는 어떤 것들이 있나요?

 

  • Service Account 오브젝트를 통한 인증
  • Open ID Connect  (OAuth) 와 같은 third party 를 통한 인증
  • Certificates (인증서)를 통한 인증  등이 있습니다.

 

쿠버네티스 사용 시 인증이 왜 필요한가요?

 

운영중인 서비스에 대한 보안 강화 및 기밀 정보 보호의 목적 뿐만 아니라,

사내 조직 간의 쿠버네티스 동시다발적 제어 및 접근에 있어서

RBAC (Role Based Access Control)  역할에 따른 최소 권한 할당에 있어서 중요한 역할을 합니다.

 

 

쿠버네티스의 인증과정은 어떻게 이루어지나요? 

일반적으로 위와 같은 과정으로 Kubernetes API Server 에서 인증이 진행됩니다.

  1. Kubectl 명령어를 통해 Kube-API Server에 HTTP Handler 에 요청을 전송
  2. API Server 는 해당 클라이언트가 쿠버네티스의 사용자가 맞는지 확인
  3. API Server 는 해당 클라이언트가 요청한 기능을 실행할 권한이 있는지 확인 
  4. 관리자의 정책에 따라 Admission Control 을 수행합니다.

 

API Server 가 인증을 어떻게 하나요?

 

앞서 설명했다시피  Service Account, third party , Certificates 와 같은 방법들이 있습니다.

우선 Service Account 오브젝트를 활용하여 인증하는 방법을 설명하겠습니다.

 

Service Account (SA) 는 체계적으로 권한을 관리하기 위한 쿠버네티스 오브젝트입니다.

k create sa [Service Account Name] -n [ namespace ]

 위와 같이 SA 생성이 가능하며, 다음과 같이 활용할 수 있습니다.

그러나, SA 오브젝트만 있어서는 인증이 불가능하며, SA 에 직접  접근 대상, 접근 권한, 권한 주체를 설정해주어야 합니다.

Role 이라는 오브젝트로 아래와 같이 rule 을 적용하여  SA에 RoleBinding 을 통해 Role 을 할당해 주어야 합니다.

또, Namespace 에 속한 리소스들을 대상으로 다루는 Role 과  Cluster 전체 리소스들을 다루는 Cluster Role 이 있습니다.

 

그러면, Kubectl 을 통해서만 SA 를 활용할 수 있나요?

 

Application 에서 또한 HTTP API 를 통해 API Server에 요청이 가능합니다.

우선, HTTP API 요청을 위한 API Server Endpoint 로  다음과 같습니다.

기본적으로 API Server 는 HTTPS 요청만을 처리하기 때문에, 인증에 대한 자격증명이 필요합니다.

SA 오브젝트를 생성ㅇ하면 해당 SA에 대응하는 Secret 이 자동으로 생성됩니다.

해당 Secret 에는 ca.crt , token , namespace 가 base64 로 인코딩되어 저장되어 있습니다.

 

이에 Application 에서는 Token 정보를 읽어 API Server 에 JWT 인증을 시도합니다.

이후, 기존 SA 정보를 바탕으로 인증 및 인가 과정을 처리하게 됩니다.

그리고, API Server 의 몇몇 특정 경로들은 접근 제한이 되어있으나, Cluster Role 을 통해 아래와 같이 설정하여 접근이 가능합니다.

 

 

마지막으로, 다음과 같이 SDK 를 통한 SA 인증이 가능합니다.

1. SA 를 생성 한 후 Role 과 Role Binding 을 적용해줍니다. 

2. 대상 Pod 에 SA 이름을 명시합니다.

3. 해당 Pod 의 Container 에 자동으로 Secret 정보가 마운트됩니다.

4. Token 정보를 읽어 기존 default namespace 의 kubernetes 서비스를 통해 API Server 에 인증을 시도합니다.

 

 

RBAC 이 왜 중요한건가요?

추후 작성 예정

Admission Controller 가 뭔가요?

추후 작성 예정

OIDC 나 Certificates 를 통한 인증은 어떻게 하나요??

새로운 글로 작성 예정

 

 

Time Zone Error

RDS 의 Timezone 설정은 기본값으로 "UTC" 로 되어있습니다.
시간대가 서울을 기준으로 한다면 RDS의 파라미터 그룹 설정을 다시 해주고 재부팅해야 합니다.

1. 파라미터 그룹 생성 

2. time_zone 파라미터를 [Asia/Seoul] 로 설정해줍니다.

3. 기존 DB 수정의 추가 구성에 들어가 파라미터 그룹을 생성한 파라미터 그룹으로 변경합니다

4. DB 를 재부팅합니다.

 

 

 

Q. IP Class 는 뭔가요?

 

하나의 네트워크가 몇 개의 호스트를 가질 수 있는지에 대한 단위 개념입니다.

즉, 네트워크와 호스트를 구분할 수 있는 단위라고 생각합니다.

 IP Class 는  A  ~  E Class 가 있습니다.

 

Q. 네트워크와 호스트를 구분할 수 있는 것은 서브넷 마스크 아니었나요?

 

IP Class 도 결국 /8 , /16, /24 .. 과 같이  Default Subnet Mask 를 가집니다.

사실 서브넷팅 하는 방법에 있어 Classful 방식으로 IP Class 를 활용하는 방법

Classless 방식으로 IP Class 개념없이 서브넷팅 (VLSM) 하는 방법이 있습니다.

 

Q. IP Class 의 각 Class 는 무엇을 의미하나요? 

 

자세한 설명은 여기를 참조하세요

 

A Class  :  Network : 0.0.0.0  ~ 127.255.255.255      SubnetMask  255.0.0.0       Hosts : 16,777,214

B Class  :  Network : 128.0.0.0 ~ 191.255.255.255      SubnetMask  255.255.0.0       Hosts : 65,534

C Class  :  Network : 192.0.0.0 ~ 223.255.255.255      SubnetMask  255.255.255.0       Hosts : 254

D Class  :  Network : 224.0.0.0 ~ 239.255.255.255      특수목적용  ( 멀티캐스트 )

E Class  :  Network : 240.0.0.0 ~ 247.255.255.255      IP 연구용

 

A , B Class 의 경우 기업이 아닌경우  호스트 수가 매우 크기 때문에 낭비가 심할 수 있습니다.

그래서 대부분 네트워크를 나눌 때 C Class 를 따릅니다.

이러한 이유로 사설 네트워크망은  192 로 시작하는 경우가 많습니다.

 

Q. 제 IP 는 59.142.xxx.xxx 인데  어떻게  사설 IP로 사용할 수 있다는 건가요?

 

NAT ( Network Address Translation ) 를 통해서  공인망(인터넷망) <~> 사설망  통신이 가능합니다.

 

 Q. NAT 는 또 뭔가요?

 

NAT 는 주소를 변환해주는 서비스입니다.

  -  IP 주소 절약  :  하나의 공인  IP 주소를 여러 호스트가 나누어 사용할 수 있습니다.

  - 보안   :  NAT 특정으로 IP 를 숨길 수 있는 기능이 있습니다.

 

출처 : https://rednooby.tistory.com/25

동작 방식   

예 )  내 컴퓨터에서 구글로  '모코코'를 검색합니다.    [ 사설 IP : 10.0.0.1   , 공인 iP : 150.150.0.1  , 구글 IP : 200.100.10.1 ]

1.  내 컴퓨터 (사설 IP) 에서 구글에 패킷전송 

   ( 패킷 헤더에  Src/Dst IP 가 기록됩니다.   Src : 10.0.0.1 / Dst : 200.100.10.1  ,  출발지,도착지 IP 주소입니다. )

2. 기본 게이트웨이에서 외부로 나가는 패킷을 인식합니다.

    2-1 . 출발지 IP 주소를 게이트웨이 자신의 공인 IP 주소로 변경합니다.

    2-2 . 이때, NAT 테이블에 보관합니다.  (  10.0.0.1 ~> 150.150.0.1 ) 

 

https://www.stevenjlee.net/

3. 구글 웹서버에서  패킷을 수신 후 처리를 수행합니다.

   3-1 .  응답 패킷을 전송합니다.      ( Src : 200.100.10.1    /  Dst : 150.150.0.1 )

4. 기본 게이트웨이에서 응답패킷을 수신합니다.

  4-1 . 기록해두었던 NAT 테이블을 참조하여 도착지 주소를 사설 IP (10.0.0.1 ) 로 변경합니다.

 

추가적으로 NAT의 여러 쓰임에 대해 설명하자면

 

SNAT  ( Source NAT ) :   사설망 ~> 공인망   

DNAT  ( Destination NAT )  공인망 ~> 사설망  

 

추가적인 내용은 SNAT , DNAT 를 확인하세요

 

 

주소할당 방식에 따른 NAT 

 

Static NAT  ( 1:1 NAT )

 - 공인 IP 와 사설 IP 주소가 1:1 로 매칭되는 방식입니다.

    -  IP 절약 효과는 없으며  ,  Port Forwarding 목적으로 사용합니다.   ( 사설 서버 IP 를  공인 IP 로 매핑하기 위한 목적 )

    -  Port Fowarding  :  하나의 서버에서 여러 서비스를 운영중일 때

                                      특정 서비스에 임의의 포트를 지정하여 해당 포트를 통해 서비스의 경로를 지정하는 방법입니다.

Dynamic NAT  ( N:N NAT )

  - 여러 개의 공인 IP 주소 대비  사설 IP가 더 많을 경우  현재 사용중이지 않은 공인 IP 에 사설 IP 를 동적으로 매핑합니다.

     - IP 절약 효과를 위해 사용합니다.

 

PAT  ( Port Address Translation ) 또는 PNAT  ( Port NAT )

  - 공인 IP 1개와  여러 개의 사설IP를 매핑합니다.  ( 공인 IP 의 포트마다  각각의 사설 IP 의 포트와 연결할 수 있습니다. )

 

자세한 내용은 여기를 참조하세요

 

 

 

Q. 이전에 소개된 서브넷팅은 뭐고 VLSM 은 뭔가요?

 

서브넷팅은  서브넷 ( Sub network )을 나누는 방법입니다.

 

우리가 할당받은 네트워크를 좀 더 효율적으로 사용하기 위해 여러 개의 서브 네트워크로 쪼개서 사용할 수 있습니다.

서브넷팅을 하는 방법으로 2가지를 위에서 소개했는데,

 Classful  :  기존 IP Class 별 Default Subnet Mask 를 사용합니다.   /8 , /16,  /24 ...

 Classless :  IP Class 의 개념없이 서브넷팅을 하는 방법입니다.   ( VLSM 한 경우 )  ( CIDR 표기 )

 

 예 )  필요한 IP 개수가 있을 때    ex. 컴퓨터 30대와 연결해야 하는 경우   (  임의의 네트워크 배정  ~>  193.1.2.0/24 )

 

  /24  (SubnetMask)  =  255.255.255.0  

   1111 1111 . 1111 1111 . 1111 1111 . 0000 0000   <~ 여기서 서브넷팅

 

  30대가 필요하니 최대한 낭비없이 할당하는 것이 중요합니다.

8 bit 에 30개를 포함시키기 위해서는   2^5 = 32 개   2진법 => 11100000  

따라서, 서브네트워크 개수는 ( 111   10진법 => 8 개 )     그렇다면, 서브넷 표기는  /24 + 3 = /27  ( CIDR 표기 ) 

 현재 생성한 서브네트워크는 8개로  각 서브네트워크 마다 32 개의 호스트를 가집니다.

193.1.2.0/27  193.1.2.32/27
193.1.2.64/27  193.1.2.96/27
193.1.2.128/27  193.1.2.160/27
193.1.2.192/27 193.1.2.223/27

 

VLSM ( Variable Length Subnet Mask ) :  가변 길이 서브넷 마스크

 위의 예로 설명한 방법이 VLSM 방식입니다.   

 ( 이 경우  반드시   xxx.xxx.xxx.xxx / xx   형식의 CIDR 표기를 해주어야 합니다.)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

'📡Network' 카테고리의 다른 글

Load Balancer  (0) 2022.12.11
IP  (0) 2022.08.14
IPtables  (0) 2022.08.13

+ Recent posts