사전 준비
위와 같이 사전 준비가 필요합니다. 저번 글에서 설명했듯이, EKS를 배포하기 위한 VPC를 생성하고, Public Subnet, Private Subnet을 생성합니다. 그 후 EKS Cluster에 접근하기 위한 bastion EC2를 미리 생성합니다.
추가로 지난번 실습 때 진행했었던 ExternalDNS와 AWS LB Controller, EBS csi driver 설치, gp3 스토리지 클래스 생성까지 해주시고, Prometheus와 Grafana까지 설치합니다.
Kyverno
ChatGPT가 알려주는 Kyverno
Kyverno는 Kubernetes 클러스터 내에서 정책 기반 관리를 제공하는 오픈 소스 프로젝트입니다. 이 도구는 보안, 규정 준수, 그리고 리소스 관리와 같은 측면에서 Kubernetes 리소스의 생성, 변경, 삭제를 제어하기 위한 정책을 정의하고 적용하는 데 사용됩니다. Kyverno를 사용하면 Kubernetes 네이티브 언어로 정책을 선언적으로(Declaratively) 작성할 수 있으며, 이를 통해 YAML 파일을 사용해 간단하게 클러스터 정책을 관리할 수 있습니다.
즉, Kyverno 정책을 사용하여 kubernetes Cluster내의 자원들을 검증하고, 변경하고, 생성할 수 있습니다.
- 정책을 코드로 관리합니다.
- YAML 형태의 선억적 언어이며, 언어를 배울 필요 없이 정책을 생성할 수 있습니다.
-
kyverno는 Mutating admission과 Validating admission 사이의 Admission Review를 담당하여 동작하며 설정되어있는 정책들을 통해서 허용/거부합니다.
Kyverno 정책
실습
namespace 생성
kubectl create ns kyverno
먼저 kynerno를 관리할 namespace를 생성합니다.
kyverno 설정 파일 생성
config:
resourceFiltersExcludeNamespaces: [ kube-system ]
admissionController:
serviceMonitor:
enabled: true
backgroundController:
serviceMonitor:
enabled: true
cleanupController:
serviceMonitor:
enabled: true
reportsController:
serviceMonitor:
enabled: true
그 후 kyverno의 정책이 적용되지 않을 namespace를 지정합니다. kube-system에 kyveno가 영향을 미쳐 cluster에 대한 중요한 리소스들이 동작하지 않으면 안되니 제외시켜줍니다. 이에 대한 자세한 내용은 공식문서를 참고해주세요!
kyverno 설치(Helm)
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
kyverno 확인
kubectl get all -n kyverno
kyveno namespace에 설치된 모든 리소스를 확인해보겠습니다.
kubectl get crd | grep kyverno
kubectl get pod,svc -n kyverno
Validation(검증)
ChatGPT가 알려주는 Kyverno Validation
Kyverno의 검증 기능은 쿠버네티스 리소스의 생성 및 업데이트 요청이 특정 규칙을 준수하는지 확인합니다. 이를 통해 클러스터의 리소스 구성이 일관되게 유지되도록 돕습니다. 검증 정책은 주로 보안, 컴플라이언스, 리소스 사용 제한과 같은 요구 사항을 강제하는 데 사용됩니다.
즉, Kyverno Validation은 쿠버네티스 리소스가 생성되거나 업데이트될 때 정해놓은 policy를 충족하는지 확인하고 통제합니다.
ClusterPolicy 적용
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: "?*"
위와 같이 clusterPolicy를 적용해보겠습니다.
check-team이라는 규칙이 생성되는데 pod에 적용되며 team이라는 label이 명시되어야 배포가 가능한 정책입니다.
Validation 확인
kubectl get validatingwebhookconfigurations
validatingwebhookconfigurations 목록을 출력합니다.
kubectl get ClusterPolicy
위의 명령어로 ClusterPolicy가 정상적으로 생성되었는지 확인해보겠습니다.
Pod 생성
kubectl create deployment nginx --image=nginx
실습을 위해 nginx deployment를 생성합니다.
하지만 위에서 설정한 Kyverno Validation의 정책에 의해 team이 설정되어 있지 않아 deployment가 배포되지 않습니다.
kubectl run nginx --image nginx --labels team=backend
labels를 통해 team=backend로 설정하여 다시 배포해보겠습니다.
정상적으로 배포가 됩니다!
Policy Report 확인
kubectl get policyreport -o wide
policyreport를 통해 PASS/FAIL/WARN등 권한 호출에 대해 요약된 정보를 확인하실 수 있습니다.
Mutation(변경)
ChatGPT가 알려주는 Kyverno Mutation
Kyverno의 변경(Mutation) 기능은 쿠버네티스 리소스가 클러스터에 생성되거나 업데이트될 때 자동으로 리소스의 구성을 수정합니다. 이 기능을 사용하면 개발자와 운영 팀이 수동으로 리소스를 수정할 필요 없이 일관된 구성을 유지할 수 있습니다.
즉, Kyverno Mutation은 쿠버네티스 리소스가 클러스터에 생성되거나 업데이트 될 때 정해놓은 구성을 적용시킵니다.
ClusterPolicy 생성
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
위의 예제와 같이ClusterPolicy를 생성합니다.
mutate를 통해 Pod가 생성될 때 team=bravo 라는 labels가 더해져서 생성됩니다.
ClusterPolicy 확인
kubectl get mutatingwebhookconfigurations
먼저 mutatingwebhookconfigureations를 확인해보겠습니다.
kyverno-policy-mutating-* 으로 생성되었습니다.
kubectl get ClusterPolicy
ClusterPolicy를 출력해보면 위에서 생성한 Cluster Policy 이름인 add-lables가 보여집니다.
Pod 생성
kubectl run redis --image redis
위의 명령어로 pod를 생성해보겠습니다.
Pod Label 확인
kubectl get pod redis --show-labels
--show-labels 옵션을 주어 labels까지 출력시켜보겠습니다.
team=bravo라는 labels이 붙은 것을 확인하실 수 있습니다.
pod 생성(labels 부착)
kubectl run newredis --image redis -l team=alpha
이번엔 team=alpha 라는 labels을 부착한 pod를 배포해보겠습니다.
pod label 확인
kubectl get pod newredis --show-labels
--show-labels 옵션을 주어 labels까지 출력시켜보겠습니다.
아까와의 차이점은 labels이 덮어쓰여진다는 것입니다.
Generation(생성)
ChatGPT가 알려주는 Kyverno Generation
Kyverno의 생성(Generation) 기능은 특정 쿠버네티스 리소스가 생성될 때 자동으로 다른 관련 리소스를 생성하거나 업데이트하는 데 사용됩니다. 이 기능을 통해 리소스 간의 의존성을 자동으로 관리하고, 필요한 보조 리소스를 자동으로 생성하여 애플리케이션 배포를 더욱 간편하게 만들 수 있습니다.
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
먼저 image pull secret을 실행할 Secret을 Cluster에 생성합니다.
Secret 확인
kubectl get secret regcred
생성된 Secret을 확인합니다.
ClusterPolicy 생성
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: "{{request.object.metadata.name}}"
synchronize: true
clone:
namespace: default
name: regcred
위의 예제와 같이 Cluster Policy를 생성합니다.
generate를 통해 namespace가 생성될 때 마다 regcred Secret이 생성되게 설정되어있습니다.
ClusterPolicy 확인
kubectl get ClusterPolicy
생성된 ClusterPolicy를 확인해보겠습니다.
namespace 생성
kubectl create ns mytestns
mytestns라는 namespace를 생성합니다.
namespace의 secret 확인
kubectl -n mytestns get secret
방금 생성한 namsespcae에 secret을 확인해보면 아래와 같이 regcred secret이 생성되어 있는 것을 확인하실 수 있습니다.
Grafana
15987 dashboard를 통해 kyverno 리소스를 아래와 같이 한눈에 확인할 수 있습니다.
Grafana로 Kyverno를 모니터링하는 것은 Cluster 관리자와 보안 관리자에게 한눈에 인사이트를 제공할 수 있습니다. 또, Cluster의 Health Check와 보안 상태를 꾸준히 관리하는 것이 가능해집니다.
Reference
- https://kyverno.io/docs/kyverno-policies/
'스터디 이야기 > AWS EKS' 카테고리의 다른 글
[AEWS] 7-2. Amazon EKS - CI/CD (ArgoCD/ArgoRollouts) (1) | 2024.04.16 |
---|---|
[AEWS] 7-1. Amazon EKS - CI/CD (Jenkins) (0) | 2024.04.16 |
[AEWS] 6-2. Amazon EKS - Security (IRSA, EKS PodIdentity) (0) | 2024.04.11 |
[AEWS] 6-1. Amazon EKS - Security (EKS 인증/인가) (0) | 2024.04.09 |