오늘 우리는 GitLab 16.4 출시 소식을 발표해서 기쁩니다. 이번 업데이트에서는 커스텀 역할 생성, 비공개 프로젝트의 워크스페이스 만들기, GitLab 사용자 ID를 이용해 로컬로 클러스터에 액세스하기, 그룹/하위 그룹 수준 의존성 목록, id_token을 전역으로 설정하고, 개별 job의 구성 제거하기 기능 등을 선보였습니다.
위 내용은 이번 릴리즈에서 선보인 100개 이상의 개선 사항 중 몇 가지 주요 사항입니다. 아래에 주요 업데이트 내용을 모두 확인하세요. 다음 달 릴리즈 내용을 미리 보려면 16.5 릴리즈 킥오프 비디오가 있는 예정 릴리즈 페이지를 보세요.
GitLab 16.4 소개 영상. 출처=인포그랩 유튜브
커스텀 역할 생성
’커스텀 역할’ 영상. 출처=GitLab
이제 그룹 Owner 또는 관리자는 ‘Roles and Permissions’ 메뉴 UI를 사용해 커스텀 역할(custom role)을 만들고 제거할 수 있습니다. 커스텀 역할을 만들려면 기존 기본 역할(base role) 위에 권한(permission)을 추가해야 합니다. 현재 기본 역할에 추가할 수 있는 권한(permission)은 세분화된 보안 권한(granular security permissions), Merge Request 승인 기능, 코드 보기 기능으로, 제한적입니다. 마일스톤마다 기존 권한(permisson)에 추가돼 커스텀 역할을 만드는 새로운 권한(permission)이 릴리즈될 예정입니다.
비공개 프로젝트의 워크스페이스 만들기

이전에는 비공개 프로젝트의 워크스페이스를 만들 수 없었습니다. 비공개 프로젝트를 복제하려면 워크스페이스를 만든 뒤에만 본인 인증할 수 있었습니다.
GitLab 16.4부터는 모든 공개 또는 비공개 프로젝트의 워크스페이스를 만들 수 있습니다. 워크스페이스를 만들 때, 워크스페이스와 함께 사용하는 개인 액세스 토큰을 받을 수 있습니다. 이 토큰을 사용해 추가 구성이나 인증 없이 비공개 프로젝트를 복제하고, Git 작업을 수행할 수 있습니다.
GitLab 사용자 ID를 이용해 로컬로 클러스터에 액세스하기
’GitLab 사용자 ID를 이용해 로컬로 클러스터에 액세스하기’ 영상. 출처=GitLab
개발자가 Kubernetes 클러스터에 액세스하도록 허용하려면 개발자 클라우드 계정 또는 서드 파티 인증 도구가 필요합니다. 이는 클라우드 ID와 액세스 관리를 복잡하게 합니다. 이제 GitLab ID와 Kubernetes 에이전트만 사용해 Kubernetes 클러스터에 액세스하도록 개발자에게 권한을 부여할 수 있습니다. 기존 Kubernetes RBAC를 사용해 클러스터 안에서 권한을 관리하세요.
GitLab 파이프라인의 OpenID Connect(OIDC) 클라우드 인증 서비스와 함께, 이러한 기능은 GitLab 사용자가 전용 클라우드 계정 없이도 보안과 컴플라이언스를 위태롭게 하지 않고, 클라우드 리소스에 액세스하도록 지원합니 다.
클러스터 액세스의 이번 첫번째 이터레이션에서는 Kubernetes 구성을 수동으로 관리해야 합니다. Epic 11455은 관련 명령어로 GitLab CLI를 확장해 설정을 간소화하도록 제안합니다.
그룹/하위 그룹 수준 의존성 목록

의존성 목록을 리뷰할 때, 전체적으로 보는 게 중요합니다. 프로젝트 수준에서 의존성을 관리하는 일은 프로젝트 전반에 걸쳐 의존성을 감사하려는 대규모 조직에서 문제가 됩니다. 이번 릴리즈에서는 하위 그룹을 포함해 프로젝트 또는 그룹 수준에서 모든 의존성을 볼 수 있습니다. 이 기능은 기본으로 사용할 수 있습니다.