Config Management 및 GitLab의 정책 관리 권장사항 살펴보기

이 문서에서는 Config Management 및 GitLab을 사용하여 프로덕션 환경에서 여러 Kubernetes 클러스터를 관리하는 방법을 중점적으로 설명합니다. Config Management 저장소를 보호하는 것은 중요한 배포 단계이며 이 프로세스를 진행할 때 이 문서를 참고하면 도움이 될 수 있습니다. 이 문서는 프로덕션 용으로 Config Management 배포를 수행하는 경우에 유용하며, Kubernetes, Git, GitLab에 익숙하다고 가정합니다.

조직의 앱을 호스팅하는 플랫폼을 운영 중인 경우 플랫폼 보호 정책을 마련해야 합니다. 정책은 플랫폼과 플랫폼의 앱과 데이터를 보호하기 위한 규칙입니다. 플랫폼은 정책을 설명하는 구성에 따라 이러한 정책을 적용합니다. 정책을 적용하면 플랫폼의 보안 및 안정성을 개선하는 데 도움이 됩니다.

Config Management는 Google Kubernetes Engine(GKE), GKE 클러스터 또는 기타 Kubernetes 배포판 위에 구축된 플랫폼에 대한 대규모 정책 관리를 지원합니다. Config Management를 사용하면 여러 클러스터의 Kubernetes 객체를 한 번에 만들고 관리할 수 있습니다. Config Management로 Kubernetes 객체를 관리할 수 있지만 다음과 같은 정책을 적용하면 특히 유용합니다.

• PodSecurityPolicies: Pod가 루트 Linux 사용자를 사용하지 못하도록 합니다.
• NetworkPolicies: 클러스터 내에서 네트워크 트래픽을 제어합니다.
• ClusterRoles 및 ClusterRoleBindings: 클러스터 내의 권한을 제어합니다.

다음 다이어그램과 같이 Config Management는 GitOps 스타일 도구입니다. 이 다이어그램과 이 페이지의 예시는 Git 저장소를 정보 소스와 스토리지 메커니즘으로 사용하지만 OCI 이미지 또는 Helm 차트를 정보 소스로 사용할 수도 있습니다.

Config Management를 사용하면 이 Git 저장소와 상호작용하여 Kubernetes 객체를 배포하고 관리할 수 있습니다. Config Management Git 저장소의 기본 분기에 대해 쓰기 액세스 권한이 있으면 Config Management에서 관리되는 클러스터를 관리할 수 있습니다. Config Management 저장소는 잠재적 공격자가 악용할 소지가 있는 정보를 포함하고 있으므로 Config Management 저장소를 보호하는 것이 중요합니다.

이 문서는 Git 저장소 호스팅 서비스로 GitLab Source Code Management(SCM)를 사용하고 Config Management와 GitLab을 함께 사용하여 여러 Kubernetes 클러스터를 관리하는 방법에 대한 권장사항을 설명합니다.

참고: 이 문서에 언급된 일부 GitLab 기능은 유료 GitLab Enterprise 등급에 포함된 기능입니다. 이러한 기능이 언급된 경우 주석으로 표시됩니다. 이 문서는 GitLab 기능 및 가격에 관한 최신 정보를 나타내지 않을 수 있습니다. GitLab 기능 및 가격에 대한 최신 정보를 보려면 GitLab 가격 책정을 참조하세요.

Config Management 및 GitLab 아키텍처

다음 다이어그램은 GKE, VMware용 GKE, 다른 클라우드 제공업체에서 각각 하나씩 총 3개의 Kubernetes 클러스터를 관리하는 GitLab이 포함된 Config Management 배포 아키텍처를 보여줍니다.

위의 다이어그램은 파이프라인의 다음 단계를 보여줍니다.

1. 이러한 클러스터 중 하나 또는 모두의 구성을 변경하려면 GitLab에서 유효성을 검사해야 하는 병합 요청(MR)이라는 수정사항을 사용자가 제출합니다.
2. MR은 GitLab에 내장된 지속적 통합 및 전달 시스템인 GitLab CI/CD를 통해 자동화된 파이프라인을 트리거하여 구성을 테스트하고 검증합니다.
3. MR은 관리자에 의해 승인되거나 거부됩니다. 승인 후 변경사항이 Git 저장소로 병합됩니다.
4. 승인이 완료되면 각 클러스터에서 실행 중인 Config Management 에이전트가 GitLab에서 이 수정사항을 읽고 해당 클러스터에 적용합니다.

Config Management 컨텍스트에서 GitLab 호스팅 시 권장사항

이 섹션에서는 GitLab SCM을 사용하여 Config Management 저장소를 호스팅하고 관리할 때 따라야 할 권장사항을 설명합니다. 고가용성 아키텍처 및 일반 백업 설정 등 GitLab 호스팅에 적용되는 일반적인 권장사항도 있지만 이 문서에서는 다루지 않습니다.

관리 액세스 제한

권장사항: GitLab에 대한 관리 액세스 권한이 있는 사용자는 Config Management에 대한 관리 액세스 권한도 있기 때문에 이러한 사용자에 대한 제어를 설정합니다.

GitLab을 호스팅하는 가상 머신(또는 Kubernetes 클러스터)에 대한 루트 액세스 권한이 있는 사용자는 GitLab 보안 기능을 우회할 수 있으므로 Config Management의 관리자로 간주됩니다. 이 가정은 GitLab의 관리자이거나 GitLab 데이터베이스에 대한 쓰기 권한이 있는 사용자에게도 적용됩니다. GitLab 관리자 권한, GitLab을 호스팅하는 가상 머신(또는 Kubernetes 클러스터)에 대한 루트 액세스 권한 또는 GitLab 데이터베이스에 대한 액세스 권한이 부여된 사용자는 Config Management에서도 변경 작업을 수행할 수 있습니다. 자세한 내용은 GitLab 권한 문서를 참조하세요.

Compute Engine을 사용 중인 경우 ID 및 액세스 관리 (IAM) 및 OS 로그인 서비스를 이용하여 누가 인스턴스에 액세스할 수 있는지 제어하세요. 특히 Compute OS 관리자 로그인 역할은 인스턴스에 대한 루트 액세스 권한을 부여합니다.

GKE를 사용하는 경우 IAM 및 RBAC를 사용하여 클러스터에 액세스할 수 있는 사용자를 제어합니다.

정기적인 업데이트

권장사항: 정기적으로, 보안 패치가 출시될 때마다 GitLab을 업데이트합니다.

GitLab은 매달 한 개씩 출시 버전을 제공하고 각 출시 버전 사이에 패치 출시 버전을 여러 개 제공합니다. GitLab은 여느 소프트웨어와 마찬가지로 이러한 출시 버전 중 일부에 보안 패치도 제공합니다. 따라서 GitLab 인스턴스를 가능한 한 최신 상태로 유지해야 합니다. 자세한 내용은 GitLab 업데이트를 참조하세요.

Google Cloud에서 GitLab을 호스팅하는 방법에 대한 Google Cloud 관련 권장사항 따르기

권장사항: Google Cloud에서 GitLab을 호스팅하는 경우 조직 노드 아래에 전용 Google Cloud 프로젝트를 배치합니다.

Google Cloud에서 GitLab을 호스팅하는 경우 GitLab 전용 Google Cloud 프로젝트를 지정해야 합니다. 이러한 Google Cloud 프로젝트는 폴더가 아닌 조직 노드 바로 아래에 배치해야 합니다. 이러한 권장사항을 따르면 다음과 같은 IAM 구성 오류의 가능성을 줄일 수 있습니다.

• GitLab이 다른 앱과 Google Cloud 프로젝트를 공유할 경우 다른 앱에 대한 액세스가 허용될 때 실수로 GitLab에 대한 관리 액세스 권한이 부여될 수 있습니다.
• Google Cloud 프로젝트를 폴더에 배치할 경우 해당 폴더에 대한 액세스 권한을 부여할 때 실수로 해당 Google Cloud 프로젝트에 대한 액세스 권한을 부여할 수 있습니다.

Google Cloud에 GitLab을 배포하는 경우 다음과 같은 관리형 서비스도 활용하는 것이 좋습니다.

• PostgreSQL용 Cloud SQL을 사용하여 GitLab의 데이터베이스를 호스팅합니다. Cloud SQL은 고가용성 및 백업을 자동으로 처리합니다.
• Redis용 Memorystore를 GitLab Redis 서버로 사용합니다. Memorystore는 고가용성을 자동으로 처리합니다.
• Cloud Storage를 사용하여 백업, 빌드 아티팩트 및 사용자 업로드를 저장합니다.

GitLab의 인증 및 액세스 제어

감사 또는 디버깅의 경우 정책 변경자를 식별하는 것이 중요하며, IT 직원이 다양한 리소스를 관리할 때도 해당 ID가 사용됩니다.

통합 ID 사용

권장사항: 동일한 ID 공급업체(IdP)를 사용하도록 GitLab을 포함한 모든 시스템을 구성합니다.

기본적으로 리소스를 생성, 업데이트, 삭제하는 Git 저장소를 통해 Config Management와 상호작용합니다. Git 저장소는 어느 사용자가 어떤 작업을 수행할 수 있는지, 모든 활동을 어디에서 감사할 수 있는지 제어하는 곳입니다. 직원이 Google Cloud, GitLab, 온프레미스 시스템의 모든 위치에서 동일한 ID를 사용하면 액세스 제어 및 감사를 더욱 쉽게 구현할 수 있습니다. 통합 ID를 사용하면 서로 다른 시스템에서 권한 및 감사 로그를 상호 참조할 수 있습니다.

GitLab에서 그룹, 프로젝트, 인스턴스의 이벤트를 감사하고 시스템 로그에서 GitLab 서비스 수준 이벤트를 쿼리할 수 있습니다. GitLab 감사 이벤트 기능은 엔터프라이즈 라이선스 등급에 적용됩니다.

Google을 ID 공급업체로 사용하지 않는 경우

Google Cloud를 Active Directory, Azure Active Directory 또는 Okta와 같은 여러 인기 IdP와 제휴할 수 있습니다. Active Directory 또는 Okta를 사용하도록 GitLab을 구성할 수 있습니다.

참고: GitLab 무료 버전에는 기본 Active Directory 통합이 포함되어 있습니다. 그러나 필터를 사용한 사용자 및 그룹 동기화 및 여러 경량 디렉터리 액세스 프로토콜(LDAP) 서버 지원과 같이 엔터프라이즈에 유용한 다양한 기능은 GitLab Enterprise의 라이선스 기능입니다.

Google을 ID 공급업체로 사용하는 경우

Google을 ID 공급업체로 사용하는 경우 Google OAuth 2.0 OmniAuth 공급업체 또는 보안 LDAP를 사용할 수 있습니다. 그러나 다음 섹션에서 권장하는 대로 그룹을 GitLab과 동기화하려면 보안 LDAP를 사용해야 합니다. 보안 LDAP는 Cloud ID Premium 및 Google Workspace Enterprise에서 제공됩니다. 자세한 내용은 보안 LDAP 서비스 정보를 참조하세요.

그룹을 GitLab과 동기화

권장사항: 가능한 경우 GitLab Enterprise의 라이선스 기능인 LDAP 그룹 동기화 기능을 사용하여 기존 사용자 그룹을 GitLab과 동기화합니다.

사용자를 식별하는 데 사용되는 기술에 관계없이 사용자를 그룹화하여 액세스를 구성하는 것이 좋습니다. 권한을 부여할 때 그룹을 사용하면 이러한 사용자를 상위 수준에서 생각할 수 있습니다. 즉, '앨리스, 밥, 클라우디아, 디네시에게 프로덕션 환경에 대한 관리 액세스 권한 부여'라는 개념 대신 '내 운영 그룹에게 프로덕션 환경에 대한 관리 액세스 권한 부여'라는 개념이 적용됩니다. 인사부 프로세스가 IT 시스템과 잘 통합되면 직원 채용, 퇴사 또는 직무 변경 시 그룹 구성원 자격도 자동으로 관리됩니다. 그룹을 사용할 경우 일반적으로 액세스 제어 설정을 업데이트할 필요가 없습니다.

Config Management는 민감한 시스템이므로 사용자 그룹을 사용하여 Config Management에 대한 액세스를 제어하는 것이 중요합니다. GitLab에서 사용자 그룹과 프로젝트를 공유하고 이 그룹의 구성원에게 부여할 액세스 수준을 지정할 수 있습니다.

2단계 인증 시행

권장사항: Config Management와 상호작용하는 사용자에게 2FA를 적용하여 사용자 인증 정보 도난 및 피싱 문제를 방지합니다.

2단계 인증이라고도 하는 2FA를 사용하여 조직의 보안을 개선해야 합니다. 사용자 인증 정보 및 피싱 공격은 일반적인 공격 벡터이며, 2FA는 이러한 공격으로부터 보호하는 데 도움이 됩니다. Config Management Git 저장소의 민감한 특성 때문에 Anthos Config Management와 상호작용하는 사용자의 계정은 2FA를 사용 설정하여 최대한 보호해야 합니다.

GitLab에 싱글 사인온(SSO)을 구성하는 경우 SSO 공급자에게 2FA를 적용해야 합니다. Google을 SSO 공급업체로 사용하는 경우 2FA를 사용 설정할 수 있습니다.

GitLab에 SSO를 구성하지 않은 경우 GitLab에 2FA를 직접 적용할 수 있습니다.

배포 키 또는 토큰을 사용하여 Config Management 에이전트를 GitLab에 연결

권장사항:

• 배포 키 또는 배포 토큰을 사용하여 GitLab에 연결하도록 Config Management 에이전트를 구성합니다.
• 암호화되지 않은 HTTP는 Config Management를 중간자 공격에 노출시키므로 사용하지 마세요.
• Config Management 저장소에서 각 Kubernetes 클러스터에 고유한 배포 키 또는 토큰을 만듭니다.
• Config Management 저장소에서 직접 배포 키와 토큰을 구성합니다.

Config Management 설치 문서에 설명된 대로 일반적인 Git 방식인 HTTP(S) 또는 SSH를 사용하여 Config Management 에이전트를 저장소에 연결할 수 있습니다. HTTP(S)를 사용하여 GitLab에서 호스팅되는 저장소에 액세스하는 경우 사용자 계정을 사용하지 마세요. 라이선스 문제나 자체 계정을 사용하여 Config Management를 구성하는 사용자와 같은 문제가 발생할 수 있습니다. GitLab에서 키 배포 및 배포 토큰을 사용하는 것이 더 좋은 방법입니다. 배포 키는 특정 사용자에게 연결되지 않은 SSH 키이지만 Config Management에서 필요한 보안 액세스 유형인 Git 작업을 자동 시스템에서 수행하는 데 사용될 수 있습니다. 배포 토큰은 배포 키와 동일한 용도로 사용되지만 SSH 대신 HTTP를 통해 인증할 수 있습니다.

고유한 배포 키와 토큰을 사용하여 클러스터별로 Config Management 에이전트의 Git 저장소 액세스를 제어하고 취소할 수 있습니다. Avoid using <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="opBB/mAJqPUFZffWWDKJfMvOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwlKMkBQSfMxp5fl+Mc9AjFx4o6T+DhcfK0B6wN+3j0FU=" track-metadata-position="body" track-name="externalLink" track-type="solution">global deploy keys for Config Management and <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="EVE38A1n4riTbiBLnLIE18vOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwnjars0LTR/vDhAa2T615gjvG0B0C/P1DzOlB98jatvw=" track-metadata-position="body" track-name="externalLink" track-type="solution">group deploy tokens. Config Management 이외의 용도로도 구성을 사용할 수 있으며 구성이 변경되면 의도하지 않은 부작용이 발생합니다.</atarget="external"></atarget="external">

병합 요청을 승인할 수 있는 사용자 관리

권장사항: Config Management 저장소에서 병합 요청의 승인 지연에 주의합니다. 승인 지연이 비정상적으로 증가하는 경우 코드 소유자 또는 고급 병합 요청 승인을 사용하여 승인 권한을 조직의 더 많은 사용자에게 위임합니다.

기본적으로 GitLab은 역할을 사용하여 GitLab 프로젝트에 대한 권한을 부여합니다. 예를 들어 개발자 역할이 부여된 사용자는 병합 요청을 열 수 있고 유지 관리 담당자 역할이 부여된 사용자는 요청을 승인할 수 있습니다. 이 권한 시스템은 처음에는 Config Management에서 잘 작동하지만 Kubernetes 및 Config Management 사용 공간이 늘어날수록 문제가 발생할 수 있습니다. Config Management 저장소의 유지 관리 담당자가 처리하고 승인해야 할 병합 요청 수가 감당하지 못할 정도로 많아질 수 있습니다.

GitLab 프리미엄 기능을 활용하면 이러한 문제를 해결할 수 있습니다.

• 코드 소유자를 사용하여 파일 또는 디렉터리별로 승인 권한을 위임할 수 있습니다. Config Management는 디렉터리 구조를 사용하여 클러스터와 네임스페이스를 설명하기 때문에 이 기능이 유용합니다. 예를 들어 코드 소유자를 사용하여 모든 클러스터에서 특정 네임스페이스에 대한 승인 권한을 위임할 수 있습니다.
• 병합 요청 승인을 사용하면 여러 팀의 다른 사용자가 요청이 병합되기 전에 승인하도록 할 수 있습니다. 예를 들어 운영팀과 보안팀에서 각각 한 명씩 총 두 명의 승인자가 병합 요청을 승인하도록 할 수 있습니다.

다음 다이어그램은 조직의 기술 부서를 보여주고 프로덕션 환경에서 승인 위임이 작동하는 방식의 예시를 보여줍니다.

위의 다이어그램에는 보안팀, 플랫폼팀, 여러 앱팀과 같은 여러 팀으로부터 보고를 받는 최고기술책임자(CTO)가 있습니다.

이 조직의 Config Management Git 저장소 구조는 다음과 같습니다(파일이 아닌 디렉터리만 표시).

.
├─ system
├─ clusterregistry
├─ cluster
└─ namespaces
   ├─ cicd
   ├─ audit
   └─ applications
      ├─ team-a
      └─ team-b

각 디렉터리에 대한 자세한 내용은 Config Management 저장소 사용을 참조하세요.

이러한 구조를 사용하는 조직은 앞서 언급한 GitLab 기능을 사용하여 다음 프로세스를 구현할 수 있습니다.

• 저장소의 루트 또는 system 디렉터리 수정 시에는 CTO의 승인을 받아야 합니다.
• clusterregistry 디렉터리 수정 시에는 플랫폼팀 구성원의 승인을 받아야 합니다.
• cluster 디렉터리 수정 시에는 플랫폼팀 구성원과 보안팀 구성원 모두의 승인을 받아야 합니다.
• namespaces 디렉터리 수정 시에는 플랫폼팀 구성원의 승인을 받아야 합니다.

• namespaces 디렉터리의 하위 디렉터리 수정 시에는 다음 팀의 승인을 받아야 합니다.

  • cicd 하위 디렉터리는 지속적 통합 및 지속적 배포(CI/CD) 도구 전용 네임스페이스를 나타냅니다. 이를 변경하려면 플랫폼팀 구성원의 승인을 받아야 합니다.
  • audit 하위 디렉터리는 감사 도구 전용 네임스페이스를 나타냅니다. 이를 변경하려면 보안팀 구성원의 승인을 받아야 합니다.
  • applications 하위 디렉터리에는 모든 앱 네임스페이스용으로 생성된 모든 리소스가 포함됩니다. 이를 변경하려면 플랫폼팀 구성원과 보안팀 구성원 모두의 승인을 받아야 합니다.
  • team-a 및 team-b 하위 디렉터리는 A 팀과 B 팀 전용 네임스페이스를 나타냅니다. 이를 변경하려면 해당 팀장의 승인을 받아야 합니다.

ID 공급업체의 그룹이 GitLab과 동기화된 경우 그룹이 동기화되지 않은 경우보다 이 프로세스를 구현하기가 더 쉽습니다. 병합 요청에 여러 그룹의 다양한 승인을 요구할 수 있습니다. 자세한 내용은 GitLab과 그룹 동기화 및 승인 수정을 참조하세요.

공유 실행기 사용 중지

권장사항: Config Management 프로젝트의 공유 실행기를 사용 중지하고 이 프로젝트의 전용 실행기만 사용합니다.

Config Management 배포하기 전에 GitLab CI를 사용하여 자동으로 테스트할 수 있습니다. GitLab CI는 실행기를 사용하여 사용자가 원하는 작업을 실행합니다. 이러한 실행기는 전체 GitLab 인스턴스와 공유할 수 있으며, 이 경우 동일한 팀에서 GitLab 인스턴스 자체로 또는 GitLab 그룹 또는 GitLab 프로젝트 전용으로 유지 관리합니다.

Config Management 저장소의 민감한 특성 때문에 Config Management 코드를 테스트할 때 공유 실행기를 사용하지 않는 것이 좋습니다. 대신 병합 요청을 승인할 수 있는 사용자가 유지 관리하는 Config Management 프로젝트 전용 실행기를 사용하세요.

권장사항 요약

이 섹션에서는 이전 섹션의 권장사항을 요약합니다. GitLab을 사용하여 Config Management Git 저장소를 호스팅하는 경우 다음을 권장합니다.

• GitLab에 대한 관리 액세스 권한이 있는 사용자는 Config Management에 대한 관리 액세스 권한도 있기 때문에 이러한 사용자에 대한 제어를 설정합니다.
• 정기적으로, 보안 패치가 출시될 때마다 GitLab을 업데이트합니다.
• Google Cloud에서 GitLab을 호스팅하는 경우 조직 노드 아래에 GitLab 전용 Google Cloud 프로젝트를 배치합니다.
• GitLab을 비롯한 모든 시스템이 동일한 ID 공급업체를 사용하도록 구성합니다.
• 가능한 경우 GitLab Enterprise의 라이선스 기능인 LDAP 그룹 동기화 기능을 사용하여 기존 사용자 그룹을 GitLab과 동기화합니다.
• Config Management와 상호작용하는 사용자에게 2FA를 적용하여 사용자 인증 정보 도난 및 피싱 문제를 방지합니다.
• Config Management 에이전트를 구성할 때 다음 작업을 수행합니다.
  • SSH, 배포 키 또는 HTTPS, 배포 토큰을 사용하여 GitLab에 연결하도록 Config Management 에이전트를 구성합니다.
  • 암호화되지 않은 HTTP는 사용하지 않습니다.
  • Config Management 저장소에서 Kubernetes 클러스터별로 고유한 배포 키 또는 토큰을 만듭니다.
  • Config Management 저장소에서 배포 키와 토큰을 직접 구성하고 Config Management에 전역 배포 키와 그룹 배포 토큰을 사용하지 않습니다.
• Config Management 저장소에서 병합 요청 승인 지연에 주의합니다. 승인 지연이 비정상적으로 증가하는 경우 코드 소유자 또는 고급 병합 요청 승인을 사용하여 승인 권한을 조직의 더 많은 사용자에게 위임합니다.
• Config Management 프로젝트의 공유 실행기를 사용 중지하고 이 프로젝트의 전용 실행기만 사용합니다.

다음 단계

• GKE Enterprise 정책 컨트롤러 알아보기
• CI 파이프라인에서 기업 정책에 따라 앱 인증 알아보기