사용자에게 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를 같은 도메인에 호스팅합니다.
- GitLab의 하위 도메인에 KAS를 호스팅합니다. 예:
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>
입니다. -
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
,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>
의 Kubernetes RBAC 그룹만 받게 됩니다. - 사용자가
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
명령을 사용합니다.
- 프로젝트와 연관된 모든 에이전트 디렉터리을 확인하세요:
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
또는 기본 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 클러스터에 액세스를 구성할 수 있습니다:
- 왼쪽 사이드바에서 검색 또는 이동하여를 선택하고 프로젝트를 찾습니다.
- 작업 > 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
구성된 사용자는 Kubernetes API를 사용하여 클러스터에 액세스할 수 있습니다.