안녕하세요.

gitlab 과 keycloak을 연동해서 인증시스템을 구축해볼것이다.

그전에 관련 용어 설명

keycloak - 오픈소스 IAM 솔루션

okta - 상용 IAM 솔루션

IAM(Identity and Access Management) - User ID, 암호를 통해 계정을 생성&관리하고 권한을 할당하여 접근제어(인증, 인가, 감사등)

즉 IAM이란 어떤 솔루션이나 프로토콜을 의믜하는게 아니고 보안행위 및 규칙등을 의미하고

IAM을 하기 위한 솔루션으로 keycloak 과 Okta등이 있는것.

더 자세히 들어가보면 IAM 솔루션들의 구성요소, 프로토콜이나 보안 정책등을 알아보자면

1. SAML - 인증정보를 중앙 관리하여 한번의 디지털 서명(ID, PW)으로 설정돼있는 모든 리소스(SAML을 제공하는)에 접근 가능.
   로직은 다음과 같다.
   요청(사용자가 로그인 시도) > 검증(SAML과 IDP 연결) > 로그인(ID, Password 입력창 표시) > 토큰생성(사용자 정보 올바를시 SAML 토큰이 전송되어 서버에 로그인)

2. OAuth - 한번의 로그인(자격증명 성공)으로 얻은 토큰을 다른서비스에 로그인(인증)시 해당 토큰을 전달하는데 사용(ID,PW를 전달해주는게 아님). 단 조건은 사전에 IdP에서 사용자의 승인을 받아 리소스 서버에 토큰을 발행할수 있어야 함.

로직은 다음과 같다.

요청(사용자가 로그인 시도) > 선택(로그인 방법으로 타사 권한 인증 선택) > 로그인(인증 서버가 액세스 토큰 생성하여 리소스 서버에 전송) > 연결(리소스 서버가 토큰 확인후 접근 허용)

SAML과 OAuth의 유사점과 차이점은?

먼저 유사점은 SAML과 OAuth를 사용(한번의 로그인)으로 여러 서비스의 접근이 가능(SSO)해지는것.

예를들어 구글(IDP)계정을 가지고 깃랩도 로그인하고 페북도 로그인하고 플럼버도 로그인하고.. 이런것들이 SAML 혹은 OAuth를 가지고 SSO 기능을 구현했다라고 볼수있음.

차이점은 SAML=인증 / OAuth = 인가이다. SAML의 경우 구글(IDP)계정들의 아이디/패스워드들을 가지고 인증을 받아 다른 서비스에 로그인하는것.

OAuth는 구글에서 받은 토큰을 로그인 하려는 다른 서비스에 등록, 즉 권한을 허가 받아 다른서비스에 로그인하는것

로그인에 초점을 맞추면 둘중 하나만 사용하면 되고.

좀더 보안을 강화하려면 일단 로그인은 SAML(인증된자만)로 접근가능하도록 하고 그 서비스 로그인 이후의 하위서비스 접근은 OAuth(인가된자만)로 접근 가능하도록 처리하면 보안을 좀 더 강화할 수 있다

3. OIDC - 인증을 위해 OAuth에서 인증부분을 확장하여 구현된 프로토콜

OAuth에서 openid 스코프가 포함돼있으면 OIDC임. oauth 스코프에 openid가 있으면 oauth의 본래 목적인 액세스토큰(인가정보)외에 추가로 인증정보인 ID토큰(JWT)을 반환함.
##인증과 인가의 차이 : 인증 - 신원 검증 / 인가 - 권한 부여

즉 OIDC는 인가가 아닌 인증을 위해 OAuth에 인증이 확장된 개념이다.

앞의 내용을 다 이해했다면 OAuth와 OIDC를 각가 언제 사용해야 하는지 이해했을듯 하다.

그럼 둘다 인증이 목적인 SAML과 OIDC은 특징 및 장단점이 뭐고 각각 언제 쓰일까 ?

SAML - XML 기반, OIDC보다 상대적으로 느림, 메시지 크기가 큼, 20년전부터 널리 사용됐기에 스탠다드함. 따라서 기존 시스템과의 호환성이 높음. 기존 엔터프라이즈 환경에서 더 잘 어울려 왔음

OIDC - JSON 기반, 처리속도가 빠르고 사이즈가 작음. 최근(5~7년전)에 각광받고 있음. 여러 환경에서 사용됨.

장단점만을 본다면 OIDC가 더 좋아보이나 기존 엔터프라이즈 환경에서 SAML이 이미 많이 사용되고 있었기에 보안규정 및 지침등이 SAML에 맞게 표준화 돼 있었음. 따라서 아주 빡세게 보안규정을 지켜야한다면 OIDC보단 그에 맞는SAML을 채택하는게 맞고 그게 아니라면 OIDC가 더 유리하다고 판단됨

하여 아직까진 SAML을 많이 사용하나 OIDC도 많아지는 추세임.

그외 

SSO - 싱글사인온. 하나의 인증/인가로 해결하는것

IdP - identitiy provider. 즉 인증/인가정보를 제공하는곳.(구글, 카카오, 페이스북등)

JWT - Json웹 토큰 - 사용자 인증정보를 json 구조로 구성. OIDC가 JWT로 인증을 주고받음

karmada 란

1. CNCF 프로젝트
2. kubefed 단점 보완
3. 클러스터간 리소스 공유&배포
4. 워크로드 분산 가능
5. 정책기반 배포 및 관리가 가능
6. 클러스터간 고가용성 지원

• 기본적인 통신 플로우는 k8s 통신과 동일하게
  api서버를 기반으로 통신
  
• karmada의 컨트롤플레인이 각 클러스터의 API 서버와 통신하는 구조

1. PropagationPolicy 추가시 PolicyController가 Resource Binding 생성
2. Resource Binding 시 Binding Controller가 Manifest 를 토대로 목적 클러스터에 Execution 생성
3. Execution 생성시 Execution Controller가 목적 클러스터에 리소스를 배포

propagation policy란 
PropagationPolicy란 워크로드를 어떤 클러스터에 어떻게 분산할지 정의하는 규칙으로 멀티클러스터환경을 위해 진행되는 karmada의 핵심 개념

• ClusterAffinity: ClusterName, Label, Field에 기반 스케쥴링
• SpreadConstraint: 여러 클러스터에 고르게 분산
• ReplicasScheduling: 워크로드복제본(동일 pod)을 여러 클러스터에 어떻게(Duplicated, Wdighted, Custom) 스케쥴링할지 결정
• Toleration: 기존 k8s 스케쥴링기법을 그대로 사용

karmada 설치 방법

git clone https://github.com/karmada-io/karmada.git; karmada/hack/local-up-karmada.sh

karmada join CLUSTER_NAME --cluster-kubeconfig=/path/to/your/cluster-kubeconfig.yaml

karmada 를통해 리소스 배포 방법

placement:

    clusterAffinity:

      clusterNames:

        - member1

        - member2

를 통해서 배포할 클러스터를 정해준다 - clusterAffinity 방식 weighted 를 기준으로 분산하는데 target cluster 모두 가중치는 1로 줬기에 균등분산하여 nginx 애플리케이션을 member1,2 각각의 클러스터에 분산 배치하여 고가용성 및 부하분산 향상

pod - 컨테이너, 라벨, 노드스케쥴등으로 설정해서 컨테이너 실행, 파드에 메모리 사용량 미리 적어줄수있음. 안적어주면 문제생김 - 메모리 부족시 다른 파드의 메모리를 사용하여 애플리케이션이 불안정할거나 파드를 스케쥴링할때 마스터노드에서 얼마나 할당해야하는지 메모리 요구사항을 모르기때문에 파드가 다른 노드에 할당되지 않을수있음 마지막으로 자원 낭비

ㄴ라벨 - 키/밸류 형식의 라벨

ㄴ노드스케쥴 - 파드는 노드위에 올라가는데 노드를 직접 지정하거나 아니면 K8S 에서 자동으로 

리밋 - CPU- 낮춤, 메모리-파드 종료

서비스 - 파드는 재시작하면 아이피가 변경되기때문에 서비스 달아서 파드 연결해줘야함.

ㄴ클러스터아이피 - 외부에서는 접근안되고 클러스터 내부에서만 아이피로 접근 가능함.

ㄴ노드포트 - 클러스터아이피 기능 + 파드가 있는 노드에만 포트가 추가되는게 아니고 파드가 없는 노드까지. 모든 노드에 포트 할당함

ㄴ로드밸런서 -  앞단에서 로드밸런싱으로 파드에 접근되도록(NGINX)

볼륨 - 

EMPTY DIR - 컨테이너들끼리 데이터를 공유하기 위해 사용, 파드 생성시 같이 생성되고 지우면 같이 지워짐

HOST PATH - 경로 지정해서 사용되며 노드에 저장됨, 파드 재생성시 다른노드에 생성되면 당연히 볼륨 사용불가. 다만 노드별로 마운트해줌 사용은 가능

PV/PVC - pod > pvc > pv > volume 형식으로 연결

config map - 환경변수 (이미지 1개에 환경변수를 준다) / secret - 보안 환경변수 secret(base64)으로 설정(메모리에 저장됨)

namespace - 서비스&파드집합소, 네임스페이스끼리 공유안됨(pv등은 공유됨). 삭제하면 그안의 서비스도 전부 삭제됨

리소스쿼타 - 네임스페이스별로 리소스 쿼타 적용해서 더 올라가지 않도록 한다

리밋 레인지 - 네임스페이스별로 리소스 리밋을 적용해서 넘을경우 파드가 해당 네임스페이스에 들어가지 않도록 한다

컨트롤러 - 오토힐링, 오토스케일링, 소프트웨어업데이트, 잡등  오케스트레이션 기능들

리플리카셋 - 오토힐링,오토스케일링, 자원할당(파드할당) 기능 

탬플릿 - 탬플릿에 설정돼있는대로 오토힐링함, 이걸로 버전업그레이드 가능

replicas - 스케일인, 스케일아웃. 

셀렉터 - 파드 지정해서 실행

deployment - 파드 배포 방식

recreate - 기존 파드 삭제하고 새로운 파드 생성, 다운타임 발생

롤링 업데이트 - 기존 파드 그대로 두고 새로운 파드 생성후 기존 파드 삭제, 생성/삭제하는 시간동안 기존 파드로 접근되는 문제가 있음. 다운타임 없음.

블루/그린 - 리플리카스를 이용하여 새로운 파드 생성후 서비스를 새로운 파드로 보도록 라벨 변경. 다운타임없고 기존파드로 접근되지도 않음. 롤백도 쉬움. 가장 많이 사용

카나리 배포 - 새버전의 파드를 생성후 일부 트래픽을 새버전의 파드로 가도록하여 테스트.

데몬셋 - 모든 노드에 파드가 하나씩 생성. 프로메테우스처럼 모든 노드에 설치되야할 서비스들 설치할때 사용

잡/크론잡 - 임시로 사용할 파드들. 프로세스가 실행되지 않으면 파드 종료.(삭제되는게아님)

파드의 라이프사이클 - 파드나 컨테이너의 state 확인

서비스 - headless, endpoint, external name

ingress - 로드밸런싱이나 카나리 업그레이드 하기 위해

네트워크 - 파드네트워크와 서비스 네트워크, 실 서버의 네트워크를 다르게 줘야함.