home..

Kyverno

April 2024 (539 Words, 3 Minutes)

Kubernetes EKS AEWS Gasida Cloudnet Kyberno Admission Controller Webhook Mutating Webhook Validating Webhook Generate

Kyverno

Kyverno는 Kubernetes 클러스터에서 정책을 관리하기 위한 도구입니다. Kubernetes 리소스에 대한 검증, 생성, 변경을 위한 정책을 정의하고 적용할 수 있습니다. 이를 통해 클러스터의 보안, 컴플라이언스 및 관리를 강화할 수 있습니다. 예를 들어, 특정 네임스페이스에서만 특정 이미지를 사용하도록 강제하거나, 특정 어노테이션 없이 리소스를 생성하지 못하도록 하는 등의 정책을 설정할 수 있습니다.

OPA랑 비슷한 정책엔진 정도로 이해를 하면 될것같습니다.

https://kyverno.io/docs/introduction/

전에 다루었던 Admission Controller로서 Validating Webhook과 Mutating Webhook 등을 제어할수있습니다.

설치는 다음과 같은 과정을 거칩니다

# 설치
# EKS 설치 시 참고 https://kyverno.io/docs/installation/platform-notes/#notes-for-eks-users
# 모니터링 참고 https://kyverno.io/docs/monitoring/
cat << EOF > kyverno-value.yaml
config:
  resourceFiltersExcludeNamespaces: [ kube-system ]

admissionController:
  serviceMonitor:
    enabled: true

backgroundController:
  serviceMonitor:
    enabled: true

cleanupController:
  serviceMonitor:
    enabled: true

reportsController:
  serviceMonitor:
    enabled: true
EOF
kubectl create ns kyverno
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno --version 3.2.0-rc.3 -f kyverno-value.yaml -n kyverno

# (참고) 기본 인증서 확인 https://kyverno.io/docs/installation/customization/#default-certificates
# step-cli 설치 https://smallstep.com/docs/step-cli/installation/
wget https://dl.smallstep.com/cli/docs-cli-install/latest/step-cli_amd64.rpm
sudo rpm -i step-cli_amd64.rpm

admission webhook에는 인증서가 필요로하는데

montkim.com/eks-webhook

EKS 환경에서 self signed 인증서 관련 이슈가있어 다룬적이 있으니 다른방법으로 인증서 구현을 할 경우, 참조하면 좋을거 같아 첨부해봅니다.

실습에서 참조해볼 Grafana Dashboard 는 15987, 15804 입니다.

# ClusterPolicy 적용
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-team
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "label 'team' is required"
      pattern:
        metadata:
          labels:
            team: "?*"
EOF

# 확인
kubectl get validatingwebhookconfigurations
kubectl get ClusterPolicy

# Deployment 생성 시도
kubectl create deployment nginx --image=nginx

# Label 적용된 Pod 생성 시도
kubectl run nginx --image nginx --labels team=backend

kubectl get pod -l team=backend

#확인
kubectl get policyreport -o wide

생성된 ClusterPolicy입니다.

label 이 적용되지 않은 nginx pod를 생성시도했을때 Validating admission을 통과하지못해 ETCD까지 요청이 닿지않고 Reject 되는 과정입니다.

Warning  PolicyViolation  16s   kyverno-admission  Deployment default/nginx: [autogen-check-team] fail (blocked); validation error: label 'team' is required. rule autogen-check-team failed at path /spec
/template/metadata/labels/team/

policyviolation이라는 이벤트가 발생합니다.

구체적인 원인을 테스트해보고 이번엔 Mutating Admission 을 테스트해봅니다.

https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/

해당 순서대로라면

Validating Admission 이 실패할경우, 해당 조건을 만족시켜주는 Mutating Admission 을 설정할경우 pod 생성이 완료되어야합니다.

# Mutating Admission 
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-labels
spec:
  rules:
  - name: add-team
    match:
      any:
      - resources:
          kinds:
          - Pod
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            +(team): bravo
EOF

# 확인
kubectl get mutatingwebhookconfigurations
kubectl get ClusterPolicy

# 파드 생성 후 label 확인
kubectl run redis --image redis

마지막으로 Generation Policy에 대해 다뤄보겠습니다

https://www.slideshare.net/SaimSafder/securing-and-automating-kubernetes-with-kyverno

기존의 admission control의 연장선 개념인 Generate 입니다.

새 리소스가 생성되거나 소스가 업데이트될 때 규칙을 사용하여 추가 리소스를 생성할 수 있습니다 . 네임스페이스에 대한 새로운 RoleBinding 또는 NetworkPolicy와 같은 지원 리소스를 생성하는 데 유용합니다.

# Image Pull Secret 샘플 생
kubectl -n default create secret docker-registry regcred \
  --docker-server=myinternalreg.corp.com \
  --docker-username=john.doe \
  --docker-password=Passw0rd123! \
  --docker-email=john.doe@corp.com
  
#
kubectl get secret regcred
NAME      TYPE                             DATA   AGE
regcred   kubernetes.io/dockerconfigjson   1      26s

#
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: sync-secrets
spec:
  rules:
  - name: sync-image-pull-secret
    match:
      any:
      - resources:
          kinds:
          - Namespace
    generate:
      apiVersion: v1
      kind: Secret
      name: regcred
      namespace: ""
      synchronize: true
      clone:
        namespace: default
        name: regcred
EOF

#
kubectl get ClusterPolicy

# 신규 네임스페이스 생성 후 확인
kubectl create ns mytestns
kubectl -n mytestns get secret

# 삭제
kubectl delete clusterpolicy sync-secrets

위 과정과 같이 generate policy를 이용해서

신규로 생성한 namespace에 secret이 마운트되는것을 확인 할 수 있었습니다.

이를 이용하여 여러개의 namespace를 유기적으로 관리하는데 도움이 되지않을까 싶은 솔루션인듯 합니다.

위에서 생성했던 webhook들의 결과를 가시화된 모니터링 메트릭으로 grafana 대시보드로도 확인이 가능합니다.

아직은 적극적인 도입을 하지 않아, 어디서부터 어디까지의 활용 가능성이 있는지는 알지 못하지만, 분명 선택지가 다양하다면 원하는 기능을 구현할수있지않을까 싶네요.

개인적으로 Kyverno를 이용해 도입해보고 싶은 Admission Controller 의 마이그레이션이 있습니다.

생성되는 pod의 /proc 하위의 시스템을 mount 해주는 addon인데,

초창기에는 InitializerConfiguration 라는 형태로 Daemonset의 MountPropagation을 시켰었습니다.

다만 점차 클러스터 버전이 업그레이드되며 admission control을 mutating webhook으로 구현한적이 있습니다.

아직은 admission control의 영역을 크게 확장하지않았지만, 전사적으로 도입해도 괜찮은 도구일거라는 생각이 듭니다.

도입을 하게되면… 새로이 후기를 적어보도록 하겠습니다

그럼 20000

© 2024 mont kim   •  Powered by Soopr   •  Theme  Moonwalk