조직에서 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)의 유지 관리자가 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. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 운영 > Kubernetes 클러스터를 선택하고 접근하려는 에이전트의 숫자 ID를 검색합니다. 전체 API 토큰을 구성하는 데 ID가 필요합니다.

3. k8s_proxy 범위로 개인 접근 토큰을 생성합니다. 전체 API 토큰을 구성하는 데 접근 토큰이 필요합니다.

4. 클러스터에 접근하기 위한 kubeconfig 항목을 구성합니다:

   1. 적절한 kubeconfig가 선택되어 있는지 확인합니다. 예를 들어 KUBECONFIG 환경 변수를 설정할 수 있습니다.

   2. kubeconfig에 GitLab KAS 프록시 클러스터를 추가합니다:

      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용 대시보드