사용자에게 Kubernetes 접근 권한 부여

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

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

접근 권한을 부여하면 프로젝트나 그룹에 대한 Kubernetes 대시보드도 활성화됩니다.

셀프 관리 인스턴스의 경우 다음 중 하나를 반드시 수행해야 합니다:

  • GitLab 인스턴스와 KAS를 동일 도메인에서 호스팅합니다.
  • GitLab의 하위 도메인에 KAS를 호스팅합니다. 예를 들어, GitLab은 gitlab.com에 있고 KAS는 kas.gitlab.com에 있습니다.

Kubernetes 접근 권한 구성

사용자에게 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 클러스터에 Kubernetes 에이전트가 설치되어 있어야 합니다.
  • 개발자 역할 이상의 권한이 있어야 합니다.

사용자 임시 대리로 접근 권한을 구성하려면:

  • 에이전트 구성 파일에서 다음 매개변수를 사용하는 user_access 키워드를 정의합니다:

    • projects: 접근 권한이 있어야 하는 프로젝트 목록입니다.
    • groups: 접근 권한이 있어야 하는 그룹 목록입니다.
    • access_as: 필수입니다. 사용자 임시 대리의 경우 값은 { user: {...} }입니다.

접근 권한을 구성한 후 요청은 인증된 사용자에 대한 임시 대리 요청으로 변환됩니다.

사용자 가장 행위 흐름

설치된 agentk는 주어진 사용자를 다음과 같이 가장합니다:

  • UserName은 gitlab:user:<username>입니다.
  • Groups는 다음과 같습니다:
    • gitlab:user: GitLab 사용자로부터 오는 모든 요청에 공통적입니다.
    • gitlab:project_role:<project_id>:<role>: 각 허가된 프로젝트의 각 역할별로.
    • gitlab:group_role:<group_id>:<role>: 각 허가된 그룹의 각 역할별로.
  • 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 또는 session_cookie 중 하나입니다. Ultimate 전용입니다.

구성 파일의 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:<role>만 받습니다.

  • 사용자가 group-2의 멤버인 경우, 그들은 두 개의 Kubernetes RBAC 그룹을 받습니다:

    • gitlab:project_role:2:<role>,
    • gitlab:group_role:2:<role>입니다.

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 사용자가 Kubernetes API로 클러스터에 접근할 수 있도록 허용할 수 있습니다.

사전 요구 사항:

  • user_access 항목이 있는 에이전트가 구성되어 있습니다.

GitLab CLI로 로컬 접근 구성하기 (권장)

GitLab CLI glab를 사용하여 에이전트 Kubernetes API에 접근하기 위한 Kubernetes 구성 파일을 생성하거나 업데이트할 수 있습니다.

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

  1. 프로젝트와 연관된 모든 에이전트 리스트를 확인합니다:
glab cluster agent list --repo '<group>/<project>'

# 현재 작업 디렉토리가 에이전트가 등록된 프로젝트의 Git 저장소인 경우 --repo 옵션을 생략할 수 있습니다:
glab cluster agent list
  1. 출력의 첫 번째 열에 표시된 숫자 에이전트 ID를 사용하여 kubeconfig를 업데이트합니다:
glab cluster agent update-kubeconfig --repo '<group>/<project>' --agent '<agent-id>' --use-context
  1. kubectl 또는 선호하는 Kubernetes 도구로 업데이트를 확인합니다:
kubectl get nodes

update-kubeconfig 명령어는 Kubernetes 도구가 토큰을 검색하는 자격 증명 플러그인으로 glab cluster agent get-token을 설정합니다. get-token 명령어는 현재 일의 종료까지 유효한 개인 액세스 토큰을 생성하고 반환합니다. Kubernetes 도구는 토큰이 만료될 때까지, API가 권한 오류를 반환하거나 프로세스가 종료될 때까지 토큰을 캐시합니다. 이후 Kubernetes 도구에 대한 모든 호출이 새로운 토큰을 생성할 것으로 예상합니다.

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

몇 가지 예시:

# 현재 작업 디렉토리가 에이전트가 등록된 Git 저장소일 경우 --repo / -R 플래그는 생략할 수 있습니다
glab cluster agent update-kubeconfig --agent '<agent-id>'

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

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

개인 액세스 토큰을 사용하여 로컬 액세스 수동 구성

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

  2. 작업 > Kubernetes 클러스터를 선택하고 액세스하려는 에이전트의 숫자 ID를 검색합니다. 전체 API 토큰을 구성하려면 ID가 필요합니다.

  3. k8s_proxy 범위로 개인 액세스 토큰을 생성합니다. 전체 API 토큰을 구성하려면 액세스 토큰이 필요합니다.

  4. 클러스터에 접근하기 위해 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>

  5. 구성이 작동하는지 확인합니다:

    kubectl get nodes

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

관련 주제