InfoGrab DocsInfoGrab Docs

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

요약

조직의 Kubernetes 클러스터 관리자는 특정 프로젝트나 그룹의 구성원에게 Kubernetes 접근 권한을 부여할 수 있습니다. 접근 권한을 부여하면 해당 프로젝트나 그룹에서 Kubernetes 대시보드도 함께 활성화됩니다.

히스토리
  • GitLab 17.0에서 에이전트 연결 공유 한도가 100에서 500으로 상향되었습니다.
  • GitLab 18.3에서 user_access 파라미터 access_as가 선택 사항으로 변경되었습니다. 기본값은 에이전트 가장입니다.
  • GitLab 18.4에서 서로 다른 최상위 그룹에 속한 프로젝트와 그룹도 인가할 수 있도록 변경되었습니다.

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

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

GitLab Self-Managed 인스턴스에서는 다음 중 하나를 반드시 충족해야 합니다.

  • GitLab 인스턴스와 KAS를 같은 도메인에 호스팅합니다.
  • KAS를 GitLab의 하위 도메인에 호스팅합니다. 예를 들어 GitLab은 gitlab.com, KAS는 kas.gitlab.com에 둡니다.

Kubernetes 접근 구성#

사용자에게 Kubernetes 클러스터 접근 권한을 부여하려면 접근을 구성합니다.

사전 요구 사항:

  • Kubernetes 클러스터에 Kubernetes용 에이전트가 설치되어 있어야 합니다.
  • Developer 이상의 권한이 있어야 합니다.

접근을 구성하려면 다음 단계를 수행합니다.

  • 에이전트 구성 파일에서 다음 파라미터와 함께 user_access 키워드를 정의합니다.

    • projects: 구성원에게 접근 권한을 부여할 프로젝트 목록입니다. 최대 500개 프로젝트를 인가할 수 있습니다.
    • groups: 구성원에게 접근 권한을 부여할 그룹 목록입니다. 최대 500개 그룹을 인가할 수 있습니다. 해당 그룹과 모든 하위 그룹에 접근 권한이 부여됩니다.
    • access_as: 에이전트 ID로 접근하는 경우 값은 { 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

사용자 가장으로 접근 구성#

Kubernetes 클러스터에 접근 권한을 부여하고, 인증된 사용자의 요청을 가장 요청으로 변환할 수 있습니다.

사전 요구 사항:

  • Kubernetes 클러스터에 Kubernetes용 에이전트가 설치되어 있어야 합니다.
  • Developer 이상의 권한이 있어야 합니다.

사용자 가장으로 접근을 구성하려면 다음 단계를 수행합니다.

  • 에이전트 구성 파일에서 다음 파라미터와 함께 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)의 Maintainer가 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>'

# If your current working directory is the Git repository of the project with the agent, you can omit the --repo option:
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로 확인할 수 있습니다.

몇 가지 예시는 다음과 같습니다.

# When the current working directory is the Git repository where the agent is registered the --repo / -R flag can be omitted
glab cluster agent update-kubeconfig --agent '<agent-id>'

# When the --use-context option is specified the `current-context` of the kubeconfig file is changed to the agent context
glab cluster agent update-kubeconfig --agent '<agent-id>' --use-context

# The --kubeconfig flag can be used to specify an alternative kubeconfig path
glab cluster agent update-kubeconfig --agent '<agent-id>' --kubeconfig ~/gitlab.kubeconfig

개인 액세스 토큰을 사용한 수동 로컬 접근 구성#

수명이 긴 개인 액세스 토큰을 사용하여 Kubernetes 클러스터 접근을 구성할 수 있습니다.

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

  2. 왼쪽 사이드바에서 Operate > Kubernetes clusters를 선택하고 접근할 에이전트의 숫자 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로 클러스터에 접근할 수 있습니다.

관련 주제#

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

GitLab v19.5
Tier: Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기

요약

조직의 Kubernetes 클러스터 관리자는 특정 프로젝트나 그룹의 구성원에게 Kubernetes 접근 권한을 부여할 수 있습니다. 접근 권한을 부여하면 해당 프로젝트나 그룹에서 Kubernetes 대시보드도 함께 활성화됩니다.

히스토리
  • GitLab 17.0에서 에이전트 연결 공유 한도가 100에서 500으로 상향되었습니다.
  • GitLab 18.3에서 user_access 파라미터 access_as가 선택 사항으로 변경되었습니다. 기본값은 에이전트 가장입니다.
  • GitLab 18.4에서 서로 다른 최상위 그룹에 속한 프로젝트와 그룹도 인가할 수 있도록 변경되었습니다.

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

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

GitLab Self-Managed 인스턴스에서는 다음 중 하나를 반드시 충족해야 합니다.

  • GitLab 인스턴스와 KAS를 같은 도메인에 호스팅합니다.
  • KAS를 GitLab의 하위 도메인에 호스팅합니다. 예를 들어 GitLab은 gitlab.com, KAS는 kas.gitlab.com에 둡니다.

Kubernetes 접근 구성#

사용자에게 Kubernetes 클러스터 접근 권한을 부여하려면 접근을 구성합니다.

사전 요구 사항:

  • Kubernetes 클러스터에 Kubernetes용 에이전트가 설치되어 있어야 합니다.
  • Developer 이상의 권한이 있어야 합니다.

접근을 구성하려면 다음 단계를 수행합니다.

  • 에이전트 구성 파일에서 다음 파라미터와 함께 user_access 키워드를 정의합니다.

    • projects: 구성원에게 접근 권한을 부여할 프로젝트 목록입니다. 최대 500개 프로젝트를 인가할 수 있습니다.
    • groups: 구성원에게 접근 권한을 부여할 그룹 목록입니다. 최대 500개 그룹을 인가할 수 있습니다. 해당 그룹과 모든 하위 그룹에 접근 권한이 부여됩니다.
    • access_as: 에이전트 ID로 접근하는 경우 값은 { 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

사용자 가장으로 접근 구성#

Kubernetes 클러스터에 접근 권한을 부여하고, 인증된 사용자의 요청을 가장 요청으로 변환할 수 있습니다.

사전 요구 사항:

  • Kubernetes 클러스터에 Kubernetes용 에이전트가 설치되어 있어야 합니다.
  • Developer 이상의 권한이 있어야 합니다.

사용자 가장으로 접근을 구성하려면 다음 단계를 수행합니다.

  • 에이전트 구성 파일에서 다음 파라미터와 함께 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)의 Maintainer가 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>'

# If your current working directory is the Git repository of the project with the agent, you can omit the --repo option:
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로 확인할 수 있습니다.

몇 가지 예시는 다음과 같습니다.

# When the current working directory is the Git repository where the agent is registered the --repo / -R flag can be omitted
glab cluster agent update-kubeconfig --agent '<agent-id>'

# When the --use-context option is specified the `current-context` of the kubeconfig file is changed to the agent context
glab cluster agent update-kubeconfig --agent '<agent-id>' --use-context

# The --kubeconfig flag can be used to specify an alternative kubeconfig path
glab cluster agent update-kubeconfig --agent '<agent-id>' --kubeconfig ~/gitlab.kubeconfig

개인 액세스 토큰을 사용한 수동 로컬 접근 구성#

수명이 긴 개인 액세스 토큰을 사용하여 Kubernetes 클러스터 접근을 구성할 수 있습니다.

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

  2. 왼쪽 사이드바에서 Operate > Kubernetes clusters를 선택하고 접근할 에이전트의 숫자 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로 클러스터에 접근할 수 있습니다.

관련 주제#