[AEWS] 6주차 쿠버네티스 인증(Authentication) 인가(Authorization) 어드미션 컨트롤 (Admission Contro

Cloudnet AWES 6주차 스터디를 진행하며 정리한 글입니다.

 
이번 포스팅은 쿠버네티스 API 서버에 대한 접근 제어 과정인 인증(Authentication), 인가 (Authorization), 어드미션 컨트롤 (Admission Control)에 대해 알아보겠습니다.
 
 

Kubernetes API Access Control

출처 : https://kubernetes.io/docs/concepts/security/controlling-access/

 
 
사용자는 kubectl과 같은 클라이언트 라이브러리를 사용하거나, REST 요청을 통해 쿠버네티스 API에 액세스합니다.
아래 그림과 같이, 실제 사용자(사람)와 파드(서비스 어카운트) 모두 API 서버에 접근하기 위해 권한을 부여받을 때 다음과 같은 단계를 거칩니다.
API 요청이 처리되는 순서는 다음과 같습니다.

1. Authentication(인증) → "요청한 사용자가 누구인지?"
2. Authorization(인가) → "이 사용자가 이 요청을 할 권한이 있는가?"
3. Admission Control(어드미션 컨트롤) → "이 요청을 허용할 것인가?"

이 세 단계를 모두 통과하면 API 서버에 요청을 보낼 수 있습니다. 이제 각각의 단계에 대해 구체적으로 알아보겠습니다.
 

Authentication (인증)

출처 : 김태민님 블로그 - https://kubetm.github.io/k8s/07-intermediate-basic-resource/authentication/

 
쿠버네티스에서는 API 요청이 오면 먼저 사용자의 신원을 확인하는 인증(Authentication) 과정을 수행합니다.
이 과정은 클러스터에 접근하는 대상이 누구이고, 맞는지 확인하는 과정으로, 쿠버네티스는 다양한 인증 방식을 지원합니다.
 

Authentication 방식

• X.509 인증서 기반 : kubeconfig에 인증서 포함하여 요청 인증하는 대표적인 방식으로, 클라이언트 인증서를 발급 받는 방식
• HTTP Basic Authentication : HTTP 요청의 헤더에 포함된 토큰 등의 정보를 활용하는 방식
• OIDC (OpenID Connect) : 외부 Identity Provider를 사용하여 인증하는 방식
• Webhook 인증 : API 서버가 외부 웹훅 서비스로 요청하여 인증하는 방식
• Proxy 인증 : Proxy 서버를 두고 인증하는 방식

 
https://kubernetes.io/docs/reference/access-authn-authz/authentication/

Authenticating

 
대표적인 X.509 클라이언트 인증서 방식에 대해 조금 더 알아보도록 하겠습니다.
 

X.509 인증

X.509는 공개키 기반(PKI - Public Key Infrastructure) 인증서 표준입니다. 
인증서에 사용자의 공개 키와 신원 정보가 포함되며, 클라이언트는 API 서버에 요청을 보낼 때 인증서를 제출하면 API 서버는 해당 인증서가 신뢰할 수 있는 CA에서 발급되었는지 확인하여 인증을 수행합니다.
 

X.509 인증 과정

 
 

1. 클라이언트가 개인 키(Private Key)와 공개 키(Public Key)를 생성
2. 공개 키를 포함하는 CSR(Certificate Signing Request) 생성
3. CSR을 쿠버네티스 CA(Cluster CA)에 제출하여 인증서 발급 요청
4. 관리자가 CSR을 승인하면 CA가 클라이언트 인증서(X.509) 서명 후 반환
5. 클라이언트는 이 인증서를 이용해 API 서버와 보안 통신 수행

 
 

X.509 인증서 구성 요소 

• 인증서가 발급된 엔터티 식별을 위한 DN
• 공개 키
• 디지털 서명
• 유효기간
• 인증서 일련 번호
• 키 사용

 
인가 과정 중 X.509 인가 과정을 이해하기 위해 X.509 인증서를 생성하고 API 서버에 접근하는 실습은 이전 포스팅에서 확인하실 수 있습니다. 해당 포스팅을 읽으신다면 아마 X.509 인증 방식에 대한 이해가 조금은 쉬우실지도 모르겠습니다. ^3^
https://hellouz818.tistory.com/46
 

---

Authorization (인가

출처 : 김태민님 블로그 - https://kubetm.github.io/k8s/07-intermediate-basic-resource/authentication/

 
인증이 완료되면, 해당 사용자가 요청한 작업을 수행할 수 있는 권한이 있는지 확인하는 인가(Authorization) 과정이 수행됩니다.
이는 쿠버네티스 클러스터에 접근하는 대상의 권한을 확인하는 과정으로, 쿠버네티스는 다양한 인가 방식을 지원합니다.
 

Authorization 방식

• RBAC (Role-Based Access Control) : Role과 Rolebinding을 활용한 역할 기반 접근 제어
• ABAC (Attribute-Based Access Control) : 속성 기반 접근 제어 
• Webhook Authorization : 외부 웹훅 서비스에서 정책 결정
• Node Authorization : Kubelet 노드가 특정 리소스에 접근하도록  허용

 
https://kubernetes.io/docs/reference/access-authn-authz/authorization/

Authorization

 
쿠버네티스는 기본적으로 RBAC 기반 인가 방식을 사용하며, 대표적인 RBAC 인가 방식에 대해 조금 더 알아보도록 하겠습니다.
 

RBAC (Role-Based Access Control)

RBAC은 사용자, 그룹, 서비스 어카운트 등에게 특정 리소스에 대한 권한을 부여하는 방식입니다.
사용자와 역할을 별개로 선언 후 두가지를 조합(binding)해서 사용자에게 권한을 부여할 수 있습니다.
사용자의 요청이 들어왔을 때 인증된 사용자의 RBAC 정책을 조회하여 해당 사용자가 요청한 작업을 수행할 권한이 있는지 확인합니다.
 

RBAC의 개념

 

• Role : 특정 네임스페이스 내에서 수행 가능한 작업 정의
• ClusterRole : 클러스터 전역에서 수행 가능한 작업 정의
• RoleBinding : Role을 사용자, 그룹, 서비스 어카운트에 연결
• ClusterRoleBinding : ClusterRole을 클러스터 전역의 사용자, 그룹, 서비스 어카운트에 연결

RBAC에서 연결하는 Service Account란?

• 쿠버네티스 내부에서 실행되는 어플리케이션 (ex, pod)이 API 서버와 통신할 때 사용하는 계정
• 쿠버네티스는 pod가 API 서버와 통신할 때 기본 서비스 어카운트를 자동으로 부여하지만, 필요에 따라 커스텀 어카운트 할당 가능
• 네임스페이스 마다 기본 Service Account가 자동 생성
• 일반 사용자는 X.509, OIDC 등 수동으로 추가하지만, Service Account는 JWT 기반

 

RBAC 인가 과정 실습

인가 과정 중 RBAC 인가 과정을 확인하기 위해 RBAC을 사용하여 사용자에게 특정 권한을 부여하는 실습을 진행해보았습니다.
 
쿠버네티스에 사용자를 위한 서비스 어카운트를 생성합니다. - Service Account : dev-k8s, infra-k8s
사용자는 각각 네임스페이스 별로 다른 권한(인가)을 가집니다. - Role : dev-k8s(dev-team 네임스페이스 내 모든 동작) , infra-k8s(infra-team 네임스페이스 내 모든 동작)
각각 별도의 파드를 생성하고, 해당 파드에 서비스 어카운트를 지정하여 권한에 대한 테스트를 진행하는 실습입니다.

# 각 팀 네임스페이스 생성
❯ kubectl create namespace dev-team
namespace/dev-team created
❯ kubectl create ns infra-team
namespace/infra-team created

# 각 팀 서비스 어카운트 생성
❯ kubectl create sa dev-k8s -n dev-team
serviceaccount/dev-k8s created
❯ kubectl create sa infra-k8s -n infra-team
serviceaccount/infra-k8s created

❯ kubectl get sa dev-k8s -n dev-team -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2025-03-11T20:05:57Z"
  name: dev-k8s
  namespace: dev-team
  resourceVersion: "437602"
  uid: a54b69f1-26c9-416f-891e-065da0dd1a00
  
❯ kubectl get sa infra-k8s -n infra-team -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2025-03-11T20:06:20Z"
  name: infra-k8s
  namespace: infra-team
  resourceVersion: "437705"
  uid: 76a791ed-4053-4e1d-98dc-08046431086b

# 각 네임스페이스에 kubectl 파드 생성
❯ cat <<EOF | kubectl create -f -       
apiVersion: v1
kind: Pod
metadata:
  name: dev-kubectl
  namespace: dev-team
spec:
  serviceAccountName: dev-k8s
  containers:
  - name: kubectl-pod
    image: bitnami/kubectl:1.31.4
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF
pod/dev-kubectl created

❯ cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: infra-kubectl
  namespace: infra-team
spec:
  serviceAccountName: infra-k8s
  containers:
  - name: kubectl-pod
    image: bitnami/kubectl:1.31.4
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF
pod/infra-kubectl created

# 확인
❯ kubectl get pod -o dev-kubectl -n dev-team -o yaml
apiVersion: v1
items:
- apiVersion: v1
  kind: Pod
  metadata:
    creationTimestamp: "2025-03-11T20:07:45Z"
    name: dev-kubectl
    namespace: dev-team
    resourceVersion: "438110"
    uid: 18f91aa0-713e-4546-963f-8be4049b404c
  spec:
    containers:
    - args:
      - -f
      - /dev/null
      command:
      - tail
      image: bitnami/kubectl:1.31.4
      imagePullPolicy: IfNotPresent
      name: kubectl-pod
      resources: {}
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      volumeMounts:
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: kube-api-access-5xpd9
        readOnly: true
    dnsPolicy: ClusterFirst
    enableServiceLinks: true
    nodeName: ip-192-168-2-169.ap-northeast-2.compute.internal
    preemptionPolicy: PreemptLowerPriority
    priority: 0
    restartPolicy: Always
    schedulerName: default-scheduler
    securityContext: {}
    serviceAccount: dev-k8s
    serviceAccountName: dev-k8s ## 확인
    
❯ kubectl get pod -o infra-kubectl -n infra-team -o yaml
apiVersion: v1
items:
- apiVersion: v1
  kind: Pod
  metadata:
    creationTimestamp: "2025-03-11T20:07:53Z"
    name: infra-kubectl
    namespace: infra-team
    resourceVersion: "438148"
    uid: e51e8320-6ebd-41cc-b942-4f2be4ea54cb
  spec:
    containers:
    - args:
      - -f
      - /dev/null
      command:
      - tail
      image: bitnami/kubectl:1.31.4
      imagePullPolicy: IfNotPresent
      name: kubectl-pod
      resources: {}
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      volumeMounts:
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: kube-api-access-rvhf5
        readOnly: true
    dnsPolicy: ClusterFirst
    enableServiceLinks: true
    nodeName: ip-192-168-3-35.ap-northeast-2.compute.internal
    preemptionPolicy: PreemptLowerPriority
    priority: 0
    restartPolicy: Always
    schedulerName: default-scheduler
    securityContext: {}
    serviceAccount: infra-k8s
    serviceAccountName: infra-k8s ## 확인
    

# 파드에 적용되는 서비스 어카운트(토큰 정보 확인)
❯ kubectl exec -it dev-kubectl -n dev-team -- ls /run/secrets/kubernetes.io/serviceaccount
ca.crt	namespace  token
❯ kubectl exec -it dev-kubectl -n dev-team -- cat /run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6ImZhMDNjOTZmZjA5YzI1MGFiYmVhNWZiNTExYzRiZjkyYzUxNmEzN2MifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjIl0sImV4cCI6MTc3MzI1OTY2NSwiaWF0IjoxNzQxNzIzNjY1LCJpc3MiOiJodHRwczovL29pZGMuZWtzLmFwLW5vcnRoZWFzdC0yLmFtYXpvbmF3cy5jb20vaWQvOEZBNDc3QTFCMzBFNUU2RDZFNzQ3M0JENUZBOEVBOTQiLCJqdGkiOiJkMjllOTZiNS1iYTQ4LTRhZTgtOTc5My01ZDBiNmFmOTk3ODciLCJrdWJlcm5ldGVzLmlvIjp7Im5hbWVzcGFjZSI6ImRldi10ZWFtIiwibm9kZSI6eyJuYW1lIjoiaXAtMTkyLTE2OC0yLTE2OS5hcC1ub3J0aGVhc3QtMi5jb21wdXRlLmludGVybmFsIiwidWlkIjoiMDExYWRjYmEtYTA2NC00ODdhLThkZTItYWJkZDgzYjcxMThiIn0sInBvZCI6eyJuYW1lIjoiZGV2LWt1YmVjdGwiLCJ1aWQiOiIxOGY5MWFhMC03MTNlLTQ1NDYtOTYzZi04YmU0MDQ5YjQwNGMifSwic2VydmljZWFjY291bnQiOnsibmFtZSI6ImRldi1rOHMiLCJ1aWQiOiJhNTRiNjlmMS0yNmM5LTQxNmYtODkxZS0wNjVkYTBkZDFhMDAifSwid2FybmFmdGVyIjoxNzQxNzI3MjcyfSwibmJmIjoxNzQxNzIzNjY1LCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGV2LXRlYW06ZGV2LWs4cyJ9.ehG9yC2aGDKh1LTDKxKmpLcKYwkHO4Oon0lJ5RnPCfMYJGQy9lGJYMYHUyGPT89_VG5s7lU5PVGvenHH4elY5z5cemWV3QagQ5S-3XzknN4By54KBsRMbOT3XHaBadSgLOdSqJlTtus3Ii-ICJME8JUqZO9THnZOOC_d46G2Cvo3Cm-oWfeOIt7-J4dNvxsG_320dYJIEETg9FI7HPIHiiTCGSrn0VRxHGX4s6pIL_ogDUiHfJLtkYW-2u9YubP4YTxOErEC-r7l4yBEbGr9bXGouF7G2X3u99xgb5MIzVHOctvo2vGDZ13LgEFDbm5gRo4QEWExdANNQmziRxjGVg
❯ kubectl exec -it dev-kubectl -n dev-team -- cat /run/secrets/kubernetes.io/serviceaccount/namespace
dev-team
❯ kubectl exec -it dev-kubectl -n dev-team -- cat /run/secrets/kubernetes.io/serviceaccount/ca.crt
-----BEGIN CERTIFICATE-----
MIIDBTCCAe2gAwIBAgIIbtKOrG36yDMwDQYJKoZIhvcNAQELBQAwFTETMBEGA1UE
AxMKa3ViZXJuZXRlczAeFw0yNTAzMTAxNDM3MDBaFw0zNTAzMDgxNDQyMDBaMBUx
EzARBgNVBAMTCmt1YmVybmV0ZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCrpSeRPnR2XHMyimNInWLB6/I/HYRkRgVIBOhKawJMzUugGYq/C/oNkuBn
~~
+py6S2zt+U3agupSZ1QPLY2EZ9jvZ59+dU6vpoVk41nYj+X1LXb6ujqWIHxugC7W
Zy1zzJolbBuV/xfSsCTQuZwl9qr6mN/7GsINnnbctghO5OHg2YrPkw6jhoDEFUC4
IGlx4GWpp1o8CEIVfizARLp2qLNMPFn+xee8vCoIyG6Wjlac2wxSRZMyuRkmafcX
gojje2bZTpSdOAPntgRitpbmMsWHq+I+y0zBTqTZ/G2rE3pzS4mlnt/zZ4orowhm
RLDJmOf8o6YVk82demHasW5+IUUUd5E62EMsrgL2UMnHJpaCLihvWnwsa6kcN66P
uf3bRFwfTcoa
-----END CERTIFICATE-----

 
위에서 네임스페이스, 서비스 어카운트, 테스트를 위한 파드 생성 등 작업을 모두 마쳤습니다.
이제 각 파드에 접속하여 kubectl get pod 라는 명령을 내릴 수 있는지 확인해보고, 롤과 롤바인딩을 생성하여 차이를 비교해보겠습니다.

# 각 파드에서 실행할 단축 명령어 지정
alias k1='kubectl exec -it dev-kubectl -n dev-team -- kubectl'
alias k2='kubectl exec -it infra-kubectl -n infra-team -- kubectl'

# 권한 테스트 -  kubectl exec -it dev-kubectl -n dev-team -- kubectl get pods 와 동일한 실행임
❯ k1 get pods                                          
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:dev-team:dev-k8s" cannot list resource "pods" in API group "" in the namespace "dev-team"
command terminated with exit code 1
❯ k1 run nginx --image nginx:1.20-alpine               

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:dev-team:dev-k8s" cannot create resource "pods" in API group "" in the namespace "dev-team"
command terminated with exit code 1

# 하지만 권한이 없음!
❯ k1 auth can-i get pods                             
no
command terminated with exit code 1

# 각각 네임스페이스내의 모든 권한에 대한 롤 생성
❯ cat <<EOF | kubectl create -f -                              
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-dev-team
  namespace: dev-team
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-infra-team
  namespace: infra-team
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

role.rbac.authorization.k8s.io/role-dev-team created
role.rbac.authorization.k8s.io/role-infra-team created

❯ kubectl describe roles role-dev-team -n dev-team    
Name:         role-dev-team
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
  
  
# 롤바인딩 생성 : '서비스어카운트 <-> 롤' 간 서로 연동
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: roleB-dev-team
  namespace: dev-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-dev-team
subjects:
- kind: ServiceAccount
  name: dev-k8s
  namespace: dev-team
EOF

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: roleB-infra-team
  namespace: infra-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-infra-team
subjects:
- kind: ServiceAccount
  name: infra-k8s
  namespace: infra-team
EOF


❯ kubectl describe rolebindings roleB-dev-team -n dev-team
Name:         roleB-dev-team
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  role-dev-team
Subjects:
  Kind            Name     Namespace
  ----            ----     ---------
  ServiceAccount  dev-k8s  dev-team
  
# 권한 테스트 -  kubectl exec -it dev-kubectl -n dev-team -- kubectl get pods 와 동일한 실행임
# 조회 가능!
❯ k1 get pods                                          
NAME          READY   STATUS    RESTARTS   AGE
dev-kubectl   1/1     Running   0          8m7s

# 파드 생성도 가능!
❯ k1 run nginx --image nginx:1.20-alpine               
pod/nginx created

# 하지만 다른 네임스페이스에 대해서는 조회 불가능!
❯ k1 get pods -n kube-system -v=6                     
I0311 20:16:04.249305      83 merged_client_builder.go:121] Using in-cluster configuration
I0311 20:16:04.261392      83 merged_client_builder.go:121] Using in-cluster configuration
I0311 20:16:04.271952      83 round_trippers.go:553] GET https://10.100.0.1:443/api/v1/namespaces/kube-system/pods?limit=500 403 Forbidden in 9 milliseconds
I0311 20:16:04.272622      83 helpers.go:246] server response object: [{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "pods is forbidden: User \"system:serviceaccount:dev-team:dev-k8s\" cannot list resource \"pods\" in API group \"\" in the namespace \"kube-system\"",
  "reason": "Forbidden",
  "details": {
    "kind": "pods"
  },
  "code": 403
}]
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:dev-team:dev-k8s" cannot list resource "pods" in API group "" in the namespace "kube-system"
command terminated with exit code 1

# 연결된 네임스페이스에 대해서는 조회 가능
❯ k1 get pods -v=6                                   
I0311 20:16:34.664963      93 merged_client_builder.go:163] Using in-cluster namespace
I0311 20:16:34.665334      93 merged_client_builder.go:121] Using in-cluster configuration
I0311 20:16:34.675794      93 merged_client_builder.go:121] Using in-cluster configuration
I0311 20:16:34.695661      93 round_trippers.go:553] GET https://10.100.0.1:443/api/v1/namespaces/dev-team/pods?limit=500 200 OK in 18 milliseconds
NAME          READY   STATUS    RESTARTS   AGE
dev-kubectl   1/1     Running   0          8m49s
nginx         1/1     Running   0          36s

# 이제 권한 있지롱~
❯ k1 auth can-i get pods                               
yes

 
 

---

Admission Control (어드미션 컨트롤)

인증과 인가를 통과한 요청이라도, 쿠버네티스는 즉시 실행하지 않고, 추가 검증과 정책 적용을 위해 어드미션 컨트롤러(Admission Controller) 단계를 거칩니다.

https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

Admission Control

• 쿠버네티스 API 서버에서 리소스를 etcd에 기록하기 전에 추가적인 검증 및 수정 작업을 수행하는 단계
• 인증과 인가를 통과한 요청도, 어드미션 컨트롤러가 추가적인 정책을 검사하고 변경할 수 있음
• 기본적으로 활성화된 컨트롤러가 있으며, 필요에 따라 추가적인 웹훅(Validating & Mutating Webhooks) 설정 가능

Admission Controller

• API 서버에서 인증 및 인가 후, 리소스가 etcd에 기록되기 전 추가적인 검증을 수행하는 단계
• Validating Admission Controller: 요청을 검증하고 거부할 수 있음
• Mutating Admission Controller: 요청을 변경할 수 있음

Admission Controller 유형

• Mutating Admission controller
  • 요청을 변경할 수 있음
• Validating Admission controller
  • 요청을 검증하고 거부할 수 있음

 
https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

Dynamic Admission Control

 
 
기본적으로 활성화된 어드미션 컨트롤러 중 Mutating Admission webhook을 사용하여 object가 생성되기 전에 pod에 nginx sidecar container를 inject하는 실습 포스팅을 참고차 공유 드립니다.
 
2년전 제가 쓴 포스팅,, 지금 보니 이해할 수 없도록 구구절절 적어놓은 것을 봤을 때 입사 직 후 말하는 감자 수준일 때 작성했던 것 같은데,, 당시에 이해가 많이 부족했나 봅니다,,^^;;
언젠간 포스팅을 보완해야할 것 같습니다..  + 백로그 추가!
https://hellouz818.tistory.com/10

Webhook

 
 
여담)
작년에 제가 쿠버네티스 코리아 그룹에서 관련 세미나를 했는데,, (주제 : Admission Webhook 직접 개발하지 마세요 Kyverno에게 양보하세요 - https://www.meetup.com/ko-KR/cloud-native-computing-seoul/events/301433550/)

Login to Meetup | Meetup

해당 자료도 시간이 된다면 추가하도록 하겠습니다.. + 백로그 추가!