클라우드/DevOps

[90DayOfDevOps] Day 28~31 - Runtime Defence & Monitoring

dayeonsheep 2024. 3. 26. 12:07

Main reference

 

Day 28

<모니터링>

 

모니터링 왜 해야되나? >> 런타임 보안 때문에

뭐를 모니터링 해야하나? 

>>

  • 제어 플레인 로깅: 인프라의 모든 오케스트레이션은 이 제어 플레인을 통해 이루어지므로 인프라 수준에서 누가 무엇을 했는지 항상 아는 것이 중요
  • 운영 수준 로그: 시스템 활동을 추적하고 오류나 보안 관련 이벤트(예: 실패한 로그인 시도 또는 시스템 변경)를 감지
  • 네트워크 활동: 네트워크 트래픽을 모니터링하여 네트워크 공격이나 손상을 나타낼 수 있는 비정상적이거나 승인되지 않은 활동을 식별
  • 애플리케이션 활동 및 성능: 공격이 애플리케이션 수준에서 발생하는 경우 애플리케이션 활동을 모니터링하여 오작동을 감지
  • 리소스 활용도: CPU, 메모리, 디스크 공간 등의 시스템 리소스 사용을 모니터링하여 병목 현상이나 기타 성능 문제를 식별
  • 보안 구성: 방화벽 규칙, 사용자 액세스 제어 등의 보안 구성을 모니터링하여 올바르게 구성되고 시행되는지 확인
  • 백업 및 재해 복구 시스템: 백업 및 재해 복구 시스템을 모니터링하여 올바르게 작동하는지, 장애나 재해 발생 시 데이터를 복구할 수 있는지 확인

Control plane monitoring

k8s -> audit logs라는 event auditing infra 있음

k8s API 서버에 기록할 내용을 알려주는 Audit Policy라고 부르는 configuration이 있음.

stdout예제에서는 Minikube를 사용하고 있으며 이를 테스트하기 위해 감사 로그를 API 서버(로그) 로 보냄

 

kubectl logs kube-apiserver-minikube -n kube-system | grep audit.k8s.io/v1

이걸로 로그 따라갈 수 있고, 모든 API 작업은 stream에 기록됨.

 

{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"RequestResponse","auditID":"8e526e77-1fd9-43c3-9714-367fde233c99","stage":"RequestReceived","requestURI":"/api/v1/namespaces/default/secrets?limit=500","verb":"list","user":{"username":"minikube-user","groups":["system:masters","system:authenticated"]},"sourceIPs":["192.168.49.1"],"userAgent":"kubectl/v1.25.4 (linux/amd64) kubernetes/872a965","objectRef":{"resource":"secrets","namespace":"default","apiVersion":"v1"},"requestReceivedTimestamp":"2023-02-11T20:34:11.015389Z","stageTimestamp":"2023-02-11T20:34:11.015389Z"}

이런식으로 누가, 무엇을, 언제 등의 인프라 요청의 사항들이 기록됨.

 

Resource Monitoring

 

k8s 모니터링 보통 많이 쓰는 거 : Prometheus(로깅 및 이벤트 데이터베이스) 및 Grafana(UI 및 대시보드)

기본적으로 리소스 모니터링 k8s 노드가 제공됨.

 

minikube에 helm을 통해 설치하기

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add grafana https://grafana.github.io/helm-charts
helm install prometheus prometheus-community/prometheus
helm install grafana grafana/grafana
kubectl expose service grafana --type=NodePort --target-port=3000 --name=grafana-np

난 여기서 kubectl로 minikube 실행할 때 에러가 났는데 

 

1. virtualbox uninstall하고 reinstall

2. minikube delete 하고 다시 start

3. hyperkit설치해서 driver를 지정해서 실행

minikube start --driver=hyperkit

 이런 식으로.. 했더니

😄  Darwin 12.6 의 minikube v1.32.0
✨  기존 프로필에 기반하여 virtualbox 드라이버를 사용하는 중
👍  minikube 클러스터의 minikube 컨트롤 플레인 노드를 시작하는 중
🤷  virtualbox "minikube" VM is missing, will recreate.
🔥  virtualbox VM (CPUs=2, Memory=6000MB, Disk=20000MB) 를 생성하는 중 ...
🤦  StartHost failed, but will try again: recreate: creating host: create: creating: Error setting up host only network on machine start: The host-only adapter we just created is not visible. This is a well known VirtualBox bug. You might want to uninstall it and reinstall at least version 5.0.12 that is is supposed to fix this issue
🔄  Restarting existing virtualbox VM for "minikube" ...
😿  Failed to start virtualbox VM. Running "minikube delete" may fix it: driver start: Error setting up host only network on machine start: The host-only adapter we just created is not visible. This is a well known VirtualBox bug. You might want to uninstall it and reinstall at least version 5.0.12 that is is supposed to fix this issue

❌  Exiting due to IF_VBOX_NOT_VISIBLE: Failed to start host: driver start: Error setting up host only network on machine start: The host-only adapter we just created is not visible. This is a well known VirtualBox bug. You might want to uninstall it and reinstall at least version 5.0.12 that is is supposed to fix this issue
💡  권장: Reboot to complete VirtualBox installation, verify that VirtualBox is not blocked by your system, and/or use another hypervisor
📘  문서: https://stackoverflow.com/questions/52277019/how-to-fix-vm-issue-with-minikube-start
🍿  관련 이슈들:
    ▪ https://github.com/kubernetes/minikube/issues/3614
    ▪ https://github.com/kubernetes/minikube/issues/4222
    ▪ https://github.com/kubernetes/minikube/issues/5817

이 에러가 없어지고 처음부터 했을 때 잘 실행되었다.

 

Prometheus와 Grafana를 사용하여 Minikube 클러스터 구축

<Grafana Dashboard로 확인하기>

kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo
minikube service grafana-np --url

 

위 명령어로 비밀번호 받고, 아래 명령어로 url 받으면 

grafana에 접속할 수 있다.

id는 admin으로 접속하면 됨.

Data sources/Prometheus add하고

Url에 http://prometheus-server

추가하고 save&test

 

그리고 dashboards가서 import해준다음에

number 넣는 곳에 6126 넣어주고 import 해주면

 

이런 화면을 볼 수 있다~~

 

 

 

Day 29

<application logging>

 

loki 활용 해보기

 

Loki란?

Kubernetes 클러스터에서 실행되는 Pod용 Promtail을 사용하여 로그를 수집하고 Prometheus가 메트릭을 위해 저장하는 것처럼 로그를 저장하는 Grafana 스택의 구성 요소

+ 

더보기

Loki 데이터 소스는 Grafana Labs에서 개발한 오픈 소스 로그 집계 시스템인 Loki를 지원하는 Grafana의 내장 기능

 Loki 데이터 소스를 추가할 수 있는 권한은 조직 관리자 역할을 가진 사용자에게만 부여됩니다.

관리자는 Grafana의 프로비저닝 시스템을 사용하여 데이터 소스를 YAML로 구성할 수도 있습니다.

Loki 데이터 소스를 추가한 후에는 Grafana 인스턴스의 사용자가 대시보드를 작성하거나 Explore를 사용할 때 쿼리 편집기에서 쿼리를 생성할 수 있도록 데이터 소스를 구성할 수 있습니다.

Loki 데이터 소스의 쿼리 편집기는 Loki의 쿼리 언어인 LogQL을 사용하여 로그 및 메트릭 쿼리를 생성하는 데 도움을 줍니다.

자세한 내용은 쿼리 편집기 문서를 참조하십시오.

템플릿 변수를 사용하여 메트릭에서 서버, 애플리케이션 및 센서 이름과 같은 세부 정보를 하드 코딩하는 대신에 사용할 수 있습니다.

 

Promtail과 함께 있어야 해서 

클러스터에 Promtail과 함께 Loki를 설치하려면 다음 Helm 차트를 설치

helm install loki --namespace=monitoring grafana/loki-stack

 

Minikube에 Promtail과 Loki 인스턴스가 배치되고 로그 수집이 시작

kubectl get pods | grep loki
loki-0                                              1/1     Running   0             8m35s
loki-promtail-lfc64                                 1/1     Running   0             8m35s

get pods loki해보면 이렇게 두 개가 실행되고 있는 걸 확인가능

 

day28처럼 url로 이동한 다음,

data sources에서 loki데이터 소스 추가하기.

 

변경해야할 게 loki의 endpoint인데, http://loki:3100을 넣어주면 된다.

그러나~~

나는 계속 unable 이 떠서 이런저런 에러 해결 방법을 찾아보았다.

 

 

에러 해결 및 다른 실습 방안 참고자료이다...

 

잘 된다면

이렇게 로깅 시스템을 확인할 수 있다.

 

 

이번엔 Falco

 

Monitoring application은 eBPF (extended Berkeley Packet Filter) 라는 걸 사용하는데, 

Falco는 k8s 노드에 에이전트를 설치하고 eBPF 수준에서 애플리케이션을 모니터링하는 프로젝트다. 

 

minikube에 falco를 설치하고, 수집한 데이터를 prometheus(grafana)로 전달.

 

falcoctl 우선 설치 

https://github.com/falcosecurity/falcoctl#installation

 

나는 인텔 맥이라서 이렇게 다운받아줌

 

falco pod이 실행되는 걸 기다리고...  (아직 만들어지는 중)

근데 여기서 

" Prometheus는 내보내기를 자동으로 감지하고 Prometheus 데이터 소스를 이미 추가했으므로 Grafana로 직접 이동하여 Falco 대시보드를 설치할 수 있습니다 . "

라고 해서 대시보드에서 id에 11914하고 로드를 하면 falco이벤트를 grafana에서 볼 수 있다고 했지만.

no data로 뜬다... ㅎㅎ

 

 

Day 30 

< 런타임 감지 > 

 

이 녀석도 마찬가지로 falco를 활용하는 것인데, 

 

Falco = Kubernetes 런타임 보안을 위해 설계된 강력한 오픈 소스 도구

  • Falco가 Kubernetes 환경 보안을 위한 좋은 선택인 몇 가지 이유
    • Falco는 Kubernetes 환경의 보안 위협과 잠재적인 취약점을 실시간으로 감지
    • 규칙 기반 엔진을 사용하여 의심스러운 활동을 감지하고 경고하므로 보안 사고에 신속하게 대응할 수 있음

 

nginx 배포 설치하고, nginx pod 내부에서 셀을 열고, apt 이용해서 pod에 curl을 설치해준다.

kubectl create deployment nginx --image=nginx:1.19
kubectl exec -it `kubectl get pod | grep nginx | awk '{print $1}'` -- bash
$ apt update && apt install -y curl

 

 

그런 다음 Falco를 사용하여 애플리케이션 동작을 모니터링하고 있으므로 grafana로 돌아가서 prometheus 데이터 소스를 사용하고 있는 대쉬보드를 들어가서...

 

쿼리 빌더에서

이렇게 설정을 해주었는데... 

뒤에 nginx deploment 숫자는 내 nginx pod 이름으로 설정해주면 된다.

 

 

그런데~~

이벤트가 표시되지 않는다.

 

yaml파일 만들어서 지정도 해주고 helm 통하는 게 잘못된건가 싶어서 addons도 켜주고

pvc랑 storageclass문제?? 로 나오길래 얘네도 만들어서 지정해줬는데,

근데 이건 아닌 듯 하다. ebs랑 연결하는 레퍼런스였던 듯... -.- 

 

 

어디서부터 잘못된 걸까나...^)^

 

 

Day 31

< Network Security in runtime >

 

[ 런타임시 네트워크 보안 ]

 

- k8s 네트워크 아키텍처

  • Kubernetes는 복잡한 네트워크 아키텍처를 사용하여 Pods와 서비스 간의 네트워크 트래픽을 관리합니다.
  • 높은 수준에서 Kubernetes 네트워크는 클러스터 전체 Pod 네트워크와 서비스 네트워크로 구성됩니다. 
  • Pod 네트워크를 통해 Pod는 서로 통신할 수 있고, 서비스 네트워크는 Pod 집합에 안정적인 IP 주소와 DNS 이름을 제공합니다
  • Kubernetes는 외부 트래픽을 클러스터로 라우팅하는 데 사용되는 Ingress도 지원합니다. 
  • Ingress는 일반적으로 TLS 암호화 및 클라이언트 인증을 사용하여 보호됩니다.

 

- network policies

  • Kubernetes 네트워크 정책을 사용하면 pod와 서비스 간의 네트워크 트래픽을 제어할 수 있습니다.
  • 네트워크 정책을 사용하면 클러스터의 공격 표면을 제한할 수 있습니다.

 

 

- container networking 

  • 컨테이너는 기본적으로 서로 격리되어 있지만 여전히 네트워크를 통해 통신할 수 있습니다.
  • 컨테이너 네트워킹은 특히 Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼을 사용할 때 복잡할 수 있습니다.
  • 컨테이너 네트워킹을 보호하려면 컨테이너 네트워킹의 작동 방식을 이해하는 것이 중요합니다.
  • Kubernetes는 다양한 네트워킹 플러그인을 사용하여 Calico, Weave Net 및 Flannel과 같은 Pod 간의 통신을 활성화합니다

 

- service mesh security 

  • Istio 및 Linkerd와 같은 서비스 메시는 Kubernetes 환경에서 점점 더 대중화되고 있습니다.
  • 서비스 메시는 로드 밸런싱, 트래픽 조절, 회로 차단과 같은 고급 트래픽 관리 기능을 제공합니다.
  • 또한 상호 TLS 인증, RBAC, 트래픽 관리와 같은 보안 기능도 제공합니다. 

 

- network monitoring and logging

  • Falco는 Kubernetes에서 의심스러운 동작을 탐지하는 데 사용할 수 있는 런타임 보안 도구이고,
  • Prometheus와 Grafana는 모니터링 및 경고에 사용할 수 있습니다.

 

- zero trust networking 

  • 제로 트러스트 네트워킹은 모든 네트워크 트래픽을 신뢰할 수 없다고 가정하고 모든 연결에 대해 인증 및 권한 부여가 필요한 보안 모델입니다.
  • 상호 TLS 인증 및 RBAC 기능을 제공하는 Istio와 같은 도구를 사용하여 Kubernetes에서 제로 트러스트 네트워킹을 구현할 수 있습니다

 

[ k8s 기본 네트워크 정책 ]

 

  • Kubernetes 기본 네트워크 정책은 네트워크 세분화를 적용하고 Kubernetes 클러스터의 Pod 간 통신을 제어하기 위한 메커니즘입니다. 
  • 네트워크 정책을 통해 관리자는 라벨을 기반으로 서로 통신할 수 있는 pod를 지정하는 규칙을 정의할 수 있습니다.
  • 네트워크 정책은 라벨을 사용하여 Pod를 선택하고 Pod 간의 트래픽을 허용하거나 거부하는 규칙을 정의합니다. 
  • Label은 pod 자체 또는 관련 서비스에 적용될 수 있습니다. 
  • 기본적으로 Kubernetes는 Pod 간에 들어오고 나가는 모든 네트워크 트래픽을 거부하며, 네트워크 정책을 통해 관리자는 특정 Pod 또는 Pod 그룹 간의 통신을 선택적으로 열 수 있습니다.
  • 네트워크 보안의 맥락에서 수신 및 송신 정책은 네트워크 또는 특정 네트워크 세그먼트에 들어오고 나가는 트래픽을 제어하는 ​​데 사용됩니다. 

ingress, egress segment를 조정해서 network polices를 조정할 수 있고, policies를 만들수도 있음. 

 

 

[ Network monitoring in k8s ]

 

; network traffic을 monitor하는데 쓸 수 있는 유명한 도구들

 

Cilium

- Runtime > Cloud Native Network 

- Kubernetes용 강력한 네트워킹 및 보안 솔루션

- Cilium은 컨테이너 및 pod 수준에서 네트워크 트래픽을 모니터링하고 pod와 서비스 간의 트래픽 흐름에 대한 자세한 통찰력을 제공

- Cilium은 또한 네트워크 정책을 제공하고 eBPF 기술을 사용하여 커널 수준에서 이를 시행할 수 있음

 

Istio 

- Orchestration & Management > Service mesh 

- k8s 용 서비스 메시

- Istio에는 Kubernetes 서비스 간의 네트워크 트래픽을 캡처 및 모니터링할 수 있고 분산 추적 및 메트릭과 같은 풍부한 관찰 기능을 제공하는 Envoy라는 강력한 사이드카 프록시가 포함

 

Calico

- Runtime > Cloud Native Network 

- Kubernetes용 네트워킹 및 보안 솔루션

- Calico에는 팟(Pod) 및 네임스페이스 수준에서 정책을 정의 및 시행할 수 있게 하고 네트워크 트래픽 흐름에 대한 자세한 통찰력을 제공하는 강력한 네트워크 정책 엔진이 포함

 

Weave Scope

- Observability 

- Kubernetes 모니터링 및 시각화 도구

- Kubernetes 서비스와 Pod 간의 트래픽 흐름을 시각화하고 Kubernetes 인프라에 대한 풍부한 통찰력을 제공하는 네트워크 트래픽 보기가 포함

 

 

 

 

+ helm과 k8s의 관계?

더보기

Helm은 Kubernetes 애플리케이션의 패키지 매니저입니다. Helm을 사용하면 Kubernetes 애플리케이션을 패키지로 묶고, 배포, 관리 및 업그레이드할 수 있습니다. Helm은 Kubernetes 자원(예: 배포, 서비스, PVC 등)을 쉽게 관리할 수 있도록 돕는 도구입니다.

Helm은 다음과 같은 주요 구성 요소로 구성됩니다:

1. **Charts**: Helm 패키지의 기본 단위입니다. 각 차트는 Kubernetes 애플리케이션을 설명하는 파일과 템플릿을 포함합니다. 이 템플릿은 Kubernetes 자원을 생성하는 데 사용됩니다.

2. **Repository**: Helm 차트를 저장하는 곳입니다. 공식 Helm 차트 저장소 외에도 사용자 정의 저장소를 만들어 사용할 수 있습니다.

3. **Client**: Helm 명령줄 도구로, 차트를 검색, 설치, 관리 및 업그레이드하는 데 사용됩니다.

Helm은 다음과 같은 사용 사례를 포함하여 Kubernetes에서 애플리케이션을 관리하는 데 매우 유용합니다:

- 애플리케이션 배포의 자동화
- 다중 환경에서의 일관된 애플리케이션 배포
- 애플리케이션의 버전 관리 및 롤백
- 애플리케이션 구성의 관리 및 템플릿화

요약하면, Helm은 Kubernetes 애플리케이션을 패키지화하고 배포하기 위한 강력한 도구이며, Kubernetes 클러스터에서 애플리케이션 관리를 단순화하는 데 도움이 됩니다.

 

 

+ eBPF 기술이란?

더보기

eBPF(Extended Berkeley Packet Filter)는 리눅스 커널 내부에서 실행되는 프로그램을 작성하고 실행할 수 있는 가상 머신이며, 최초로 리눅스 커널 3.15에서 소개되었습니다. eBPF는 네트워크, 보안, 디버깅, 성능 모니터링 등 다양한 영역에서 널리 사용되고 있습니다.

eBPF의 주요 특징과 사용 사례는 다음과 같습니다:

1. **프로그래밍 가능한 네트워크**: eBPF는 네트워크 데이터를 실시간으로 처리하고 수정하는 데 사용됩니다. 이를 통해 네트워크 패킷을 필터링하거나 수정하고, 사용자 정의 네트워크 기능을 구현할 수 있습니다.

2. **성능 모니터링 및 디버깅**: eBPF는 리눅스 시스템 내부에서 발생하는 이벤트를 캡처하고 분석하는 데 사용됩니다. 이를 통해 시스템의 성능을 모니터링하고 디버깅하는 데 도움이 됩니다.

3. **보안**: eBPF는 시스템 내부의 보안 이벤트를 캡처하고 분석하여 보안 이슈를 탐지하는 데 사용됩니다. 예를 들어, 악성 코드나 해킹 시도를 감지하고 차단하는 데 활용될 수 있습니다.

4. **커널 내부 기능 확장**: eBPF는 리눅스 커널 내부의 다양한 기능을 확장하는 데 사용됩니다. 이를 통해 사용자 정의 커널 기능을 동적으로 로드하고 실행할 수 있습니다.

eBPF는 C, Go, Rust 등 다양한 언어로 프로그래밍할 수 있으며, 현재는 리눅스 커널의 핵심 기능 중 하나로 자리 잡고 있습니다. 네트워크 및 시스템 관리자, 보안 전문가, 성능 엔지니어 등 다양한 업무 분야에서 활용되고 있으며, 더 많은 기능과 새로운 사용 사례가 지속적으로 개발되고 있습니다.

 

저작자표시 비영리 변경금지

'클라우드 > DevOps' 카테고리의 다른 글

[90DaysOfDevOps] Day 53~55 - AWS + AWS app mesh  (0) 2024.03.26
[90DayOfDevOps] Day 32~34 - Runtime Defence & Monitoring  (1) 2024.03.26
[IaC] Terraform  (0) 2024.03.19
[Red Hat OpenShift] 개념, ROSA Hands-on : cluster 구성 및 autoscale, labeling  (5) 2024.03.19
[90DaysOfDevOps] Day 53 - Kubernetes  (0) 2024.03.12

'클라우드/DevOps'의 다른글

  • 현재글[90DayOfDevOps] Day 28~31 - Runtime Defence & Monitoring

관련글

티스토리툴바