사용자에게 Kubernetes 액세스 권한 부여
- 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
사용자 위임을 사용한 액세스 구성
사용자에게 Kubernetes 클러스터에 액세스 권한을 부여하고 인증된 사용자를 위해 요청을 위임 요청으로 변환할 수 있습니다.
전제 조건:
- Kubernetes를 위한 에이전트가 클러스터에 설치되어 있어야 합니다.
- 개발자 롤 이상이어야 합니다.
사용자 위임을 사용한 액세스를 구성하려면 다음 단계를 수행하세요:
-
에이전트 구성 파일에서 다음 매개변수를 사용하여
user_access
키워드를 정의합니다.-
projects
: 액세스 권한을 부여해야 하는 프로젝트 목록입니다. -
groups
: 액세스 권한을 부여해야 하는 그룹 목록입니다. -
access_as
: 필수 사항입니다. 사용자 위임의 경우 값은{ user: {...} }
입니다.
-
액세스를 구성한 후 요청은 인증된 사용자를 위해 위임된 요청으로 변환됩니다.
사용자 위임 워크플로우
설치된 agentk
는 다음과 같이 주어진 사용자를 위임합니다:
-
UserName
은gitlab: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
명령을 사용하여 클러스터 연결을 관리합니다:
- 프로젝트와 관련된 모든 에이전트 목록을 확인합니다:
glab cluster agent list --repo '<group>/<project>'
# 현재 작업 디렉토리가 에이전트가 등록된 프로젝트의 Git 리포지토리인 경우 --repo 옵션을 생략할 수 있습니다:
glab cluster agent list
- 출력의 첫 번째 열에 표시된 숫자 에이전트 ID를 사용하여
kubeconfig
을 업데이트합니다:
glab cluster agent update-kubeconfig --repo '<group>/<project>' --agent '<agent-id>' --use-context
-
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
개인 접근 토큰을 사용하여 수동으로 로컬 액세스 구성
장기간 사용되는 개인 접근 토큰을 사용하여 쿠버네티스 클러스터에 액세스를 구성할 수 있습니다:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 운영 > Kubernetes 클러스터를 선택하고 액세스하려는 에이전트의 숫자 ID를 검색합니다. 전체 API 토큰을 구성하려면 ID가 필요합니다.
-
k8s_proxy
스코프로 개인 접근 토큰을 생성합니다. 전체 API 토큰을 구성하려면 액세스 토큰이 필요합니다. - 클러스터에 액세스하기 위한
kubeconfig
항목을 생성합니다:- 적절한
kubeconfig
이 선택되었는지 확인합니다. 예를 들어,KUBECONFIG
환경 변수를 설정할 수 있습니다. -
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 주소를 얻을 수 있습니다. -
숫자 에이전트 ID와 개인 접근 토큰을 사용하여 API 토큰을 생성합니다:
kubectl config set-credentials <gitlab_user> --token "pat:<agent-id>:<token>"
-
클러스터와 사용자를 결합할 컨텍스트를 추가합니다:
kubectl config set-context <gitlab_agent> --cluster <cluster_name> --user <gitlab_user>
-
새로운 컨텍스트를 활성화합니다:
kubectl config use-context <gitlab_agent>
- 적절한
-
구성이 작동하는지 확인합니다:
kubectl get nodes
구성된 사용자는 쿠버네티스 API를 통해 클러스터에 액세스할 수 있습니다.