Skip to content

태그: auth

총 5개의 글이 있습니다.

k8s에서 kubectl과 같은 커맨드를 사용해 API를 요청하는 과정은 크게 3가지로 구성되어 있다. 1. 'k8s 사용자가 맞느냐'를 판단하는 Authentication 2. 두 번째는 'API를 호출할 수 있는 권한이 있느냐'를 판단하는 Authorization 3. 마지막으로 그 요청이 적절한지를 판단하는 Admission Controller이다. Authorization와 Admission Controller는 k8s에 내장되어 있는 기능이기 때문에 사용 방법이 비교적 정해져 있는 반면, 첫 번째 단계인 Authentication은 이렇다 할 정답이 딱히 정해져 있지 않다. 물론 k8s의 자체 인증 기능인 ServiceAccount, 인증서 등을 사용할 수는 있지만, 사내에서 LADP, Go

k8s 클러스터 root CA를 통한 사용자 인증

k8s는 기본적으로 root CA 인증서를 스스로 발급해 사용한다. 이 인증서를 이용하면 별도의 Third-party 연동 없이도 User와 Group을 사용할 수 있다. 단, 이 방법은 여러모로 한계점이 많기 때문에 가능하면 사용하지 않는 것이 좋다. 인증서가 유출되었을 때 revoke가 힘들기도 하고, 파일 단위로 인증 정보를 관리하는 것은 매우 비효율적이고 보안에 취약하기 때문이다. 따라서 k8s는 인증서 발급을 통한 사용자 인증은 극히 제한된 경우에만 사용하고 있다. 대표적으로는 관리자 권한을 가져야 하는 `system:master` 그룹의 인증 정보를 생성한다거나 (`/etc/kubernetes/admin.conf`), k8s의 핵심 컴포넌트에 인증서를 발급한다거나 할 때가 이에 해당한다. 우선

OIDC Authentication with Dex

OIDC (Open ID Connect) 인증 방법은 OAuth2 위에서 동작하는 인증으로, Github이나 Google과 같이 서드 파티에서 부여받은 OAuth 권한을 통해 쿠버네티스의 인증을 수행한다. 기존에 사용하던 OAuth 인증 방법을 쿠버네티스에 그대로 가져온다고 생각하면 이해하기 쉽다. OIDC 인증 방법은 OAuth + JWT 토큰을 사용한다는 점에서 Webhook Token 인증 방법과 차이점을 갖는다. OAuth 토큰을 관리하기 위한 중간 서버를 구현한 [Dex]( 사용하여 OIDC 인증을 구현해보자. Dex Concept Dex는 서드 파티로부터 OAuth 인증 토큰을 가져와 관리하는 인증 도구이다. OAuth를 사용하기 위

Security Context for a Pod or Container

A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to: Descretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID)](

Token Webhook with Guard

Webhook 서버에 인증 데이터를 전달한 뒤, 클라이언트가 유효한지 인증하여 Third party에 권한을 부여하는 Webhook Token 인증 방법에 대해 알아보자. 1. 사용자는 미리 인증 데이터를 발급받아 놓고, 2. 사용자가 인증 데이터를 Bearer 헤더에 담아서 REST API 요청을 보내면 3. API 서버는 클라이언트가 유효한지를 검증하기 위해 Webhook 서버에 인증 데이터를 전달한다. 4. Webhook 서버는 해당 데이터를 검사한 뒤, 인증 여부를 API 서버에 반환하는 간단한 방식으로 되어 있다 Token Webhook, OIDC 중 어느 방법을 선택하든지에 상관 없이 클라이언트는 HTTP의 Bearer 헤더에 인증 데이터를 담아서 보내기만 하면 된다. 클라이언트는 인증