Kubernetes 액세스 구성
사용자 위장을 사용한 액세스 구성
- 사용자 위장 작업 흐름
- RBAC 권한 부여
Kubernetes API를 통한 클러스터 액세스
- GitLab CLI(권장)를 사용한 로컬 액세스 구성
- 개인 액세스 토큰을 사용하여 로컬 액세스 매뉴얼으로 구성하기
관련 주제

사용자에게 Kubernetes 액세스 권한 부여

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated Status: Beta

GitLab 16.1에서 도입됨, environment_settings_to_graphql, kas_user_access, kas_user_access_project 및 expose_authorized_cluster_agents라는 플래그와 함께. 이 기능은 Beta 상태입니다.
피처 플래그 environment_settings_to_graphql가 GitLab 16.2에서 제거됨.
피처 플래그 kas_user_access, kas_user_access_project 및 expose_authorized_cluster_agents가 GitLab 16.2에서 제거됨.
에이전트 연결 공유 한계가 100에서 GitLab 17.0에서 500으로 증가했습니다.

조직의 Kubernetes 클러스터 관리자로서, 특정 프로젝트 또는 그룹의 구성원에게 Kubernetes 액세스 권한을 부여할 수 있습니다.

액세스를 부여하면 해당 프로젝트 또는 그룹을 위한 Kubernetes 대시보드도 활성화됩니다.

자체 호스팅된 인스턴스의 경우 다음 중 하나를 확인하세요:

GitLab 인스턴스 및 KAS를 동일한 도메인에 호스팅합니다.
KAS를 GitLab의 하위 도메인에 호스팅합니다. 예를 들어, gitlab.com에 GitLab이 있고 kas.gitlab.com에 KAS가 있습니다.

Kubernetes 액세스 구성

사용자에게 Kubernetes 클러스터 액세스를 부여하려면 액세스를 구성하세요.

전제 조건:

Kubernetes 클러스터에 대한 에이전트가 설치되어 있어야 합니다.
개발자 역할 이상이어야 합니다.

액세스를 구성하려면 다음을 수행합니다:

에이전트 구성 파일에서 다음 파라미터를 사용하여 user_access 키워드를 정의합니다:
- projects: 멤버가 액세스해야 하는 프로젝트 디렉터리입니다. 최대 500개의 프로젝트를 승인할 수 있습니다.
- groups: 멤버가 액세스해야 하는 그룹 디렉터리입니다. 최대 500개의 프로젝트를 승인할 수 있습니다.
- access_as: 필수 항목입니다. 일반 액세스의 경우 값은 { agent: {...} }입니다.

액세스를 구성한 후, 요청은 에이전트 서비스 계정을 사용하여 API 서버로 전달됩니다. 예를 들면:

# .gitlab/agents/my-agent/config.yaml

user_access:
  access_as:
    agent: {}
  projects:
    - id: group-1/project-1
    - id: group-2/project-2
  groups:
    - id: group-2
    - id: group-3/subgroup

사용자 위장을 사용한 액세스 구성

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

Kubernetes 클러스터에 액세스를 부여하고 인증된 사용자의 위장 요청으로 변환할 수 있습니다.

전제 조건:

Kubernetes 클러스터에 대한 에이전트가 설치되어 있어야 합니다.
개발자 역할 이상이어야 합니다.

사용자 위장을 사용한 액세스를 구성하려면 다음을 수행합니다:

에이전트 구성 파일에서 다음 파라미터를 사용하여 user_access 키워드를 정의합니다:
- projects: 멤버가 액세스해야 하는 프로젝트 디렉터리입니다.
- groups: 멤버가 액세스해야 하는 그룹 디렉터리입니다.
- access_as: 필수 항목입니다. 사용자 위장인 경우 값은 { user: {...} }입니다.

액세스를 구성한 후, 인증된 사용자의 위장 요청으로 변환됩니다.

사용자 위장 작업 흐름

설치된 agentk는 다음과 같이 사용자를 위장합니다:

사용자명은 gitlab:user:<사용자명>입니다.
그룹은 다음과 같습니다:
- gitlab:user: GitLab 사용자로부터 오는 모든 요청에서 공통적입니다.
- 각 승인된 프로젝트의 각 역할에 대해 gitlab:project_role:<프로젝트 ID>:<역할>입니다.
- 각 승인된 그룹의 각 역할에 대해 gitlab:group_role:<그룹 ID>:<역할>입니다.
Extra는 요청에 대한 추가 정보를 포함하며 다음과 같습니다:
- agent.gitlab.com/id: 에이전트 ID입니다.
- agent.gitlab.com/username: GitLab 사용자의 사용자명입니다.
- agent.gitlab.com/config_project_id: 에이전트 구성 프로젝트 ID입니다.
- agent.gitlab.com/access_type: personal_access_token, oidc_id_token, 또는 session_cookie 중 하나입니다.

구성 파일의 user_access에 직접 나열된 프로젝트 및 그룹만 위장됩니다. 예를 들면:

# .gitlab/agents/my-agent/config.yaml

user_access:
  access_as:
    user: {}
  projects:
    - id: group-1/project-1 # group_id=1, project_id=1
    - id: group-2/project-2 # group_id=2, project_id=2
  groups:
    - id: group-2 # group_id=2
    - id: group-3/subgroup # group_id=3, group_id=4

이 구성에서:

사용자가 group-1의 멤버인 경우, Kubernetes RBAC 그룹 gitlab:project_role:1:<역할> 만 받습니다.
사용자가 group-2의 멤버인 경우, Kubernetes RBAC 그룹 두 개를 받습니다:
- gitlab:project_role:2:<역할>
- gitlab:group_role:2:<역할>.

RBAC 권한 부여

위장된 요청에는 Kubernetes 내부의 리소스 권한을 식별하기 위한 ClusterRoleBinding 또는 RoleBinding이 필요합니다. 적절한 구성은 RBAC 권한 부여을 참조하세요.

예를 들어, awesome-org/deployment 프로젝트(ID: 123)의 관리자가 Kubernetes 워크로드를 읽을 수 있도록 허용하는 경우, Kubernetes 구성에 ClusterRoleBinding 리소스를 추가해야 합니다:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-cluster-role-binding
roleRef:
  name: view
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
  - name: gitlab:project_role:123:maintainer
    kind: Group

Kubernetes API를 통한 클러스터 액세스

GitLab 16.4에서 도입됨.

에이전트를 구성하여 GitLab 사용자가 Kubernetes API를 통해 클러스터에 액세스할 수 있습니다.

전제 조건:

user_access 항목이 구성된 에이전트가 필요합니다.

GitLab CLI(권장)를 사용한 로컬 액세스 구성

GitLab CLI인 glab를 사용하여 Kubernetes 구성 파일을 생성하거나 업데이트할 수 있습니다.

glab cluster agent 명령어를 사용하여 클러스터 연결을 관리합니다:

프로젝트에 연결된 모든 에이전트의 디렉터리을 확인하세요:

glab cluster agent list --repo '<group>/<project>'

# 현재 작업 디렉터리가 에이전트가 등록된 프로젝트의 Git 리포지터리인 경우 --repo 옵션을 생략할 수 있습니다:
glab cluster agent list

출력의 첫 번째 열에 표시된 숫자 형태의 에이전트 ID를 사용하여 kubeconfig를 업데이트하세요:

glab cluster agent update-kubeconfig --repo '<group>/<project>' --agent '<에이전트-ID>' --use-context

kubectl 또는 기본적으로 사용하는 Kubernetes 도구로 업데이트를 확인하세요:

kubectl get nodes

update-kubeconfig 명령은 Kubernetes 구성을 검색하기 위한 자격 증명 플러그인으로 glab cluster agent get-token을 설정합니다. get-token 명령은 현재 날짜의 자정까지 유효한 개인 액세스 토큰을 생성하고 반환합니다. Kubernetes 도구는 토큰을 만료될 때까지 나머지 호출을 캐시합니다. Kubernetes 도구로의 계속된 모든 호출은 새로운 토큰을 생성할 것입니다.

glab cluster agent update-kubeconfig 명령은 여러 명령행 플래그를 지원합니다. 모든 지원되는 플래그를 glab cluster agent update-kubeconfig --help로 확인할 수 있습니다.

일부 예시:

# 현재 작업 디렉터리가 에이전트가 등록된 Git 리포지터리인 경우 --repo / -R 플래그를 생략할 수 있습니다
glab cluster agent update-kubeconfig --agent '<에이전트-ID>'

# --use-context 옵션을 지정하면 kubeconfig 파일의 `current-context`가 에이전트 컨텍스트로 변경됩니다
glab cluster agent update-kubeconfig --agent '<에이전트-ID>' --use-context

# --kubeconfig 플래그를 사용하여 대체 kubeconfig 경로를 지정할 수 있습니다
glab cluster agent update-kubeconfig --agent '<에이전트-ID>' --kubeconfig ~/gitlab.kubeconfig

개인 액세스 토큰을 사용하여 로컬 액세스 매뉴얼으로 구성하기

긴 수명을 가진 개인 액세스 토큰을 사용하여 Kubernetes 클러스터에 대한 액세스를 구성할 수 있습니다:

왼쪽 사이드바에서 검색 또는 이동하여를 선택하고 프로젝트를 찾습니다.
운영 > Kubernetes 클러스터를 선택하여 액세스하려는 에이전트의 숫자 ID를 검색합니다. 전체 API 토큰을 만들기 위해 ID가 필요합니다.
k8s_proxy 스코프로 개인 액세스 토큰을 생성합니다. 전체 API 토큰을 만들기 위해 액세스 토큰이 필요합니다.
클러스터에 액세스하기 위해 kubeconfig 항목을 만듭니다:
1. 적절한 kubeconfig가 선택되었는지 확인합니다. 예를 들어, KUBECONFIG 환경 변수를 설정할 수 있습니다.
2. GitLab KAS 프록시 클러스터를 kubeconfig에 추가합니다:
```
kubectl config set-cluster <cluster_name> --server "https://kas.gitlab.com/k8s-proxy"
```
  server 인수는 GitLab 인스턴스의 KAS 주소를 가리킵니다. GitLab.com의 경우, https://kas.gitlab.com/k8s-proxy입니다. 에이전트를 등록할 때 인스턴스의 KAS 주소를 얻을 수 있습니다.
3. 숫자형 에이전트 ID와 개인 액세스 토큰을 사용하여 API 토큰을 만듭니다:
```
kubectl config set-credentials <gitlab_user> --token "pat:<agent-id>:<token>"
```
4. 클러스터와 사용자를 결합하는 컨텍스트를 추가합니다:
```
kubectl config set-context <gitlab_agent> --cluster <cluster_name> --user <gitlab_user>
```
5. 새로운 컨텍스트를 활성화합니다:
```
kubectl config use-context <gitlab_agent>
```
구성이 작동하는지 확인합니다:
```
 kubectl get nodes
```

구성된 사용자는 Kubernetes API를 사용하여 클러스터에 액세스할 수 있습니다.

사용자에게 Kubernetes 액세스 권한 부여

Kubernetes 액세스 구성

사용자 위장을 사용한 액세스 구성

사용자 위장 작업 흐름

RBAC 권한 부여

Kubernetes API를 통한 클러스터 액세스

GitLab CLI(권장)를 사용한 로컬 액세스 구성

개인 액세스 토큰을 사용하여 로컬 액세스 매뉴얼으로 구성하기

관련 주제

도움말

기능 사용 가능성과 제품 평가판

도움받기