사용자에게 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라는 플래그가 도입되었습니다. 이 기능은 베타 상태입니다.
  • environment_settings_to_graphql 특징 플래그는 GitLab 16.2에서 삭제되었습니다.
  • kas_user_access, kas_user_access_project, expose_authorized_cluster_agents 특징 플래그는 GitLab 16.2에서 삭제되었습니다.

조직 내 Kubernetes 클러스터의 관리자로서, 특정 프로젝트나 그룹의 구성원에 대해 Kubernetes 액세스를 부여할 수 있습니다.

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

자체 호스팅된 인스턴스의 경우 다음 사항을 확인하세요:

  • GitLab 인스턴스와 KAS를 동일 도메인에 호스트합니다.
  • KAS를 GitLab의 서브도메인에 호스트합니다. 예를 들어, gitlab.com에 GitLab을 호스팅하고 kas.gitlab.com에 KAS를 호스트합니다.

Kubernetes 액세스 구성

사용자가 Kubernetes 클러스터에 액세스 권한을 부여하려는 경우 액세스를 구성하세요.

전제 조건:

  • Kubernetes를 위한 에이전트가 클러스터에 설치되어 있어야 합니다.
  • 개발자 롤 이상이어야 합니다.

액세스를 구성하려면 다음 단계를 수행하세요:

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

    • projects: 액세스 권한을 부여해야 하는 프로젝트 목록입니다.
    • groups: 액세스 권한을 부여해야 하는 그룹 목록입니다.
    • 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는 다음과 같이 주어진 사용자를 위임합니다:

  • UserNamegitlab:user:<username>입니다.
  • 그룹은:
    • 모든 GitLab 사용자로부터 오는 모든 요청에 대한 공통입니다.
    • 각 허가된 프로젝트의 각 역할에 대해 gitlab:project_role:<project_id>:<role>입니다.
    • 각 허가된 그룹의 각 역할에 대해 gitlab:group_role:<group_id>:<role>입니다.
  • 추가는 요청에 대한 추가 정보를 제공합니다:
    • 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의 멤버인 경우 gitlab:project_role:1:<role>만 받습니다.
  • 사용자가 group-2의 멤버인 경우 Kubernetes RBAC 그룹 둘 다 받습니다:
    • gitlab:project_role:2:<role>
    • gitlab:group_role:2:<role>.

RBAC 권한 부여

임시 요청은 쿠버네티스 내에서 자원 권한을 식별하기 위해 ClusterRoleBinding 또는 RoleBinding을 필요로 합니다. 적절한 구성을 위해 RBAC 권한을 참조하세요.

예를 들어, awesome-org/deployment 프로젝트(ID: 123)에서 유지자들에게 쿠버네티스 워크로드를 읽을 수 있도록 허용한다면, 쿠버네티스 구성에 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

쿠버네티스 API를 통해 클러스터에 액세스

  • GitLab 16.4에서 도입되었습니다.

GitLab 사용자가 쿠버네티스 API를 통해 클러스터에 액세스할 수 있도록 에이전트를 구성할 수 있습니다.

사전 요구 사항:

  • user_access 항목이 구성된 에이전트가 있어야 합니다.

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

GitLab CLI glab를 사용하여 에이전트 쿠버네티스 API에 액세스할 수 있는 구성 파일을 생성 또는 업데이트할 수 있습니다.

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 또는 선호하는 쿠버네티스 도구로 업데이트를 확인합니다:
kubectl get nodes

update-kubeconfig 명령은 쿠버네티스 도구가 토큰을 검색하기 위한 자격 증명 플러그인으로 glab cluster agent get-token을 설정합니다. get-token 명령은 생성된 토큰을 반환하며 해당 토큰은 현재 날짜의 끝까지 유효합니다. 쿠버네티스 도구는 토큰을 만료될 때, API가 권한 오류를 반환할 때 또는 프로세스가 종료될 때까지 캐시합니다. 앞으로 모든 호출은 새로운 토큰을 생성하도록 합니다.

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

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

장기간 사용되는 개인 접근 토큰을 사용하여 쿠버네티스 클러스터에 액세스를 구성할 수 있습니다:

  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
    

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

관련 주제