v2.4에서 v2.5로 업그레이드
v2.4에서 v2.5로 업그레이드 (v2.4 to 2.5)
v2.5에서는 새 applicationsets RBAC 리소스가 생기고, argocd-cm 기반 구성 관리 플러그인(CMP)이 디프리케이트되며 dex 서버에 TLS가 기본 활성화돼요. 또 out-of-bounds 심링크가 fetch 시점에 차단되도록 보안 검사가 추가됐어요.
출처: 문서
본문
알려진 이슈 (Known Issues)
2.5.15 이전의 깨진 project 필터
Argo CD 2.4.0은 project 필터를 projects로 이름을 바꾸는, 호환성이 깨지는 API 변경을 도입했어요.
API 클라이언트에 미치는 영향
REST API로 Argo CD API 서버와 통신하는 다른 API 클라이언트에도 비슷한 문제가 적용돼요. 클라이언트가 project 필드를 사용해 프로젝트를 필터링한다면 필터가 적용되지 않아요. 실패하는 project 필터는, 예를 들어 삭제할 Application 목록을 만드는 데 의존한다면 심각한 결과를 초래할 수 있어요.
CLI 클라이언트에 미치는 영향
v2.4.0보다 오래된 CLI 클라이언트는 클라이언트 측 필터링에 의존하므로 이 버그의 영향을 받지 않아요.
문제 해결 방법
Argo CD >=2.4.27, >=2.5.15 또는 >=2.6.6으로 업그레이드하세요. 이 버전의 Argo CD는 project와 projects를 모두 유효한 필터로 받아들여요.
2.5.14의 깨진 matrix 중첩 git files 생성기
Argo CD 2.5.14는 matrix 중첩 git files 생성기에 버그를 도입했어요. 이 버그는 git files 생성기가 matrix 아래에 중첩된 두 번째 생성기일 때만 적용돼요. 예를 들어:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: guestbook
spec:
generators:
- matrix:
generators:
- clusters: {}
- git:
repoURL: https://git.example.com/org/repo.git
revision: HEAD
files:
- path: "defaults/*.yaml"
template:
# ...
중첩된 git files 생성기가 파라미터를 생성하지 않으면, matrix 생성기도 파라미터를 생성하지 않아요. 이로 인해 ApplicationSet이 Application을 생성하지 못해요. ApplicationSet 컨트롤러가 애플리케이션을 삭제할 수 있도록 구성되어 있다면, 이전에 ApplicationSet이 생성한 모든 Application을 삭제하게 돼요.
이 문제를 피하려면 >=2.5.15 또는 >= 2.6.6으로 바로 업그레이드하세요.
새 applicationsets 리소스에 맞춰 RBAC 구성
2.5는 새 applicationsets RBAC 리소스를 도입해요.
2.5로 업그레이드하면, 리소스 필드에 *가 있고 액션 필드에 create, update, delete, get 또는 *가 있는 RBAC 정책은 자동으로 applicationsets 권한을 부여해요.
새 권한 부여를 피하려면 기존 정책을 이전 리소스를 명시적으로 나열한 새 정책 목록으로 바꾸세요.
예시
이전:
p, role:org-admin, *, create, *, allow
새로:
p, role:org-admin, clusters, create, *, allow
p, role:org-admin, projects, create, *, allow
p, role:org-admin, applications, create, *, allow
p, role:org-admin, repositories, create, *, allow
p, role:org-admin, certificates, create, *, allow
p, role:org-admin, accounts, create, *, allow
p, role:org-admin, gpgkeys, create, *, allow
p, role:org-admin, exec, create, *, allow
(목록에서 applicationsets가 빠진 것에 주의하세요. 이는 2.5 이전 권한을 보존하기 위함이에요.)
argocd-cm 플러그인(CMP) 디프리케이트
Argo CD v2.5부터 argocd-cm ConfigMap을 통한 구성 관리 플러그인(CMP) 설치는 디프리케이트됐어요. 지원은 v2.7에서 제거될 예정이에요.
플러그인을 repo-server Deployment의 사이드카로 설치하면 계속 사용할 수 있어요.
사이드카 플러그인은 훨씬 더 안전해요. 플러그인 코드는 거의 완전히 격리된 파일시스템을 가진 자체 컨테이너에서 실행돼요. 공격자가 플러그인을 손상시키더라도 피해를 입힐 수 있는 능력이 크게 줄어들어요.
argocd-cm 플러그인이 여전히 사용 중인지 확인하려면 argocd-repo-server와 argocd-server 로그에서 다음 메시지를 검사하세요:
argocd-cm plugins are deprecated, and support will be removed in v2.6. Upgrade your plugin to be installed via sidecar. https://argo-cd.readthedocs.io/en/stable/user-guide/config-management-plugins/
참고: argocd-cm 플러그인 지원 제거는 v2.7로 연기되었어요. 로그 검사에 v2.6 대신 v2.7을 사용하도록 업데이트하세요.
관리자로 argocd app list를 실행하면, 디프리케이트된 플러그인을 사용하는 Application 목록이 경고로 기록돼요.
Dex 서버 TLS 구성
dex 서버와 Argo CD API 서버 사이의 통신을 보호하기 위해, dex 서버에서 TLS가 이제 기본적으로 활성화돼요.
기본적으로 구성 없이도 dex 서버는 시작 시 자체 서명 인증서를 생성해요. 다만 argocd-dex-server-tls 시크릿으로 자체 TLS 인증서를 구성하는 것이 좋아요. 자세한 내용은 TLS 구성 가이드를 참고하세요.
잘못된 사용자.session.duration 값은 이제 24h로 폴백
v2.5 이전에는 argocd-cm의 잘못된 users.session.duration 값이 1) 경고를 기록하고 2) 사용자 세션에 기간 제한이 없는 결과를 초래했어요.
v2.5부터 잘못된 duration 값은 경고와 함께 기본값인 24시간으로 폴백해요.
Out-of-bounds 심링크가 fetch 시점에 차단
과거에 심링크와 관련된 여러 경로 탐색(path traversal) 및 식별 취약점이 공개된 적이 있어요. 추가 취약점을 막기 위해, 이제 모든 저장소와 Helm 차트를 fetch 시점에 out of bounds 심링크에 대해 검사하고 발견되면 추가 처리를 차단해요.
out-of-bounds 심링크는 최종 대상이 루트 내부에 있더라도 Git 저장소나 Helm 차트의 루트를 벗어나는 모든 심링크로 정의돼요.
out of bounds 심링크가 발견되면 repo 서버 콘솔에 경고가 출력되고 UI 또는 CLI에 오류가 표시돼요.
다음은 유효한 심링크와 유효하지 않은 심링크를 보여주는 예시 디렉터리 구조예요.
chart
├── Chart.yaml
├── values
│ └── values.yaml
├── bad-link.yaml -> ../out-of-bounds.yaml # Blocked
├── bad-link-2.yaml -> ../chart/values/values.yaml # Blocked because it leaves the root
├── bad-link-3.yaml -> /absolute/link.yaml # Blocked
└── good-link.yaml -> values/values.yaml # OK
out of bounds 심링크에 의존한다면 다음 세 가지 방법 중 하나로 이 검사를 비활성화할 수 있어요:
- repo 서버의
--allow-oob-symlinks인자 argocd-cmd-params-cm을 사용한다면reposerver.allow.oob.symlinks키- repo 서버에
ARGOCD_REPO_SERVER_ALLOW_OOB_SYMLINKS환경 변수를 직접 설정
이 검사를 활성화 상태로 두는 것을 강력히 권장해요. 검사를 비활성화해도 모든 out-of-bounds 심링크가 허용되는 것은 아니에요. Helm 차트의 values 파일 같은 것들은 여전히 차단되지만, 다른 검사에서 명시적으로 차단되지 않는 심링크는 허용돼요.
클라이언트 측 매니페스트 diff 디프리케이트
argocd app diff --local을 사용하면, repo 서버의 코드가 사용자 머신에서 실행되어 앱의 라이브 매니페스트와 비교할 매니페스트를 로컬로 생성해요. 그런데 이를 위해서는 필요한 도구(Helm, Kustomize 등)가 올바른 버전으로 설치되어 있어야 해요. 설상가상으로 구성 관리 플러그인(CMP)은 전혀 지원하지 않아요.
CMP를 지원하고 로컬 요구 사항을 줄이기 위해 --server-side-generate 인자로 로컬 매니페스트의 서버 측 생성을 구현했어요. 예를 들어 argocd app diff --local repoDir --server-side-generate는 repoDir의 내용을 repo 서버에 업로드하고, Git 저장소에서처럼 동일하게 매니페스트 생성 파이프라인을 실행해요.
v2.7에서 --server-side-generate 인자가 기본값이 되고, 클라이언트 측 생성은 대안으로 지원될 예정이에요.
경고
Argo가 저장소 안에서 매니페스트 생성을 시작하는 위치의 의미가 클라이언트 측 생성과 서버 측 생성 사이에서 달라졌어요. 클라이언트 측 생성에서는 애플리케이션의 경로(spec.source.path)가 무시되고 --local-repo-root 값(기본적으로 --local 기준 /)이 실질적으로 사용됐어요.
예를 들어 애플리케이션 경로가 /manifests인 애플리케이션이 있다면, argocd app diff --local yourRepo/manifests를 실행해야 했어요. 이 동작은 전체 repo/차트를 다운로드한 다음 애플리케이션 매니페스트에 지정된 경로에서 생성을 시작하는 repo 서버의 방식과 일치하지 않았어요.
서버 측 생성으로 전환할 때 --local은 spec.source.path를 포함하지 않은 저장소 루트를 가리켜야 해요. 이는 --server-side-generate가 v2.7에서 기본값이 될 때 특히 유의해야 해요. spec.source.path가 /가 아닌 경우, diff --local을 사용하는 기존 스크립트는 v2.7에서 깨질 수 있어요.
Kustomize 버전 업그레이드
번들로 제공되는 Kustomize 버전이 4.4.1에서 4.5.7로 업그레이드됐어요.
Helm 버전 업그레이드
번들로 제공되는 Helm 버전이 3.9.0에서 3.10.1로 업그레이드됐어요.
HAProxy 버전 업그레이드
HA 매니페스트의 HAProxy 버전이 2.0.25에서 2.6.2로 업그레이드됐어요. 변경/개선 사항을 보려면 HAProxy 메이저 릴리스 발표(2.1.0, 2.2.0, 2.3.0, 2.4.0, 2.5.0, 2.6.0)를 참고하세요.
logs RBAC 강제 적용은 계속 선택적
이 내용은 명확성을 위한 참고일 뿐이에요. 조치가 필요하지 않아요.
우리는 2.5에서 logs RBAC 강제 적용을 기본적으로 활성화할 것으로 예상했어요. Project Roles의 사용자에게 미치는 혼란 때문에 2.x 시리즈에서는 그렇게 하지 않기로 결정했어요.
API 버전 >=2.5.16에서 오래된 CLI 버전의 argocd app create 실패
Argo CD 2.5.16부터 API는 Application이 존재하지 않을 때 Application GET 요청에 NotFound 대신 PermissionDenied를 반환해요.
2.5.0-rc1로 시작하는 버전 이전과 2.5.16 및 2.6.7 이전 버전의 Argo CD CLI는 argocd app create에서 POST 요청 전에 GET 요청을 수행해요. 이 명령은 PermissionDenied 응답을 처리하지 못하므로 Application 생성/업데이트에 실패해요.
이 문제를 해결하려면 CLI를 최소 2.5.16 또는 2.6.7로 업그레이드하세요.
2.5.0-rc1보다 오래된 CLI는 영향을 받지 않아요.
2.5.20의 Golang 업그레이드
2.5.20에서 Argo CD를 빌드하는 Golang 버전을 1.18에서 1.19로 업그레이드해요. Argo CD를 라이브러리로 사용한다면 Go 버전을 업그레이드해야 할 수 있어요.
더 알아보기 (Learn more)
- 이 문서의 원문: v2.4 to 2.5
- Argo CD 공식 문서: https://argo-cd.readthedocs.io