argo workflows 설치 및 인증

UI를 가진 오픈 소스를 사용할 때마다 드는 생각이 아이디 발급하는 것 만큼 귀찮고 의미 없는 작업이란 생각에 해당 부분을 대부분 오픈소스들에 goolge Oauth를 적용하여 이용하는 중입니다. 

 

아이디 발급 하는 나의 모습.. ㄱ-

argocd 같은 경우 google Oauth를 이용해 이용하고 있고 argo workflows 역시 SSO 인증이 된다고 나와 있으나 이게 사알짝 BRAC와 얽혀 있어서 인증이 되고 이용하는데 있어서 설정해 줘야 할 부분들이 있기에 알아 보도록 하겠습니다.

• 설치는 helm을 이용하여 argocd 로 배포할 예정입니다.

참조 : https://argoproj.github.io/argo-workflows/argo-server-sso/

---

아래는 helm 차트에 나와있는 SSO 적용 방법입니다.

( 필자는 다써두고 중간에 글을 쓰다가 한번 날려먹어서 현타가 왔다고 합니다. 다들 컨트롤 +S를 생활화 합시다... )

 # -- SSO configuration when SSO is specified as a server auth mode.
  sso: {}
    ## All the values are required. SSO is activated by adding --auth-mode=sso
    ## to the server command line.
    #
    ## The root URL of the OIDC identity provider.
    # issuer: https://accounts.google.com
    ## Name of a secret and a key in it to retrieve the app OIDC client ID from.
    # clientId:
    #   name: argo-server-sso
    #   key: client-id
    ## Name of a secret and a key in it to retrieve the app OIDC client secret from.
    # clientSecret:
    #   name: argo-server-sso
    #   key: client-secret
    ## The OIDC redirect URL. Should be in the form <argo-root-url>/oauth2/callback.
    # redirectUrl: https://argo/oauth2/callback
    # rbac:
    #   enabled: true
    ## When present, restricts secrets the server can read to a given list.
    ## You can use it to restrict the server to only be able to access the
    ## service account token secrets that are associated with service accounts
    ## used for authorization.
    #   secretWhitelist: []
    ## Scopes requested from the SSO ID provider.  The 'groups' scope requests
    ## group membership information, which is usually used for authorization
    ## decisions.
    # scopes:
    # - groups

 

argo-server-sso Secret 생성

먼저, Google OAuth2 클라이언트 ID와 클라이언트 시크릿을 포함하는 Kubernetes Secret을 생성해야 합니다. 이를 위해 다음과 같은 YAML 을 만들고 저장해 줍니다.

apiVersion: v1
kind: Secret
metadata:
  name: argo-server-sso
type: Opaque
stringData:
  client-id-key: <your-google-client-id>
  client-secret-key: <your-google-client-secret>

인증 모드를 sso를 사용한다고 선언

  extraArgs:
    - --auth-mode=sso

sso 설정 선언

  sso:
    issuer: https://accounts.google.com
    clientId:
      name: argo-server-sso
      key: client-id-key
    clientSecret:
      name: argo-server-sso
      key: client-secret-key
    redirectUrl: https://사용하려는URL/oauth2/callback
    rbac:
      enabled: true
    scopes:
      - openid
      - profile
      - email
    secretWhitelist: ['admin','readonly']

위 설정에서 저는 secretWhitelist를 통해 시크릿 토큰을 통해 인증 절차를 밟는데 해당 부분에 대해서 그룹으로 관리를 진행하려고 admin 과 readonly로 나눠서 선언 했습니다.

여기서 저 그룹은 serviceaccounts에 등록하여서 clusterrole, clusterrolebindings 을 사용하여 관리 하는 것 이 편할 것 같아서 그렇게 진행을 했으며( role 과 rolebinding 은 쫌 더 새부적으로 관리할 때 사용하는 것이 좋습니다. ), 아래와 같이 helm 차트에서 관리하기 편하도록 코드로 관리 할 수 있게 추가시켜 줬습니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    workflows.argoproj.io/rbac-rule: "email in {{- .Values.serviceaccount.admin }}"
    workflows.argoproj.io/rbac-rule-precedence: "1"
  name: admin
---
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    workflows.argoproj.io/rbac-rule: "true"
    workflows.argoproj.io/rbac-rule-precedence: "0"
  name: readonly

위 처럼 헬름 템플릿을 추가 해두면 들어 오는 이메일로 serviceaccount를 조절할 수 있습니다.

helm 에서 시크릿 토큰을 생성 하는 것 을 넣어두면 바뀐 부분이 싱크가 되면서 꼬이지 않을까, 란 생각이 들어서 아래와 같이 그냥 수동으로 넣어 주었습니다.

apiVersion: v1
kind: Secret
metadata:
  name: admin-user.service-account-token
  annotations:
    kubernetes.io/service-account.name: admin-user
type: kubernetes.io/service-account-token

 

이후 argocd 로 배포 하고 인증이 완료된 모습을 확인

배포를 시켰고 해당 인그래스로 배포한 URL 접속 후 인증 결과를 보니 원하는 그룹에 잘 들어간 것을 확인 할 수 있고 어떤 서비스 어카운트를 사용하는지 어떤 네임스페이스 인지 나옵니다.

---

 

이 외에 아래는 공식 문서에서 나온 내용인데 내용이 꽤 흥미롭네요

Argo는 워크플로를 Kubernetes 리소스(즉, EtcD 내)로 저장합니다. 
리소스가 1MB 미만이어야 하므로 크기에 제한이 생깁니다. 
각 리소스에는 각 노드의 상태가 포함되며 /status/nodes리소스의 필드에 저장됩니다. 
1MB가 넘을 수 있습니다. 이런 일이 발생하면 노드 상태를 압축하여 /status/compressedNodes. 
상태가 여전히 너무 크면 SQL 데이터베이스에 저장을 시도합니다.

( ConfigMap이 1MB이상 저장 못하는 건 알고 있었는데 Etcd에 최대 저장 할 수 있는 용량이기 때문에 그러지 않았나? 란 생각 )
위 내용 대로 Etcd 이외에 SQL 설정도 있으며 persistence 을 통해 해당 설정을 진행 할 수 있는 것을 확인 했습니다. 규모가 커질 수록 etcd와 확실히 분리해서 운영하는 편이 안정 적이라고 생각이 들었고 비용이 어느정도 들더라도 해당 적용하는 것이 좋아 보인다고 생각이 들어 아래는 해당 내용을 적용할 수 있는 configmap 참조하여 적용 완료 했습니다.

https://argoproj.github.io/argo-workflows/workflow-controller-configmap.yaml

 

---

 

이것 저것 해줄게 정말 많았네요.. 특히 인증 쪽이 처음에는 어떻게 해줘야 할지 막막하기도 했는데,

argo workflows 서버는 워크플로에 대한 API 및 UI를 노출하는 서버이기 때문에 그런 것 같았습니다.

 

이제야 정말 준비가 끝났나 ?!