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 사용.
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 때문.