워크스페이스를 위한 Kubernetes용 GitLab 에이전트 구성
GitLab v19.5Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
요약
워크스페이스 인프라를 설정할 때는 워크스페이스를 지원하도록 Kubernetes용 GitLab 에이전트를 구성해야 합니다. Kubernetes용 GitLab 에이전트 설정 튜토리얼의 설정 단계를 모두 마쳐야 합니다. 에이전트 구성에서 remote_development 모듈이 활성화돼 있어야 하고, 이 모듈의 필수 필드가 올바르게 설정돼 있어야 합니다.
워크스페이스 인프라를 설정할 때는 워크스페이스를 지원하도록 Kubernetes용 GitLab 에이전트를 구성해야 합니다. 이 가이드는 Kubernetes 클러스터에 GitLab 에이전트가 이미 설치돼 있다고 가정합니다.
필수 조건:
-
Kubernetes용 GitLab 에이전트 설정 튜토리얼의 설정 단계를 모두 마쳐야 합니다.
-
에이전트 구성에서
remote_development모듈이 활성화돼 있어야 하고, 이 모듈의 필수 필드가 올바르게 설정돼 있어야 합니다.[!note] 활성 워크스페이스가 있는 에이전트에서
remote_development모듈을 비활성화하면 해당 워크스페이스는 사용할 수 없게 됩니다. 자세한 내용은 워크스페이스 설정을 참고합니다. -
워크스페이스를 만들려면 해당 그룹에서 에이전트가 허용돼 있어야 합니다. 워크스페이스를 만들 때 사용자는 워크스페이스 프로젝트의 상위 그룹에 연결된 허용 에이전트를 선택할 수 있습니다.
-
워크스페이스를 만드는 사용자는 에이전트가 속한 프로젝트에 대해 Developer 권한이 있어야 합니다.
워크스페이스를 만들기 위한 그룹에서 에이전트 권한 부여#
히스토리
- 새로운 권한 부여 전략이 GitLab 17.2에서 도입되었습니다.
새로운 권한 부여 전략은 레거시 권한 부여 전략을 대체합니다. 그룹 Owner와 관리자는 어떤 클러스터 에이전트가 그룹의 워크스페이스를 호스팅할지 제어할 수 있습니다.
예를 들어 워크스페이스 프로젝트의 경로가 top-level-group/subgroup-1/subgroup-2/workspace-project라면, top-level-group, subgroup-1, subgroup-2 그룹에 구성된 에이전트를 모두 사용할 수 있습니다.
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
accTitle: Agent authorization hierarchy for workspaces
accDescr: Workspace projects inherit access to agents from all parent groups in the hierarchy.
topGroup[Top-Level Group, allowed Agent 1]
subgroup1[Subgroup 1, allowed Agent 2]
subgroup2[Subgroup 2, allowed Agent 3]
wp(Workspace Project, Agent 1, 2 & 3 all available)
topGroup --> subgroup1
subgroup1 --> subgroup2
subgroup2 --> wp
class wp active;</code></pre></details></div>
subgroup-1 같은 특정 그룹에 클러스터 에이전트를 허용하면,
그 그룹 아래의 모든 프로젝트에서 워크스페이스를 만드는 데 해당 에이전트를 사용할 수 있습니다.
허용할 그룹의 범위는 클러스터 에이전트가 워크스페이스를 호스팅할 수 있는 위치를 결정하므로
신중하게 정합니다.
그룹의 워크스페이스에 클러스터 에이전트 허용#
필수 조건:
- 워크스페이스 인프라를 설정해야 합니다.
- 인스턴스에 대한 관리자 액세스 권한이 있거나 해당 그룹에 대해 Owner 권한이 있어야 합니다.
그룹의 워크스페이스에 클러스터 에이전트를 허용하려면 다음과 같이 진행합니다:
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 Settings > Workspaces를 선택합니다.
- Group agents 섹션에서 All agents 탭을 선택합니다.
- 사용 가능한 에이전트 목록에서 상태가 Blocked 인 에이전트를 찾아 Allow를 선택합니다.
- 확인 대화 상자에서 Allow agent를 선택합니다.
GitLab은 선택한 에이전트의 상태를 Allowed로 갱신하고, 해당 에이전트를 Allowed agents 탭에 표시합니다.
그룹의 워크스페이스에서 허용된 클러스터 에이전트 제거#
필수 조건:
- 워크스페이스 인프라를 설정해야 합니다.
- 인스턴스에 대한 관리자 액세스 권한이 있거나 해당 그룹에 대해 Owner 권한이 있어야 합니다.
그룹에서 허용된 클러스터 에이전트를 제거하려면 다음과 같이 진행합니다:
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 Settings > Workspaces를 선택합니다.
- Group agents 섹션에서 Allowed agents 탭을 선택합니다.
- 허용된 에이전트 목록에서 제거할 에이전트를 찾아 Block을 선택합니다.
- 확인 대화 상자에서 Block agent를 선택합니다.
GitLab은 선택한 에이전트의 상태를 Blocked로 갱신하고, 해당 에이전트를 Allowed agents 탭에서 제거합니다.
Note
그룹에서 허용된 클러스터 에이전트를 제거해도 그 에이전트를 사용해 실행 중인 워크스페이스가 즉시
중지되지는 않습니다. 실행 중인 워크스페이스는 자동으로 종료되거나 수동으로 중지될 때 멈춥니다.
인스턴스의 워크스페이스에 클러스터 에이전트 허용#
히스토리
- GitLab 18.2에서 도입되었습니다.
필수 조건:
- 워크스페이스 인프라를 설정해야 합니다.
- 원격 개발이 활성화된 에이전트가 있어야 합니다.
- 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.
인스턴스의 워크스페이스에 클러스터 에이전트를 허용하려면 다음과 같이 진행합니다:
- 오른쪽 위에서 Admin을 선택합니다.
- 왼쪽 사이드바에서 Settings > General을 선택합니다.
- Available agents for workspaces를 확장합니다.
- 워크스페이스가 활성화된 에이전트 목록에서 허용할 에이전트를 찾아
사용 가능 토글을 선택합니다.
인스턴스의 워크스페이스에서 허용된 클러스터 에이전트 제거#
히스토리
- GitLab 18.2에서 도입되었습니다.
필수 조건:
- 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.
인스턴스에서 허용된 클러스터 에이전트를 제거하려면 다음과 같이 진행합니다:
- 오른쪽 위에서 Admin을 선택합니다.
- 왼쪽 사이드바에서 Settings > General을 선택합니다.
- Available agents for workspaces를 확장합니다.
- 허용된 에이전트 목록에서 제거할 에이전트를 찾아 사용 가능 토글을 해제합니다.
Note
인스턴스에서 허용된 클러스터 에이전트를 제거해도 그 에이전트를 사용해 실행 중인 워크스페이스가 즉시
중지되지는 않습니다. 실행 중인 워크스페이스는 자동으로 종료되거나 수동으로 중지될 때 멈춥니다.
레거시 에이전트 권한 부여 전략#
GitLab 17.1 이하에서는 그룹에서 에이전트를 사용할 수 있는지가 워크스페이스 생성의 필수 조건이
아니었습니다.
다음 두 조건을 모두 충족하면 워크스페이스 프로젝트의 최상위 그룹에 있는 모든 에이전트로
워크스페이스를 만들 수 있습니다:
- 원격 개발 모듈이 활성화돼 있습니다.
- 최상위 그룹에 대해 Developer, Maintainer, Owner 중 하나의 권한이 있습니다.
예를 들어 워크스페이스 프로젝트의 경로가 top-level-group/subgroup-1/subgroup-2/workspace-project라면,
top-level-group과 그 하위 그룹에 구성된 모든 에이전트를 사용할 수 있습니다.
원격 개발을 사용하여 사용자 액세스 구성#
user_access 모듈을 구성하면 GitLab 자격 증명으로 연결된 Kubernetes 클러스터에 액세스할 수 있습니다.
이 모듈은 remote_development 모듈과 독립적으로 구성되고 실행됩니다.
같은 에이전트에서 user_access와 remote_development를 함께 구성할 때는 주의합니다.
remote_development 클러스터는 개인 액세스 토큰 같은 사용자 자격 증명을 Kubernetes Secret으로 관리합니다.
user_access 구성이 잘못되면 이 비공개 데이터가 Kubernetes API를 통해 노출될 수 있습니다.
user_access 구성에 대한 자세한 내용은
Kubernetes 액세스 구성을 참고합니다.
관련 주제#