모든 네임스페이스의 애플리케이션

모든 네임스페이스의 애플리케이션 (Applications in any namespace)

2.5 버전부터 Argo CD는 컨트롤 플레인 네임스페이스(보통 argocd)가 아닌 다른 네임스페이스에서 Application 리소스를 관리하는 것을 지원해요. 단, 이 기능은 명시적으로 활성화하고 적절히 구성해야 해요.

출처: 문서

본문

[!WARNING] 이 기능을 활성화하기 전에 이 문서를 주의 깊게 읽으세요. 잘못 구성하면 보안 문제가 발생할 수 있어요.

소개 (Introduction)

2.5 버전부터 Argo CD는 컨트롤 플레인 네임스페이스(보통 argocd)가 아닌 다른 네임스페이스에서 Application 리소스를 관리하는 것을 지원하지만, 이 기능은 명시적으로 활성화하고 적절히 구성해야 해요.

Argo CD 관리자는 Application 리소스를 생성·업데이트·reconcile할 수 있는 특정 네임스페이스 집합을 정의할 수 있어요. 하지만 이 추가 네임스페이스의 애플리케이션은 Argo CD 관리자가 구성한 대로 특정 AppProject만 사용할 수 있어요. 이렇게 하면 일반 Argo CD 사용자(예: 애플리케이션 팀)가 Application 리소스의 선언적 관리를 사용하고, app-of-apps와 같은 패턴을 구현할 수 있게 되면서도, 애플리케이션 팀에 부여된 권한을 초과하는 다른 AppProject 사용을 통한 권한 상승(privilege escalation) 위험을 방지할 수 있어요.

이 기능을 활성화하려면 Argo CD 관리자가 몇 가지 수동 단계를 수행해야 해요.

모든 네임스페이스의 애플리케이션을 채택하는 추가 장점 하나는, 최종 사용자가 Argo CD 애플리케이션이 실행 중인 네임스페이스에서 해당 애플리케이션에 대한 알림을 구성할 수 있게 된다는 점이에요. 자세한 내용은 알림의 네임스페이스 기반 구성 페이지를 참고하세요.

사전 요구사항 (Prerequisites)

클러스터 범위 Argo CD 설치 (Cluster-scoped Argo CD installation)

이 기능은 Argo CD가 클러스터 전체(cluster-wide) 인스턴스로 설치된 경우에만 활성화하고 사용할 수 있어요. 클러스터 범위에서 리소스를 나열하고 조작할 권한이 있어야 하니까요. 네임스페이스 범위(namespace-scoped) 모드로 설치된 Argo CD에서는 동작하지 않아요.

리소스 추적 방법 전환 (Switch resource tracking method)

기술적으로 필수는 아니지만, 애플리케이션 추적 방법을 기본 label 설정에서 annotation 또는 annotation+label로 전환하는 것을 강력히 권장해요. 그 이유는 애플리케이션 이름이 네임스페이스 이름과 Application 이름의 합성이 될 수 있는데, 이것이 라벨 값에 부과된 63자 길이 제한을 쉽게 초과할 수 있기 때문이에요. 어노테이션은 훨씬 더 큰 길이 제한을 가져요.

어노테이션 기반 리소스 추적을 활성화하려면 리소스 추적 방법 문서를 참고하세요.

구현 세부사항 (Implementation details)

개요 (Overview)

애플리케이션이 Argo CD의 컨트롤 플레인 네임스페이스 밖에서 관리되고 reconcile되기 위해서는 두 가지 사전 요구사항이 일치해야 해요:

1. Application의 네임스페이스는 argocd-application-controller와 argocd-server 워크로드의 --application-namespaces 파라미터로 명시적으로 활성화되어야 해요. 이 파라미터는 Argo CD가 전역적으로 Application 리소스를 소싱할 수 있는 네임스페이스 목록을 제어해요. 여기에 구성되지 않은 네임스페이스는 어떤 AppProject에서도 사용할 수 없어요.

2. Application의 .spec.project 필드가 참조하는 AppProject는 .spec.sourceNamespaces 필드에 그 네임스페이스를 나열해야 해요. 이 설정은 Application이 특정 AppProject를 사용할 수 있는지 결정해요. Application이 허용되지 않는 AppProject를 지정하면 Argo CD는 이 Application 처리를 거부해요. 위에서 말했듯이 .spec.sourceNamespaces 필드에 구성된 모든 네임스페이스는 전역적으로도 활성화되어야 해요.

다른 네임스페이스의 Application은 이전에 argocd 네임스페이스의 다른 Application처럼 선언적으로 또는 Argo CD API(예: CLI, web UI, REST API 등 사용)를 통해 생성·관리할 수 있어요.

특정 네임스페이스를 허용하도록 Argo CD 재구성 (Reconfigure Argo CD to allow certain namespaces)

워크로드 시작 파라미터 변경 (Change workload startup parameters)

이 기능을 활성화하려면 Argo CD 관리자가 argocd-server와 argocd-application-controller 워크로드를 재구성해서 컨테이너 시작 명령에 --application-namespaces 파라미터를 추가해야 해요.

--application-namespaces 파라미터는 Application을 허용할 네임스페이스의 쉼표로 구분된 목록을 받아요. 목록의 각 항목은 다음을 지원해요:

• 셸 스타일 와일드카드(예: *). 예를 들어 app-team-* 항목은 app-team-one과 app-team-two와 일치해요. Argo CD가 실행 중인 클러스터의 모든 네임스페이스를 활성화하려면 *를 지정하면 돼요(즉, --application-namespaces=*).
• 정규식, 문자열을 /로 감싸야 해요. 예를 들어 특정 네임스페이스 하나를 제외한 모든 네임스페이스를 허용하려면 /^((?!not-allowed).)*$/.

argocd-server와 argocd-application-controller 둘 다의 시작 파라미터는 각 워크로드의 매니페스트를 변경하는 대신 argocd-cmd-params-cm ConfigMap에서 application.namespaces 설정을 지정해서 편리하게 설정하고 동기화 상태를 유지할 수도 있어요. 예를 들어:

data:
  application.namespaces: app-team-one, app-team-two

이렇게 하면 app-team-one과 app-team-two 네임스페이스에서 Application 리소스를 관리할 수 있어요. argocd-cmd-params-cm 네임스페이스를 변경한 후에는 해당 워크로드를 재시작해야 해요:

kubectl rollout restart -n argocd deployment argocd-server
kubectl rollout restart -n argocd statefulset argocd-application-controller

Kubernetes RBAC 적용 (Adapt Kubernetes RBAC)

현재로서는 기본적으로 argocd-server 워크로드의 Kubernetes RBAC를 확장하지 않기로 결정했어요. 다른 네임스페이스의 Application이 Argo CD API(즉 CLI와 UI)로 관리되게 하려면 argocd-server ServiceAccount의 Kubernetes 권한을 확장해야 해요.

examples/k8s-rbac/argocd-server-applications 디렉터리에 이 목적에 적합한 ClusterRole과 ClusterRoleBinding을 제공해요. 기본 Argo CD 설치(즉 argocd 네임스페이스에 설치된)의 경우 그대로 적용할 수 있어요:

kubectl apply -k examples/k8s-rbac/argocd-server-applications/

argocd-notifications-controller-rbac-clusterrole.yaml과 argocd-notifications-controller-rbac-clusterrolebinding.yaml은 알림 컨트롤러가 모든 네임스페이스의 앱에 알리도록 지원하는 데 사용돼요.

[!NOTE] 언젠가 이 클러스터 역할을 기본 설치 매니페스트의 일부로 만들 수도 있어요.

AppProject에서 추가 네임스페이스 허용 (Allowing additional namespaces in an AppProject)

Argo CD 컨트롤 플레인 네임스페이스(argocd)에 Kubernetes 접근 권한이 있는 사용자, 특히 선언적 방식으로 Application을 생성하거나 업데이트할 권한이 있는 사용자는 Argo CD 관리자로 간주돼요.

이것은 과거에 권한이 없는 Argo CD 사용자가 Application을 선언적으로 생성하거나 관리하는 것을 막았어요. 그런 사용자는 Argo CD RBAC의 적용을 받는 API 사용으로 제한되었고, 허용된 AppProject의 Application만 생성되도록 보장했어요.

argocd 네임스페이스 밖에서 Application을 생성하려면, Application의 .spec.project 필드가 참조하는 AppProject가 .spec.sourceNamespaces 필드에 Application의 네임스페이스를 포함해야 해요.

예를 들어 다음 두 개의 (불완전한) AppProject 스펙을 고려하세요:

kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
  name: project-one
  namespace: argocd
spec:
  sourceNamespaces:
    - namespace-one

그리고:

kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
  name: project-two
  namespace: argocd
spec:
  sourceNamespaces:
    - namespace-two

Application이 .spec.project를 project-one으로 설정하려면 namespace-one 또는 argocd 네임스페이스에서 생성되어야 해요. 마찬가지로 Application이 .spec.project를 project-two로 설정하려면 namespace-two 또는 argocd 네임스페이스에서 생성되어야 해요.

namespace-two의 Application이 .spec.project를 project-one으로 설정하거나 namespace-one의 Application이 .spec.project를 project-two로 설정하면, Argo CD는 이를 권한 위반으로 간주하고 Application의 reconcile을 거부해요.

또한 Argo CD API는 Argo CD RBAC 권한과 관계없이 이러한 제약을 강제해요.

AppProject의 .spec.sourceNamespaces 필드는 임의의 수의 네임스페이스를 포함할 수 있는 목록이며, 각 항목은 셸 스타일 와일드카드를 지원하므로 team-one-* 같은 패턴으로 네임스페이스를 허용할 수 있어요.

[!WARNING] default 같은 권한 있는 AppProject의 .spec.sourceNamespaces 필드에 사용자 제어 네임스페이스를 추가하지 마세요. AppProject가 최소 필요 권한 부여 원칙을 따르도록 항상 확인하세요. AppProject 안에서 argocd 네임스페이스에 대한 접근을 절대 부여하지 마세요.

[!NOTE] 역호환성을 위해 Argo CD 컨트롤 플레인 네임스페이스(argocd)의 Application은 AppProject의 .spec.sourceNamespaces 필드가 부과한 제한과 관계없이 .spec.project 필드가 어떤 AppProject든 참조하도록 설정할 수 있어요.

[!NOTE] 현재 한 네임스페이스에 applicationset을 두고 다른 네임스페이스에 application을 생성하는 것은 불가능해요. 자세한 내용은 #11104를 참고하세요.

애플리케이션 이름 (Application names)

CLI와 UI에서 애플리케이션은 이제 <namespace>/<name> 형식으로 참조되고 표시돼요.

역호환성을 위해 Application의 네임스페이스가 컨트롤 플레인 네임스페이스(즉 argocd)라면, 애플리케이션 이름을 참조할 때 <namespace>를 생략할 수 있어요. 예를 들어 argocd/someapp과 someapp 애플리케이션 이름은 의미상 같으며 CLI와 UI에서 같은 애플리케이션을 참조해요.

애플리케이션 RBAC (Application RBAC)

Application 객체의 RBAC 문법은 <project>/<application>에서 <project>/<namespace>/<application>으로 변경되었어요. 관리할 Application의 소스 네임스페이스에 따라 접근을 제한해야 하기 때문이에요.

역호환성을 위해 argocd 네임스페이스의 Application은 RBAC 정책 규칙에서 여전히 <project>/<application>으로 참조돼요.

[!NOTE] 역호환성 때문에 foo/argocd/* 패턴을 사용해 Argo CD 컨트롤 플레인 네임스페이스(보통 argocd)의 애플리케이션에 대한 RBAC 정책을 특별히 정의하는 것은 불가능해요. 컨트롤 플레인 네임스페이스의 애플리케이션은 RBAC 강제 시 항상 2-세그먼트 형식 <project>/<application>으로 정규화돼요. 보안상의 이유로 AppProject는 .spec.sourceNamespaces 필드를 통해 컨트롤 플레인 네임스페이스에 대한 접근을 절대 부여해서는 안 돼요. 그러면 사용자가 상승된 권한으로 애플리케이션을 만들 수 있게 되기 때문이에요.

와일드카드는 아직 프로젝트와 애플리케이션 네임스페이스를 구분하지 않아요. 예를 들어 다음 RBAC 규칙은 생성된 네임스페이스와 관계없이 foo 프로젝트에 속한 모든 애플리케이션과 일치해요:

p, somerole, applications, get, foo/*, allow

bar 네임스페이스 안의 foo 프로젝트에 있는 Application에만 접근을 제한하려면 규칙을 다음과 같이 수정해야 해요:

p, somerole, applications, get, foo/bar/*, allow

다른 네임스페이스의 애플리케이션 관리 (Managing applications in other namespaces)

선언적으로 (Declaratively)

Application을 선언적으로 관리하려면 원하는 네임스페이스에서 YAML이나 JSON 매니페스트로 Application을 만들기만 하면 돼요. .spec.project 필드가 이 네임스페이스를 허용하는 AppProject를 참조하는지 확인하세요. 예를 들어 다음 (불완전한) Application 매니페스트는 some-namespace 네임스페이스에 Application을 만들어요:

kind: Application
apiVersion: argoproj.io/v1alpha1
metadata:
  name: some-app
  namespace: some-namespace
spec:
  project: some-project
  # ...

그런 다음 some-project 프로젝트는 허용된 소스 네임스페이스 목록에 some-namespace를 지정해야 해요:

kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
  name: some-project
  namespace: argocd
spec:
  sourceNamespaces:
    - some-namespace

CLI 사용 (Using the CLI)

기존 Argo CD CLI 명령을 모두 사용해 다른 네임스페이스의 애플리케이션을 관리할 수 있어요. 컨트롤 플레인 네임스페이스의 애플리케이션을 관리할 때와 정확히 같은 방식으로요.

예를 들어 bar 네임스페이스에서 foo라는 Application을 조회하려면 다음 CLI 명령을 사용할 수 있어요:

argocd app get foo/bar

마찬가지로 이 애플리케이션을 관리할 때는 계속 foo/bar로 참조하세요:

# Create an application
argocd app create foo/bar ...
# Sync the application
argocd app sync foo/bar
# Delete the application
argocd app delete foo/bar
# Retrieve application's manifest
argocd app manifests foo/bar

앞서 말했듯이 Argo CD 컨트롤 플레인 네임스페이스의 애플리케이션은 애플리케이션 이름에서 네임스페이스를 생략할 수 있어요.

UI 사용 (Using the UI)

CLI와 유사하게 UI에서도 애플리케이션을 foo/bar로 참조할 수 있어요.

예를 들어 foo 네임스페이스에 bar라는 애플리케이션을 만들려면 생성 대화상자의 Application Name 필드에 foo/bar를 설정하세요. 네임스페이스를 생략하면 컨트롤 플레인 네임스페이스가 사용돼요.

REST API 사용 (Using the REST API)

REST API를 사용하는 경우 Application의 네임스페이스는 애플리케이션 이름으로 지정할 수 없고, 선택적 appNamespace 쿼리 파라미터로 리소스를 지정해야 해요. 예를 들어 bar 네임스페이스에서 foo라는 Application 리소스로 작업하려면 요청은 다음과 같을 거예요:

GET /api/v1/applications/foo?appNamespace=bar

POST와 PUT 같은 다른 작업의 경우 appNamespace 파라미터가 요청의 payload에 포함되어야 해요.

컨트롤 플레인 네임스페이스의 Application 리소스는 이 파라미터를 생략할 수 있어요.

더 알아보기 (Learn more)

• 리소스 추적 방법 (Resource Tracking Methods)
• AppProject 스펙 (Project Specification)
• 문서: Applications in any namespace