KubeCon2022 - Multi Tenancy for Argo Workflows and Argo CD at Adobe

https://youtu.be/aTgINAFV3T8?si=CiQvPy7-HwsGOYPt

 

 

 

발표자: Srinivas Malladi. Adobe Internal Developer Platform 개발.

 

 

Internal Developer Platform (IDP) at Adobe

 

Adobe는 크게 세 가지 Product Category가 있다. Document Cloud, Creative Cloud, Experience Cloud

• 각 클라우드 서비스에서 필요한 애플리케이션은 different internal platform에서 Run / Deploy.
• 공통으로 필요한 Core Mechanisms / infrastructure toolings을 제공하는 게 Internal Developer Platforms. (IDP)
  • 예컨대 AWS, Azure, Adobe DataCenter에서 제공하는 resource의 Access Control 지원
  • Standardize Best Practices, CI / CD 제공.

 

몇 가지 Term 정의하고 넘어가자면

• GitOps: Desired System State을 Git에서 정의 / tracking하고, Running System은 Actual State를 Git에 정의된 것과 Sync.

 

Argo CD가 대표적인 gitOps tool이다.

• k8s Manifests를 Git으로 정의하고, k8s Cluster의 특정 namespace에 manifest를 배포하는 것.
• k8s Controller with Various CRDs.
  • 어떤 state를 tracking할 것인지
  • 어디에 배포할 것인지 설정한다.

 

Argo Workflow: Workflow Engine.

• pod 단위로 실행되는 Task를 정의하고, task 간 실행순서를 dependency로 정의.
• Template으로 만들어서 DAG 형태로 사용할 수 있다.

Architecture

 

Argo CD와 Argo Workflow가 동작할 Hub Cluster 설정.

• Client workflows가 실행될 namespace 세팅

Client의 작업이 실제로 실행될 Remote Cluster 설정.

• 실행할 workload는 별도의 Image Registry에서 pull 받아온다.

---

순서대로 설명하자면

• Client의 git Repo에는 IDP의 Workflow Template를 참조해서 만들어진 k8s Manifests가 있다.
  • Argo CD가 git Repo를 tracking -> client의 Remote Cluster에 workload를 배포하는 Workflow를 관리한다.
• git Repo에 변경사항이 생기면, Client Hub Namespace에 있는 Workflows를 Trigger한다.
  • Argo Workflow가 이벤트 받아서 실행한다.
  • 사실 변경사항 받아서 image build / push하는 게 대부분임.
• workflow 변경사항이 끝나면, git Repo에 새로운 image tag와 같은 정보를 update.
• git repo에 상태가 업데이트되면, Argo CD가 탐지해서 remote Cluster에 새로운 manifest를 배포한다.

Multi-Tenancy

 

여러 클라이언트가 Share Single Resource. 위 예시의 경우 Argo CD / Argo Workflows.

• reduce Idle time
• Save times (spin up faster)
• Consolidates best practices
• Efficient, Scales Well.

 

Multi Tenancy 구조에서 해결해야 할 이슈

• Access: Client는 Argo CD / Argo Workflow에서 자신에게 권한이 있는 리소스에만 접근한다.
• Isolation: workflows와 Deployment process의 분리.
• Distributed Support: Client에게만 권한이 있는 resource의 update / fix가 필요한 경우 어떻게 대응할 것인지.
• Scaling: heavy load에도 Reliability를 유지하는 방법

Access

Argo Server UI on Argo Workflows

 

Hub Cluster에 설치된 Argo Server에서 제공하는 UI.

• client Namespace에서 돌아가는 workflow의 정보를 보여준다.

 

Argo Server UI에서 특정 workflow 정보를 보고, 필요한 작업을 수행할 수 있다.

• suspending, retrying, deleting workflows.

기능은 훌륭한데, Client가 접근권한이 있는 workflow resource일 때만 이 화면과 이 기능이 활성화되어야 한다. How?

 

Client가 해당 리소스에 권한이 있는지 없는지 확인하려면 두 가지 정보가 필요하다.

• client Group Membership (by identity Provider)
• Service Account가 해당 namespace resource 권한이 있는지.

따라서, Client는 먼저 SSO를 사용해서 Group Information 정보를 받아온다.

• 위 예시의 경우 Azure Active Directory 서비스를 SSO로 사용했다.

인증된 사용자라면, Group Information 정보와 Service Account가 매칭되는 것이 있는지 확인한다.

• Service Account가 있고 RBAC 권한도 잘되어 있다면, Display Workflows.

장점

• client의 Access를 Namespace Level로 Workflow Resource와 연결할 수 있고
• service Account를 사용하므로 highly Scalable. (RBAC)
  • hub Cluster에서, clients와 namespace의 M:N relation이 가능해진다.

 

namespace RBAC feature in Argo Workflows

• ServiceAccount의 annotation에 authorized Groups 정보가 포함되어 있는지를 확인한다.
• 위 예시의 경우, Group A의 client만 이 Service Account에 접근할 수 있다는 뜻.
  • 리스트 형식이므로, group을 추가할 수 있다.
• precedence: client에서 SA의 multpile match가 이루어졌을 때 우선순위 설정을 위한 필드.

Argo Cli on Argo Workflows

 

Argo cli의 경우, scoping access 절차가 다르다.

• Identity Provider 대신 k8s API server를 사용함.
  • cli로 요청을 보낼 땐, kubeConfig file의 인증정보를 기반으로 한 bearer token을 사용함.
  • k8s api에서 token 토대로 authenticate / authorize 수행.
• workflow 리소스 핸들링할 권한이 있을 경우 display workflows.

 

Argo CD

 

Argo CD에서도 권한 있는 사용자만 리소스에 접근할 수 있어야 한다. 필요한 기능을 수행하거나, 시각화할 때.

 

argo CD는 UI와 cli의 절차가 동일하다. 똑같이 Argo CD Server가 Access 로직을 처리함.

• appProject라는 리소스가 중요한데, scope / group Argo CD resources를 담당하기 때문.
  • argo CD에서 관리하는 Log, repositories, clusters, projects, certificates..
  • appProject 단위로 관리가 안 되는 것들은 Global Scope의 Configmap.
    • SPOF 발생할 수 있으므로 global scope 관리는 되도록이면 하지 않는다.

 

• Client가 리소스 접근 요청을 보내면, Identity Provider로 해당 클라이언트가 접근할 수 있는 Group 정보를 리턴한다.
• Argo Server에서 if any of the clients groups are authorized by the parent projects of the requested resources 체크.
  • appProject 체크한다는 소리 같음.
• 권한이 있는 appProject 찾으면, 리소스 접근 기능 제공.

 

ArgoCD에서는 기본적으로 3 role을 제공함. admin role, read-only role, automation role.

Isolation

Argo Workflows

 

client는 권한이 있는 리소스에만 접근할 수 있도록 해 뒀다.

• workflow로 만들어진 Pod도, 권한 없는 다른 리소스에 접근해서는 안 된다. How?

No Secret Shared

• All clients bring their own secrets to the namespace.
• git token이라던가, argoCD Automation token 등 pull from vault

Scoped Artifact Repos: leverage the lack of shared secrets.

• 공유하는 secret정보가 없다면, client의 artifact repo도 자동으로 Scoped된다.
• 개별 workflows steps에서 사용할 artifacts에도 isolation

Executor

• argo workflows의 default Executor인 Emissary Executor와 k8s API Executor 사용.
  • https://argo-workflows.readthedocs.io/en/latest/workflow-executors/

Network Policy

• k8s api Executor는 Network Policy가 필요하고,
• 그게 아니더라도 기본적으로 ingress / egress 권한관리를 위해 Network Policy 사용

ServiceAccount

• Workflow를 Trigger할 때 ServiceAccount를 명시해야 함.
  • workflow 전체에 동일한 SA를 적용할 수도 있고, 특정 task에만 특정 SA를 적용할 수도 있다.
  • 특정 workflow의 어떤 작업에는 어떤 권한을 부여할 건지 선택할 수 있게 함.

Hub Cluster Pod Security Policy

• cluster Level의 security Options: limit Pod Capability.
• prevent Privileged Pods in client Namespace.

Optional off-cluster Build: privilege 권한이 필요한 경우 (i.e. Docker in Docker)

• isolation은 유지한 채 Privilege를 제공하는 방법이라고 함. (자세히 설명하지는 않아서 뭔소린지 모르겠다)

cf. 이미지 빌드에는 Kaniko를 쓰고 있다.

• client image 빌드할 때 별도의 privileges를 요구하지 않고
• Multi stage build를 지원하기 때문

Argo CD

 

Argo CD의 경우, Argo CD application Level에서부터 Isolation이 시작된다. 권한관리는 AppProject에서 수행한다.

• application 자체가 'remote cluster의 특정 Namespace에 workload를 배포한다'는 동작이기 때문
• appProject는 아래 두 가지 외부 리소스의 tracking 권한을 관리한다.
  • k8s manifest 추적을 위한 git repo 권한 -> owned by client.
  • git repo가 참조하는 artifact (helm repo 같은 거)
• appProject는 대상이 될 외부 클러스터에 배포 권한을 관리한다.

위 조건이 만족되지 않으면, Argo CD 앱 생성할 때 에러를 리턴해버린다.

• 추가로, argoCD 앱이 cluster level resource (Namespace 같은 것) 접근할 수 없도록 Restrict해야 한다.

 

Argo CD Component 중 isolation 관점에서 봐야 하는 것 중 하나가 ArgoCD Operator itself, running on hub cluster.

• 여러 개의 remote cluster에 리소스를 배포해야 하므로 권한을 가지고 있음. (hub and spoke Model) 따라서 얘도 적절한 권한관리를 해줘야 한다.

 

클러스터를 argoCD에 등록할 때 kube-system Namespace에 cluster Admin 권한으로 SA를 만들어서 사용하는 경우가 있는데, 두 가지 이유로 보안상 좋지 않다.

• privileged pod가 만들어질 수 있음.
• argo CD Deployment와 관계없는 namespace까지도 접근 가능함

 

• kube-system 대신 다른 ns를 사용할 것
• cluster admin이 아니라 read cluster access role을 사용할 것
  • 특정 ns에 앱을 배포하려면, individual ns에 한해서 admin access를 부여한다.
  • 즉, read cluster admin Role + individual ns에 write access
• 가급적이면 secret access 권한도 빼버린다. vault로 k8s secret integration 넣는 게 낫다.
  • cluster bulk read for sync에서 과부하 오지 않도록, argoCD 쪽에서도 secret 관련 권한을 다 빼버리거나 ignore 처리한다.

Distributed Support

 

client Repository나 외부 resource (helm repo)는 IDP가 권한이 있는 게 아님. how?

• 할 수 있는 건 centralize한다.
  • application Code: template 제공
  • CI / CD: own repository 만들어서 제공. resource type은 helm으로 통일한다. 다 우리가 내재화해서 관리하면 됨
• semantic versioning 사용.
  • minor / patch update는 Backward Compatiblity를 지원하므로, 자동으로 client repository에 업데이트해준다.
  • major update의 경우 manual update

Scaling

Argo Workflows

 

HA: 문서에 쓰여 있는 것 (https://argo-workflows.readthedocs.io/en/latest/high-availability/)

• hot-standby.
• pod disruptions budgets / min replica counts for argo server 등의 옵션 설정.

Rate limiting

• 자주 쓰는 이미지는 mirror. 여러 workflow에서 동시에 Dockerhub Pull 요청할 경우 Ratelimit 걸릴 수 있다.

Resource Consumption

• workflow executor's default resource allocation (cpu / memory)
• 이 값에 따라 client가 사용할 수 있는 artifact의 size 결정하기 때문.
• default main container (running task)의 default resource는 좀 더 준다.
• Namespace Quota로 관리하는 것도 좋은 선택. 특정 클라이언트 하나가 클러스터 전체 리소스를 점유하면 안 되니까.

Metrics (Prometheus)

• Workflow Controller의 state metric
• workflow / template level로 custom metric 지원.
• grafana dashboards.

Argo CD

 

HA: 문서에 잘 나와있음.

Rate limiting: Github App으로 전환.

• Github App의 ratelimit이 일반 user나 PAT보다 높음.
• reduce client friction. 사용자가 github app 설치하기만 하면 됨.

Resource Consumption

• Limit repo-server memory usage. huge artifact를 argo CD repo server가 땡겨온다거나... 하는 문제 방지
• sharding Argo CD operators across different hub clusters.

Metrics (Prometheus)

 

Q&A

Q. Where do users get the token to access argo workflows in argo CLI

• IDP에서 제공하는 KubeConfig 기반. <- 이 경우가 훨씬 많다
• Bearer Token (SA 기반)이 있으면 그걸 사용

Q. argo CD는 not create ns. ns 생성은 누가 하고, 관리는 어떻게 이루어지나?

• ns creation 담당하는 provisioner tool이 있음.

Q. ArgoCD Operator를 hub and spoke방식으로 사용하도록 결정한 근거가 궁금하다. other alternatives?

• 제일 많이 고려한 건 consolidate maintenance / best practices 제공 / simplify things for client, While providing a secure experience.
• 여기는 질문도 답변도 뭔가 나사가 빠져있어서, offline으로 이야기하자고 하고 끝냈음

Q. argo workflows 돌리다 보면 namespace quota 이슈 생기지 않나? how did you do?

• that's why we had to modify the resource allocations out of the box for the workflow executor.
  • main container와 executor의 resource변경이 미치는 영향력을 뭐라뭐라 설명했는데 뭔소린지 모르겠다.
• 그럼에도 불구하고 필요하다면 ns quota 증설 요청을 받아서 대응하고 있다.

Q. Argo SaaS 안 쓴 이유?

• granular control과 flexibility 때문.