Tekton 사용해보기 (3) Tekton Dashboard에 OIDC를 기반으로 RBAC 적용하기

본 포스팅은 "Tekton 사용해보기" 시리즈의 세 번째 글입니다.

 

해당 시리즈의 첫 번째 글은 Tekton 사용해보기 (1) Tekton으로 쿠버네티스 CI/CD 파이프라인을 구성해보자 에서 볼 수 있습니다. 

해당 시리즈의 두 번째 글은 Tekton 사용해보기 (2) Tekton으로 인프라를 자동 배포하는 Terraform Pipeline을 만들어보자 에서 볼 수 있습니다.

 

이번 포스팅에서는 Tekton의 컴포넌트 중 하나인 Tekton Dashboard를 OIDC와 함께 연동해서 Kubernetes RBAC을 적용해보겠습니다.

 

현재 Tekton Dashboard에서 native하게 지원하지 않는 기능 중 한가지는 사용자에 따른 RBAC인데요. 따라서 Dashboard에 접속하는 사용자에 따라 접근할 수 있는 리소스를 제한하는 등의 구성을 할 수 없다는 제한점이 있었습니다.

 

 

하지만 Tekton은 이러한 제한점을 극복하기 위해 Proxy에서 들어오는 Authentication header를 그대로 kube-api에 path하는 기능을 지원하도록 했는데요. 그럼으로써 Tekton Dashboard는 kubernetes의 impersonation 기능을 이용해서 RBAC기능을 간접적으로 구현할 수 있게 되었습니다.

 

 

위의 Impersonation 기능은 다양한 Reverse Proxy 솔루션으로 구현할 수 있습니다. 

 

본 페이지에서는 솔루션으로 오픈소스 Authentication Proxy인 Openunison을 사용했습니다. 

https://openunison.github.io/

Kubernetes Authentication and SSO - OpenUnison

 

 

정리하자면 이번 포스팅은 Tekton Dashboard가 간접적으로 지원하는 RBAC 기능과 OIDC를 지원하는 Reverse Proxy를 연동하게 만드는 것이 목표라고 할 수 있습니다.

 

01. OIDC란?

 

 

본 포스팅을 본격적으로 시작하기 전에 중요한 개념인 OIDC에 대해서 먼저 알아보겠습니다.

 

OIDC(OpenID Connect)란 기존의 인증(Authorization) 체계이던 Oauth2.0의 상위 레이어에서 인가(Authentication)를 처리하는 프로토콜입니다.

 

여기서 인증(Authorization)이란 "내가 무엇을 할 수 있는 사람인지"를 검증하는 권한 확인 절차이고, 인가(Authentication)란 "내가 허가된 사람인지"를 검증하는 신원 확인 절차 입니다. 예를 들어 대표적인 인증 절차에는 RBAC이 있으며, 인가 절차에는 로그인이 있습니다.

 

 

즉 OIDC는 API 호출을 위해 신원 및 권한 확인 절차까지 요구하는 Oauth 2.0에서 신원 확인만을 담당하는 인가 프로토콜이라고 할 수 있습니다.

 

 

OIDC 프로토콜의 동작 Flow chart는 위와 같습니다. 

 

본 포스팅에서 사용되는 OIDC 연동은 Tekton Dashboard 앞단의 Proxy Dashboard에 접근하려는 클라이언트를 IDP의 인증 페이지로 리다이렉트해서 인증 절차를 밟게 한 후, id_token을 받아 토큰 정보를 기반으로 계정 정보를 받기 위해 사용됩니다.

 

 

02. Tekton Dashboard OIDC 연동 개요

 

 

이번에 소개할 OIDC를 이용해 Tekton Dashboard에 RBAC을 적용하는 아키텍쳐 다이어그램은 위와 같습니다.

 

위 다이어그램의 플로우를 순서대로 설명하면 아래와 같습니다.

 

1. Client가 Tekton Dashboard의 Authentication Proxy 역할을 하는 Openunison 페이지로 접근합니다.

 

2. Openunison은 Google Oauth 인증 페이지로 Client를 Rediret합니다. 사용자의 인증이 완료되면 Google은 id_token을 openunison에게 전달합니다.

 

3. Openunison은 전달받은 id_token을 기반으로 kube-api를 impersonation 기능으로 호출하는데 필요한 impersonate_user 등의 헤더를 생성한 뒤 nginx proxy로 요청을 전달합니다.

 

4. nginx proxy는 SSL termination을 수행한 뒤 받은 요청을 Tekton Dashboard로 전달합니다. 

 

5. Tekton Dashboard는 Impersonate-user를 포함한 헤더를 kube-api에 전송합니다.

 

6. Impersonate 관련 헤더를 포함한 api 호출 요청을 받은 kube-api는 헤더의 User 값을 기반으로 요청을 수행합니다.

 

7. 해당 User에 부여된 Role에 따라 접근 제어가 이루어져 역할 기반 접근 제어(RBAC)를 구현할 수 있습니다. 

 

 

위 아키텍쳐의 실제 구현 결과는 아래와 같습니다.

 

1. Tekton Dashboard에 접근하기 위해 "Openunison" authentication proxy 페이지로 진입하면 Google Oauth 페이지로 리다이렉션됩니다.

 

 

2. 인증에 성공하면 Openunison의 Access Portal 페이지로 리다이렉션됩니다. Access Portal 페이지 상단의 User 값을 통해 Oauth인증에 사용된 계정 정보를 가져왔음을 확인할 수 있습니다.

 

 

3. Access Portal의 Tekton Dashboard 뱃지를 클릭하면 Tekton Dashboard 페이지로 진입할 수 있습니다.

 

 

4. 미리 Rolebinding을 통해서 Oauth 인증한 계정에 권한을 부여한 "dev" namespace의 Tekton 리소스는 접근 권한이 존재하는 상태임을 확인할 수 있습니다.

 

 

5. 하지만 권한을 부여하지 않은 "default" namespace의 리소스에 대해서는 접근이 되지 않고 있습니다. 이것으로 Tetkon Dashboard에서 OIDC 기반의 RBAC이 잘 동작하는 것을 확인할 수 있습니다.

 

 

 

03. 아키텍쳐 구성

이제 본격적으로 아키텍쳐를 구성하는 방법에 대해서 알아보겠습니다. 

 

Kubernetes 환경은 GCP의 GKE를 사용했으며, IDP로는 Google을 사용합니다. 

 

그 외에 Kubernetes 패키지 매니저인 helm이 설치되어 있어야 합니다.

 

 

3-1. Tekton 컴포넌트 설치

먼저 Tekton Pipeline 및 Dashbaord를 설치해 Tekton 컴포넌트를 준비하겠습니다.

 

Tekton 컴포넌트 설치에 대한 내용은 Tekton 사용해보기 (1) Tekton으로 쿠버네티스 CI/CD 파이프라인을 구성해보자 포스팅에 설명이 있으니 이로 대체하겠습니다.

 

 

3-2. Google Oauth 2.0 설정

다음으로는 Google IDP에서 OIDC 프로토콜을 사용하기 위한 Google Oauth 2.0 설정을 구성하겠습니다.

 

Oauth 2.0 설정은 Openunison과 같은 어플리케이션이 IDP에게 인증 절차를 수행하게 한 뒤 id_token을 받아오기 위해서 필요합니다.

 

받아온 id_token은 사용자 계정 정보를 담고 있어 Kubernetes Impersonation에 사용됩니다.

 

 

3-2-1. Google Cloud Platform Console로 진입한 뒤, Project를 선택 후 APIs & Services 탭의 Oauth consent screen 페이지로 진입합니다. 

 

3-2-2. App name 등 필요한 정보를 적고 다음 페이지로 진입합니다.

 

 

3-2-3. Scope 설정 페이지에서 아래와 같이 openid, email, profile을 추가하고 설정을 마칩니다.

 

 

3-2-4. 이후 Credential 페이지로 진입한 뒤 CREAT CREDENTIAL → OAuth Client ID를 클릭해 Oauth client ID 생성 페이지로 진입합니다.

 

 

3-2-5. Application Type에 Web Application을 선택한 후, Authorized JavaScript origins에 Openunison의 Host 주소가 될 URL을, Authorized redirect URIs에 Openunison의 Host주소가 될 URL/auth/oidc를 입력합니다. 

 

 

3-2-6. 해당 페이지의 DOWNLOAD JSON 버튼을 클릭해 Client ID와 Client secret 정보를 저장합니다.

 

 

 

3-3. Openunison 설치 및 구성

 

 

이제 Tekton Dashboard의 앞단에서 Authentication을 처리해주는 Proxy인 Openunison을 설치하겠습니다.

Openunison은 Kubernetes 환경에 구성되어 Tekton Dashboard 및 kubectl 접근의 인가 기능을 제공하고 있습니다.

 

3-3-1. Openunison은 Operator, Portal 등의 컴포넌트를 설치해주는 CLI도구인 ouctl을 제공하고 있습니다. Openunison 설치 페이지를 참고해서 ouctl을 설치합니다.

 

 

ouctl 바이너리를 OS에 맞게 다운받은 뒤, 해당 파일을 ouctl로 이름으르 변경하고 chmod 777 명령어로 권한을 변경합니다.

ouctl을 실행했을 시 아래와 같이 출력되면 정상적으로 설치된 것입니다. 

 

$ ./ouctl             
openunison-ctl automates the deployment of OpenUnison into your cluster.  This tool will create the appropriate Secrets and deploy the correct helm charts for you
 
 
Usage:
  openunison-control [command]
 
 
Available Commands:
  completion          Generate the autocompletion script for the specified shell
  help                Help about any command
  install-auth-portal Deploys the authentication portal for Kubernetes, requires one argument: The path to the values.yaml
  install-satelite    Installs a satelite OpenUnison that relies on a control-plane openunison for authentication
 
 
Flags:
  -h, --help               help for openunison-control
  -n, --namespace string   namespace to deploy openunison into (default "openunison")
  -t, --toggle             Help message for toggle
 
 
Use "openunison-control [command] --help" for more information about a command.

 

3-3-2. ouctl 명령어를 통해서 Openunison을 설치하기 위해서는 client_secret 파일과 value.yaml이 필요합니다. 먼저 Google Oauth2.0 설정에서 생성한 Client ID의 Client_Secret이 포함된 파일을 생성합니다.

 

$ echo GOCSPX-... >client_secret.txt

 

3-3-3. 다음으로 value.yaml 파일을 생성하겠습니다. default value.yaml 파일은 여기서 확인할 수 있습니다. yaml 파일을 아래와 같이 수정 후 저장합니다.

 

network:
 openunison_host: "open.test-for-lswoo.kro.kr" # openunison의 host로 사용할 값으로 바꿔주세요.
 dashboard_host: "tekton-dashboard.test-for-lswoo.kro.kr" # Tekton-dashboard의 host로 사용할 값으로 바꿔주세요.
 api_server_host: "api.test-for-lswoo.kro.kr" # api server의 host로 사용할 값으로 바꿔주세요.
  session_inactivity_timeout_seconds: 900
  k8s_url: https://192.168.2.130:6443
  force_redirect_to_tls: false
  createIngressCertificate: true
  ingress_type: nginx
  ingress_annotations: {}
 
 
cert_template:
  ou: "Kubernetes"
  o: "MyOrg"
  l: "My Cluster"
  st: "State of Cluster"
  c: "MyCountry"
 
 
image: docker.io/tremolosecurity/openunison-k8s
myvd_config_path: "WEB-INF/myvd.conf"
k8s_cluster_name: openunison-cp
enable_impersonation: true # 해당 값을 true로 설정해야 impersonation 기능이 활성화됨
 
impersonation:
  use_jetstack: false
  jetstack_oidc_proxy_image: docker.io/tremolosecurity/kube-oidc-proxy:latest
  explicit_certificate_trust: true
 
dashboard:
  namespace: "tekton-pipelines"
 cert_name: "self-signed-cert" # 이미 생성된 Cert 값을 넣는 것이 아닌 Openunison이 생성할 Cert의 이름 값을 넣는 항목
  label: "app=nginx-ssl-proxy"
 service_name: nginx-ssl-proxy # nginx-ssl-proxy의 Serivce를 지정
  require_session: false
 
certs:
  use_k8s_cm: false
 
trusted_certs: []
 
monitoring:
  prometheus_service_account: system:serviceaccount:monitoring:prometheus-k8s
 
# Uncomment one of the below options for authentication
 
#active_directory:
#  base: cn=users,dc=ent2k12,dc=domain,dc=com
#  host: "192.168.2.75"
#  port: "636"
#  bind_dn: "cn=Administrator,cn=users,dc=ent2k12,dc=domain,dc=com"
#  con_type: ldaps
#  srv_dns: "false"
 
oidc:
 client_id: 773410544731-m5hct7aahkjugd43qfm0r6q9lfqdahqt.apps.googleusercontent.com # 발급받은 Client_id 값으로 바꿔주세요.
  issuer: https://accounts.google.com #google id token의 attribute 참고
  user_in_idtoken: false
  domain: ""
  scopes: openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile #google consent screen의 scope 참고
  claims:
    sub: email #google id token의 attribute 참고
    email: email
    given_name: given_name
    #family_name:
    display_name: name
    groups: groups
 
#github:
#  client_id: d85d77c55a08c9bcbb15
#  teams: TremoloSecurity/
 
#saml:
#  idp_url: "https://portal.apps.tremolo.io/idp-test/metadata/dfbe4040-cd32-470e-a9b6-809c8f857c40"
 
 
 
 
network_policies:
  enabled: false
  ingress:
    enabled: true
    labels:
      app.kubernetes.io/name: ingress-nginx
  monitoring:
    enabled: true
    labels:
      app.kubernetes.io/name: monitoring
  apiserver:
    enabled: false
    labels:
      app.kubernetes.io/name: kube-system
 
services:
  enable_tokenrequest: false
  token_request_audience: api
  token_request_expiration_seconds: 600
  node_selectors: []
 
openunison:
  replicas: 1
  non_secret_data:
    K8S_DB_SSO: oidc
    PROMETHEUS_SERVICE_ACCOUNT: system:serviceaccount:monitoring:prometheus-k8s
    SHOW_PORTAL_ORGS: "fadslse" # 해당 부분은 현재 "false"로 적으면 boolean 처리되서 오류가 발생하는 버그가 있으니 의도적으로 에러를 낼 것. 설치 후 수정 가능.
  secrets: []
  html:
    image: docker.io/tremolosecurity/openunison-k8s-html
  enable_provisioning: false
  use_standard_jit_workflow: true
  #az_groups:
  #- CN=k8s-users,CN=Users,DC=ent2k12,DC=domain,DC=com
 
#myvd_configmap: myvdconfig
 
# For Namespace as a Service
 
#database:
#  hibernate_dialect: org.hibernate.dialect.MySQL5InnoDBDialect
#  quartz_dialect: org.quartz.impl.jdbcjobstore.StdJDBCDelegate
#  driver: com.mysql.jdbc.Driver
#  url: jdbc:mysql://mariadb.mariadb.svc.cluster.local:3306/unison
#  user: unison
#  validation: SELECT 1
 
#smtp:
#  host: blackhole.blackhole.svc.cluster.local
#  port: 1025
#  user: "none"
#  from: donotreply@domain.com
#  tls: false

 

3-3-4. 아래 명령어로 helm 레포지토리를 추가한 뒤, Secret 파일과 value.yaml 파일을 이용해 Openunison 설치를 진행합니다.

 

$ helm repo add tremolo https://nexus.tremolo.io/repository/helm/
$ helm repo update
$ ouctl install-auth-portal -s /path/to/secret/file /path/to/yaml

 

3-3-5. Openunison Host URL로 접속 시 Oauth 인증 페이지로 리다이렉션되고, 인증이 완료된 후 아래 페이지로 진입하면 설치가 정상적으로 완료된 것입니다.

 

 

 

3-4. Nginx Proxy 설치 및 구성

본래 Openunison은 내부 서비스의 443 Port로만 접근할 수 있기 때문에 9097 Port만 허용하는 Tekton Dashboard에 직접 접근할 수 없습니다.

 

이런 문제를 해결하기 위해 Openunison과 Tekton Dashboard 사이에 SSL termination을 담당하는 Nginx pod를 두어서 Proxy 역할을 담당하게 합니다.

 

Nginx는 /etc/nginx 디렉토리에 존재하는 nginx.conf 파일을 통해 설정을 구성합니다. 이 파일을 Configmap으로 구성해 Mount하는 방식으로 설정을 변경하겠습니다.

 

3-4-1. 아래 nginx.config 파일을 기반으로 Configmap을 생성합니다.

 

user  nginx;
worker_processes  auto;
 
error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;
 
 
events {
    worker_connections  1024;
}
 
stream {
    upstream stream_backend {
         server tekton-dashboard.tekton-pipelines.svc.cluster.local:9097; # Tekton Dashboard의 DNS 주소
    }
 
    server {
        listen                443 ssl;
        proxy_pass            stream_backend;
 
 
        ssl_certificate       /cert/dashboard.crt;
        ssl_certificate_key   /cert/dashboard.key;
        ssl_protocols         SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers           HIGH:!aNULL:!MD5;
        ssl_session_cache     shared:SSL:20m;
        ssl_session_timeout   4h;
        ssl_handshake_timeout 30s;
        #...
     }
}

 

3-4-2. 위에서 만든 Configmap과 value.yaml의 dashboard.cert_name 값으로 만들어진 Secret을 Mount한 Nginx Deployment를 생성합니다.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  labels:
    app: nginx-ssl-proxy
  name: nginx-ssl-proxy
  namespace: tekton-pipelines
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx-ssl-proxy
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-ssl-proxy
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /etc/nginx/
          name: config
        - mountPath: /cert/
          name: cert
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - name: cert
        secret:
          defaultMode: 420
          secretName: self-signed-cert
      - configMap:
          defaultMode: 420
          name: nginx-config
        name: config

 

3-4-3. nginx-ssl-proxy pod에 도달할 수 있도록 Service를 생성해 줍니다.

 

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"ingress":true}'
  labels:
    app: nginx-ssl-proxy
  name: nginx-ssl-proxy
  namespace: tekton-pipelines
spec:
  clusterIP: 10.112.8.200
  clusterIPs:
  - 10.112.8.200
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: 443-443
    port: 443
    protocol: TCP
    targetPort: 443
  selector:
    app: nginx-ssl-proxy
  sessionAffinity: None
  type: ClusterIP

 

3-4-4. 생성된 nginx-ssl-proxy Pod에서 Tekton Dashboard 서비스의 9097 포트로 접속을 시도할시 아래와 같이 연결이 잘 된다면 구성이 완료된 것입니다.

 

 

3-4-5. 마지막으로 Openunison의 Kubernetes Dashboard 페이지를 클릭했을시 아래와 같이 Tekton Dashboard 페이지로 접근하면 정상적으로 구성된 것입니다.

 

 

 

3-5. RBAC 구성

기본적으로 Tekton Dashboard는 Service account에 부여된 Role을 통해 Kubernetes API를 수행합니다.

 

하지만 지금까지와 같이 Impersonation 기능을 활용하게 되면 Service account가 아닌 Oauth2.0으로 인증받은 개인정보로 API를 수행하게 됩니다.

 

이 구성을 사용한다면 Least privilege 원칙을 지키기 위해 우선 기존 Tekton Dashboard의 Service account에 존재하는 Role을 전부 제거해야 합니다. 

 

3-5-1. 아래 명령어로 Tekton Dashboard Service account의 기존 Role을 제거합니다.

 

$ kubectl delete clusterrolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard
$ kubectl delete rolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard -n tekton-pipelines

 

3-5-2. 아래와 같이 Tekton Dashboard에서 리소스가 보이지 않는다면 Role이 성공적으로 제거된 것입니다.

 

 

3-5-3. 개발자 도구에서 확인해볼 경우 "lswoo@~.com"과 같이 Oauth2.0인증한 계정으로 kube-api에 API 호출을 하고 있다는 것을 확인할 수 있습니다.

 

 

3-5-4. RBAC을 활용해 지정한 계정이 특정 Namespace에 존재하는 Tetkton 리소스만 접근할 수 있도록 구성해보겠습니다. 먼저 Tekton Dashboard의 Service account에 Impersonation을 할 수 있는 권한을 부여합니다.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
  name: impersonator
rules:
- apiGroups:
  - ""
  resources:
  - users
  - groups
  - serviceaccounts
  verbs:
  - impersonate
- apiGroups:
  - authorization.k8s.io
  resources:
  - selfsubjectaccessreviews
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: impersonator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: impersonator
subjects:
- kind: ServiceAccount
  name: tekton-dashboard
  namespace: tekton-pipelines

 

3-5-5. Tekton 리소스에 접근할 수 있는 Role 및 Rolebinding 오브젝트를 접근제어를 원하는 네임스페이스에 생성 후 적용합니다.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  annotations:
  labels:
    app.kubernetes.io/component: dashboard
    app.kubernetes.io/instance: default
    app.kubernetes.io/part-of: tekton-dashboard
  name: tekton-dashboard-tenant-dev
  namespace: dev
rules:
- apiGroups:
  - tekton.dev
  resources:
  - tasks
  - taskruns
  - pipelines
  - pipelineruns
  - pipelineresources
  - runs
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - triggers.tekton.dev
  resources:
  - eventlisteners
  - triggerbindings
  - triggers
  - triggertemplates
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - tekton.dev
  resources:
  - tasks
  - taskruns
  - pipelines
  - pipelineruns
  - pipelineresources
  - runs
  verbs:
  - create
  - update
  - delete
  - patch
- apiGroups:
  - triggers.tekton.dev
  resources:
  - eventlisteners
  - triggerbindings
  - triggers
  - triggertemplates
  verbs:
  - create
  - update
  - delete
  - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tekton-dashboard-tenant-lswoo
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tekton-dashboard-tenant-dev
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: lswoo@~~.com #User account

 

3-5-6. 확인을 위해 Role을 적용한 계정으로 Oauth2.0 인증을 한 뒤, 원하는 네임스페이스의 Tekton 리소스만 접근 가능한지 확인합니다.

 

 

 

3-6. Tekton Dashboard 뱃지 구성

Openunison Access portal은 기본적으로 Kubernetes Dashboard Badge만을 제공하지만, CRD를 통해 필요에 따라 Badge를 추가할 수 있는 기능을 제공하고 있습니다.

 

이 기능을 통해 Access portal에 원하는 Dashboard의 Icon과 이름 및 Access control 정책을 사용할 수 있습니다.

 

3-6-1. Tekton Dashboard를 위한 yaml 매니페스트를 생성 후 적용합니다.

 

apiVersion: openunison.tremolo.io/v1
kind: PortalUrl
metadata:
  annotations:
  labels:
  name: tekton-dashboard
  namespace: openunison
spec:
  azRules: # Access control을 위한 정책
  - constraint: o=Tremolo
    scope: dn
  icon: iVBORw0KGgoAAAANSUhEUgAAANIAAADwCAYAAAB1/Tp/AAAAAXNSR0IArs4c6QAAA.. # 가로 210 세로 240의 base64 encoding된 PNG 아이콘
  label: Tekton Dashboard # Portal에 표시될 이름
  org: b1bf4c92-7220-4ad2-91af-ee0fe0af7312 # 조직 uuid
  url: https://#[K8S_DASHBOARD_HOST] # Dashboard URL

 

3-6-2. Pod를 다시 시작할 필요 없이 사이트를 새로고침 하면 아래와 같이 Tekton Dashboard Badge가 추가된 것을 확인할 수 있습니다.

 

 

3-6-3. Kubernetes Dashboard Badge를 제거하려면 portalurl 오브젝트의 "k8sdb" 리소스를 삭제하면 됩니다.

 

 

3-6-4. Kubernetes Dashboard Badge 제거 후 최종 Access Portal 페이지 화면입니다.

 

 

 

04. 마무리

 

지금까지 Tekton Dashboard가 제공하지 않던 RBAC 기능을 Kubernetes의 Impersonate 기능과 OIDC 프로토콜을 사용해서 탑재해봤습니다.

 

이 기능을 이용한다면 사용자마다 네임스페이스별, 혹은 리소스별 Tekton 접근 제어가 가능해 세분화된 관리가 가능해진다는 이점이 있습니다.

 

사용자는 Oauth2.0을 통해 인증하기 때문에 관리 및 보안 면에서도 안정적이라는 장점도 존재합니다.

 

본 페이지에서 이 아키텍쳐를 구현하는데 사용했던 컴포넌트들은 다른 대체 솔루션으로 유연하게 구성할 수 있습니다.

 

예를 들면 Kubernetes 환경을 EKS에서 구성하거나, IDP를 Azure AD로 사용하거나, Authentication Proxy를 Openunison이 아닌 다른 Reverse proxy로 대체할 수 있습니다.

 

다만 Authentication Proxy는 Kubernetes Impersonation 기능을 지원해야 한다는데 주의해야 합니다.

 

이 글을 보시는 분들이 도움을 얻으셨으면 합니다.