[90DayOfDevOps] Day 32~34 - Runtime Defence & Monitoring

Main reference

• https://github.com/MichaelCade/90DaysOfDevOps/blob/main/2023/

90DaysOfDevOps/2023/day32.md at main · MichaelCade/90DaysOfDevOps

 

 

Day 32

< Vulnerability and patch management >

 

 

취약점 관리에서 첫 단계 - 런타임에서 현재 상태 모니터링하기

 

호스트 수준에서 취약점을 스캔할 수 있는 여러 솔루션들이 있음(AWS Inspector, OpenVAS, Vuls, Lynis 등)

 

 

lynis 이용해서 machine을 scan 해보자!

나는 인텔 맥이라, 그냥 brew install lynis을 해주었다.

그런 다음

 

sudo lynis audit system

 

해주면

 

호스트 시스템에 대한 보고서가 반환되는 걸 확인할 수 있다

하지만 이건 너무 간단하게 확인하는 도구이고, 

여러 호스트를 관리해야하는 복잡한 시스템, 중앙 집중식 솔루션을 사용하여 전체를 개요하는 게 좋다~ 

 

 

그렇다면 다각적인 k8s 클러스터의 취약성을 관리하는 방식을 활용해 보자.

 

[ Kubernetes vulnerabilities and misconfigurations ]

 

Kubernetes configuration 감사하는 여러 툴들:

• Kubescape - its CLI can give you instant feedback about potential security and compliance issues
• Trivy - Aqua Security's open-source scanner used for both image, cloud and Kubernetes scanning
• Checkov - Bridgecrew's open-source tool scanning cloud infrastructure and Kubernetes

 

[ Application vulnerabilities ]

 

• 애플리케이션 이미지는 컨테이너 기반 배포 시스템의 기본 부분이며 애플리케이션과 모든 종속성을 배포 가능한 단일 artifact(산출물 정도...)로 패키지하는 데 사용됨
• 이러한 이미지는 공개 또는 비공개 저장소에서 가져오는 경우가 많으며 공격자가 악용할 수 있는 취약성, 잘못된 구성 또는 기타 보안 문제가 포함될 수 있음
• 이미지 스캐닝 도구는 알려진 취약점과 잘못된 구성뿐만 아니라 안전하지 않은 소프트웨어 라이브러리, 오래된 패키지 또는 기본 비밀번호와 같은 기타 문제에 대해 이미지를 분석할 수 있음
• 이러한 도구는 이미지의 내용을 알려진 취약점의 데이터베이스와 비교하고 문제의 심각도에 대한 정보를 제공함 

 

+artifact

https://www.inflearn.com/questions/23403/artifact%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94

 

>> Trivy에는 k8s 클러스터에 있는 컨테이너의 애플리케이션 취약성을 모니터링하는 operator가 있음.

 

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set="trivy.ignoreUnfixed=true" \
  --version 0.11.1

 

instll 해주고

kubectl get vulnerabilityreports --all-namespaces -o wide

kubectl로 CRD통한 취약성을 확인할 수 있음.

 

 

 

Day 34 

< Runtime access control >

 

• Kubernetes는 인증 메커니즘, 액세스 제어(RBAC), 승인 제어, 네트워크 정책 등을 포함하여 액세스 제어를 위한 여러 메커니즘을 제공합니다. 컴퓨터 시스템 클러스터의 보안과 신뢰성을 보장하려면 액세스 제어를 적절하게 구성하고 관리하는 것이 중요

 

[ Authentication ]

 

• 인증 : Kubernetes API 서버 또는 클러스터 리소스에 액세스하려고 시도하는 사용자 또는 프로세스의 ID를 확인하는 프로세스

 

>> 주로 사용되는 토큰 및 인증 매커니즘 예시

:  Kubernetes는 X.509 클라이언트 인증서, 전달자 토큰 및 OIDC(OpenID Connect) 토큰을 포함한 여러 인증 메커니즘을 제공

 

 

1. X.509 클라이언트 인증서는 Kubernetes에서 가장 안전하고 널리 사용되는 인증 메커니즘. 클라이언트는 신뢰할 수 있는 인증 기관(CA)에 대해 인증서를 확인하는 API 서버에 유효한 X.509 클라이언트 인증서를 제공함. 

 

2. Bearer 토큰은 Kubernetes에서 널리 사용되는 또 다른 인증 메커니즘입니다. 전달자 토큰은 사용자 또는 프로세스의 ID를 나타내는 문자열

 

3. OIDC 토큰은 Kubernetes의 최신 인증 메커니즘입니다. OIDC는 Google, Azure 또는 Okta와 같은 타사 ID 공급자를 사용하여 인증 및 권한 부여를 가능하게 하는 OAuth 2.0 프로토콜 위에 있는 ID 계층

 

4. Kubernetes는 API 서버가 구성된 웹훅 서비스에 인증 요청을 보내는 웹훅 토큰 인증도 지원

 

5. 인증 외에도 Kubernetes는 특정 리소스에 대한 액세스를 제어하는 ​​인증 메커니즘을 제공합니다.

- RBAC(역할 기반 액세스 제어)는 Kubernetes에서 가장 널리 사용되는 인증 메커니즘입니다. RBAC를 사용하면 관리자는 직무나 책임에 따라 사용자 또는 사용자 그룹의 역할과 권한을 정의할 수 있음

 

 

 

>> 자격증명 사용하는 예시를 해보자~

 

kubectl -n kube-system exec $(kubectl get pods -n kube-system | grep kube-proxy | head -n 1 | awk '{print $1}') -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

Kube-proxy 구성 요소의 Kubernetes 서비스 계정 토큰을 얻을 수 있음

 

요렇게

 

이 jwt 토큰을 알아보자

이 토큰을 획득하면 

 

export KUBE_PROXY_POD_NAME=`kubectl get pods -n kube-system | grep kube-proxy | head -n 1 | awk '{print $1}'`
export TOKEN=`kubectl -n kube-system exec $KUBE_PROXY_POD_NAME -- cat /var/run/secrets/kubernetes.io/serviceaccount/token`
export API_SERVER_URL=`kubectl config view --minify --output jsonpath="{.clusters[*].cluster.server}"`
kubectl -n kube-system exec $KUBE_PROXY_POD_NAME -- cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt > /tmp/ca.crt
kubectl config set-cluster access-test --server=$API_SERVER_URL --certificate-authority=/tmp/ca.crt
kubectl config set-context access-test --cluster=access-test
kubectl config set-credentials user --token=$TOKEN
kubectl config set-context access-test --user=user
kubectl config use-context access-test

 

kubectl 기본 자격 증명 대신에 이렇게 설정하고,

kube-proxy에서 훔쳤다고 가정한 token을 사용하도록 설정했음

그러면 Kubectl nodes에서 작동한다... 

이건 자격 증명을 도난 당한 경우에 어떻게 사용할 수 있는지 보여주는 예.

 

 

[ Authorization ]

 

• Kubernetes RBAC(Role-Based Access Control) = Kubernetes 클러스터 내의 리소스에 대한 액세스를 제어하는 ​​데 사용되는 보안 메커니즘
  • RBAC는 사용자 및 서비스 계정이 Kubernetes 리소스에 대해 수행할 수 있는 작업을 결정하는 정책을 정의하는 데 사용됨
• Kubernetes에서 RBAC는 역할과 역할 바인딩이라는 두 가지 주요 개체 유형을 정의하여 작동
  • 역할 = Kubernetes 클러스터에 있는 하나 이상의 리소스에 적용할 수 있는 권한 모음
  • 역할 bindings 은 사용자, 사용자 그룹 또는 서비스 계정에 역할을 부여하는 데 사용됨
• 사용자 또는 서비스 계정이 Kubernetes의 리소스에 대한 작업을 수행하려고 시도하면 Kubernetes API 서버는 관련 역할 바인딩에 정의된 권한을 확인하고, 사용자 또는 서비스 계정에 작업을 수행할 권한이 있으면 API 서버가 액세스 권한을 부여함. 사용자 또는 서비스 계정이 승인되지 않으면 API 서버는 액세스를 거부함.
• RBAC를 사용하면 pod, 서비스, 배포 등을 포함한 광범위한 Kubernetes 리소스에 대한 액세스를 제어할 수 있음
•  RBAC 정책은 클러스터 수준, 네임스페이스 수준, 개별 리소스 수준을 포함하여 Kubernetes 클러스터의 다양한 수준에서 정의할 수 있음

이런 식으로 ClusterRole을 kubectl로 확인할 수 있는데, 

rbac authorization으로 적용되어 있는 것도 확인할 수 있다. 

 

Kubernetes RBAC는 좋은 인증 시스템인가요? 네,하지만...

• 때로는 관리하기가 다소 복잡할 수 있습니다.
• Authorization은 verb와 object의 조합에 권한 부여 받을 수 있다*(??)... 

 

+ 동사와 객체의 조합에 대한 권한 부여 한계 

Kubernetes RBAC에서는 권한을 "동사(verb)"와 "객체(object)"의 조합으로 제어합니다.

예를 들어, 사용자에게 특정 리소스를 만들거나 삭제하는 권한을 부여할 수 있습니다.

하지만 한계는 두 가지 동작에 대한 세밀한 제어가 어렵다는 것입니다.

예를 들어, 특정 사용자가 특정 리소스를 생성할 수 있지만,  특정 조건에서만 생성할 수 있는 등의 세밀한 제어를 하기 어렵습니다.

 

[ Runtime admission controllers ]

 

; Kubernetes API 서버에 대한 요청이 처리되기 전에 이를 가로채서 관리자가 생성되거나 수정되는 리소스에 대한 사용자 지정 정책 및 제한 사항을 적용할 수 있도록 하는 플러그인 유형

 

 

; Kubernetes의 admission 컨트롤러 유형

• MutatingAdmissionWebhook: Kubernetes API 서버에 대한 요청이 지속되기 전에 수정하거나 변경할 수 있습니다.
• ValidatingAdmissionWebhook: 사용자 지정 정책을 기반으로 Kubernetes API 서버에 대한 요청을 검증하거나 거부할 수 있습니다.

 

오픈소스 admission controller projects들 

: OPA Gatekeeper, Kyverno

 

 

Kyverno 사용해보자~

: Kyverno를 사용하면 사용자는 정책을 코드로 정의하고 이를 포드, 배포, 서비스 등과 같은 Kubernetes 리소스에 적용할 수 있음

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace --set replicaCount=1
helm install kyverno-policies kyverno/kyverno-policies -n kyverno

 

install 해주고

 

kubectl apply -f - << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: no-privileged-containers
  annotations:
    policies.kyverno.io/title: No Privileged Containers
    policies.kyverno.io/subject: Pod
spec:
  validationFailureAction: Enforce
  rules:
    - name: no-privileged-containers
      match:
        any:
        - resources:
            kinds:
              - Pod
      validate:
        message: >-
          Privileged containers are not allowed!
        pattern:
          spec:
            containers:
              - =(securityContext):
                  =(privileged): "false"
EOF

 

 

pod의 securityContext 아래에서 privileged flag가 false인지 검증하는 policy를 확인할 수 있다... 

그리고 

kubectl apply -f - << EOF
apiVersion: v1
kind: Pod
metadata:
  name: privileged-container-demo
spec:
  containers:
  - name: privileged-container-demo
    image: nginx:latest
    securityContext:
      privileged: true
EOF

이 pod을 spawn up하려고 하면 실패해야한다! kyverno policy가 없다면

 

근데 난 된다...

쩝.

그래서 privileged:false로 만들어서 강제 실패로 만들어줬다

 

 

admission webhook "validate.kyverno.svc-fail" denied the request: 

policy Pod/default/privileged-container-demo for resource violation: 

no-privileged-containers:
  no-privileged-containers: 'validation error: Privileged containers are not allowed!.
    rule no-privileged-containers failed at path /spec/containers/0/securityContext/privileged/'

이렇게 뜨면 된다고 하는데... 흠. 

 

난 똑같이 해주었는데... 왜 created가 될까? 

내 노트북 어디에 털리는 거 아니겠지? ㄷㄷ

 

 

---

 

그리고 helm과 많이 비교하는 Kustomize가 궁금해져서 

조금 찾아봤다.

 

https://wookiist.dev/159

[DevOps/번역글] Helm vs Kustomize: 어떻게 배포할 것인가?

 

 

https://www.sktenterprise.com/bizInsight/blogDetail/dev/2664

kustomize 를 활용하여 helm chart 배포하기 | 개발자 Story | SKT Enterprise

 

 

https://velog.io/@pullee/Kustomize%EB%A1%9C-K8S-%EB%A6%AC%EC%86%8C%EC%8A%A4-%EA%B4%80%EB%A6%AC%ED%95%98%EA%B8%B0

Kustomize로 K8S 리소스 관리하기