티스토리 뷰
starboard 란?
Aquasecurity 사에서 개발해 opensource로 제공하는 Kubernetes-native security tool kit 이다.
실제 Kubernetes 환경에서 동작되는 모든 서비스(kubernete 자신을 포함)에 대한 취약점 분석을 진행하고 Report를 생성한다.
뜻을 알면 이해에 도움이 될거라 생각해서 찾아보았지만 정확한 의미가 나와있지는 않았다.
starboard란?
배의 좌우측면을 현측이라 하는데 여기서 우현을 의미한다.
예상하기로는 기존 측면(좌측)이 아닌 다른 측면(우측, 보안적인)에서 바라보는 개념이지 않을까 한다.
Aquasecurity에서 제공하는 CRD인 다음 항목에 대한 기능을 kubenretes 환경에서 제공한다.
취약점 분석 (trivy)
설정 검사 (polaris)
kubebench (kube-bench)
kubehunter (kube-hunter)
위 항목들은 원래 각각 다른 binary와 다른 기능으로 제공되는 것들이다.
starboard는 이를 통합해 Kubernetes 환경에서 사용할수 있도록 해준다.
원리는 각기 기능들이 달리 제공되던 tool들을 starboard에서는 하나의 interface를 통해 실행하고
실행된 결과를 위 항목에 맞는 CRD를 생성해서 report로 저장시키는 역할을 한다고 보면 된다.
how to use
우선 starboard cli를 이용해 취약점 분석 및 kube-hunter, configaudit등을 어떻게 찾아내고 report로 생성하는지 알아보도록 하자.
installation
설치는 간단하다
아래 github의 release 페이지에서 OS에 맞는 tar.gz 파일을 다운로드 받고 압축해제후 등록된 path로 이동시켜주면 끝.
github.com/aquasecurity/starboard/releases
curl -L https://github.com/aquasecurity/starboard/releases/download/v0.4.0/starboard_linux_x86_64.tar.gz | tar xvz
sudo mv starboard /usr/local/bin
usage
초기화를 통한 사용준비
아래 초기화 작업을 수행하면 현재 context에 맞는 cluster에 몇가지 aquasecurity apigroup을 가지는 CRD가 생성된다.
jacob@jacob-laptop:~$ starboard init
jacob@jacob-laptop:~$ kubectl api-resources --api-group aquasecurity.github.io
NAME SHORTNAMES APIGROUP NAMESPACED KIND
ciskubebenchreports kubebench aquasecurity.github.io false CISKubeBenchReport
configauditreports configaudit aquasecurity.github.io true ConfigAuditReport
kubehunterreports kubehunter aquasecurity.github.io false KubeHunterReport
vulnerabilityreports vulns,vuln aquasecurity.github.io true VulnerabilityReport
위 4가지 사항은 위에 설명한 취약점분석보고 부터 kube-hunter보고까지를 의미한다.
starboard를 설치한후 아래와 같은 명령을 통해 취약점을 찾는다.
starboard 사용법은 다음과 같다.
jacob@jacob-laptop:~$ starboard --help
Kubernetes-native security toolkit
Usage:
starboard [command]
Available Commands:
cleanup Delete custom resource definitions created by starboard
find Manage security scanners
get Get security reports
help Help about any command
init Create custom resource definitions used by starboard
kube-bench Run the CIS Kubernetes Benchmark https://www.cisecurity.org/benchmark/kubernetes
kube-hunter Hunt for security weaknesses
polaris Run a variety of checks to ensure that Kubernetes pods and controllers are configured using best practices
version Print the version information
분석과정
취약점분석 과정은 다음과 같은 순서로 진행한다.
- (starboard) find vulnerabilities
- (starboard) get vulnerabilities or (kubectl) get vulnerabilityreport
취약점 분석 외에 configaudit, kube-bench, kube-hunter 모두 분석을 위한 명령어를 처음 수행한후
결과는 별도의 명령을 통해 얻을수 있다. 즉 취약점 분석과 유사한 과정을 거친다.
취약점 분석 (CRD: vulnerabilityreports)
먼저 이해를 위한 sample deployment인 nginx-deployment를 배포하고 이를 통해 starboard의 사용법을 알아보자.
jacob@jacob-laptop:~$ kubectl get deploy/nginx-deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 2/2 2 2 59s
참고로 취약점분석은 trivy를 사용하여 진행한다.
(trivy의 경우 mr100do.tistory.com/1029 를 참고하거나 실제 trivy github page(github.com/aquasecurity/trivy)를 참고)
jacob@jacob-laptop:~$ starboard find vulnerabilities deploy/nginx-deployment
취약점 검색이 끝난후 아래 명령어로 yaml 형태의 report를 생성할수 있다.
jacob@jacob-laptop:~$ starboard get vulnerabilities deploy/nginx-deployment
apiVersion: v1
items:
- apiVersion: aquasecurity.github.io/v1alpha1
kind: VulnerabilityReport
metadata:
creationTimestamp: "2020-10-06T05:04:10Z"
generation: 1
labels:
starboard.container.name: nginx
starboard.resource.kind: Deployment
starboard.resource.name: nginx-deployment
starboard.resource.namespace: jx
managedFields:
- apiVersion: aquasecurity.github.io/v1alpha1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:starboard.container.name: {}
f:starboard.resource.kind: {}
f:starboard.resource.name: {}
f:starboard.resource.namespace: {}
f:ownerReferences:
.: {}
k:{"uid":"dd6ae1fa-6d4d-4fe3-8784-d5fdc797507a"}:
.: {}
...
trivy 기반으로 scanning을 한 후 그에 따른 결과를 원하는 형태(json, yaml)로 출력하여 확인하고 취약점에 대한 대처를 수행할 수 있다. 또한 아래 명령을 통해 html report로도 생성할 수 있다.
jacob@jacob-laptop:~$ starboard get report deploy/nginx-deployment > /tmp/nginx-deploy.html
browser를 통해 해당 파일을 접근해보면 아래와 같은 report 가 출력된다.
어떤 CVE 항목에 취약점을 가지고 있는지를 좀더 비쥬얼하게 보여준다.
configaudit (CRD: configauditreports)
starboard polaris를 이용하여 report를 생성할수 있다.
우선 간단히 fairwinds polaris에 대해 알아보면 kubernetes deployment 설정에러를 식별하는 opensource 프로젝트이다.
먼저 아래 명령을 통해 configaudit을 수행할수 있다. 대상은 앞선 nginx-deployment가 아닌 wordpress로 배포된 lamp deployment로 지정하였다. 이유는 기존 nginx-deployment는 configmap 및 secret이 존재하지 않아서 이다.
아래와 같이 configauditreport 생성을 진행하자.
jacob@jacob-laptop:~$ starboard polaris deploy/lamp-1601965082-lamp -n default
진행된 configaudit에 대해 다음과 같은 명령으로 결과를 확인할 수 있다.
jacob@jacob-laptop:~$ starboard get configaudit deploy/lamp-1601965082-lamp -n default
apiVersion: v1
items:
- apiVersion: aquasecurity.github.io/v1alpha1
kind: ConfigAuditReport
metadata:
creationTimestamp: "2020-10-06T06:20:17Z"
generation: 1
labels:
starboard.resource.kind: Deployment
starboard.resource.name: lamp-1601965082-lamp
starboard.resource.namespace: default
managedFields:
- apiVersion: aquasecurity.github.io/v1alpha1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:starboard.resource.kind: {}
f:starboard.resource.name: {}
f:starboard.resource.namespace: {}
앞서 생성했던 configaudit report가 앞서 생성했던 CRD type으로 존재함을 확인할수 있다.
jacob@jacob-laptop:~$ kubectl get configauditreport
NAME AGE
deployment.nginx-deployment 2m25s
configaudit 또한 html로 결과를 출력할수 있다.
jacob@jacob-laptop:~$ starboard get report deploy/lamp-1601965082-lamp -n default > /tmp/configaudit.html
앞선 취약점 분석 과정과 동일하게 browser를 통해 파일을 open해보면
참고
kube-hunter (CRD: kubehunterreports)
kubernetes 외부에서 kubernetes에 open 된 port 와 관련된 주소 및 도메인에 대한 probing을 수행한다.
즉, kubernetes 가 제공하는 API, 외부에 expose된 port, etcd service, dashboard 등 다양한 서비스에 대한 취약점 분석을 진행한다.
jacob@jacob-laptop:~$ starboard kube-hunter
kube-hunter에 의해 생성된 리포트는 kubectl 명령을 통해 확인할수 있다.
역시나 앞서 생성되었던 CRD를 기반으로 report 가 생성되었다.
jacob@jacob-laptop:~$ kubectl get kubehunterreport
NAME AGE
cluster 3m30s
별도의 명령어가 현시점에는 제공되고 있지 않다. 하여 아래 kubectl 명령을 통해 결과를 뽑아내야한다.
jacob@jacob-laptop:~$ kubectl get kubehunterreport -o json | jq -r '.items[].report'
{
"scanner": {
"name": "kube-hunter",
"vendor": "Aqua Security",
"version": "0.3.1"
},
"vulnerabilities": [
{
"category": "Access Risk",
"description": "CAP_NET_RAW is enabled by default for pods.\n If an attacker manages to compromise a pod,\n they could potentially take advantage of this capability to perform network\n attacks on other pods running on the same node",
"evidence": "",
"hunter": "Pod Capabilities Hunter",
"location": "Local to Pod (bcab2395-ffa1-49c6-b2bf-5e9b0db484aa-47l6n)",
"severity": "low",
"vid": "None",
"vulnerability": "CAP_NET_RAW Enabled"
},
{
"category": "Information Disclosure",
"description": "The kubernetes version could be obtained from the /version endpoint ",
"evidence": "v1.18.3",
"hunter": "Api Version Hunter",
"location": "10.96.0.1:443",
"severity": "medium",
"vid": "KHV002",
"vulnerability": "K8s Version Disclosure"
}
]
}
kube-bench (CRD: ciskubebenchreports)
우선 kube-bench에 대하여 알아보자면, CIS kubernetes benchmark 내에 정의된 항목들을 체크하여 안전하게 kubernetes가 배포되었는지 확인하는 Golang으로 만들어진 application이다.
jacob@jacob-laptop:~$ starboard kube-bench
jacob@jacob-laptop:~$ kubectl get ciskubebenchreport
NAME SCANNER AGE
minikube kube-bench 60s
앞선 kube-hunter와 동일하게 starboard의 경우 별도의 get option을 제공하고 있지 않아 jq command를 이용하여 report 항목만 출력시킬수 있다.
jacob@jacob-laptop:~$ kubectl get ciskubebenchreport -o json | jq -r '.items[].report'
{
"scanner": {
"name": "kube-bench",
"vendor": "Aqua Security",
"version": "0.3.1"
},
"sections": [
{
"id": "1",
"node_type": "master",
"tests": [
{
"desc": "Master Node Configuration Files",
"fail": 2,
"info": 0,
"pass": 14,
"results": [
...
참고
kube-bench는 managed kubernetes(public cloud 에서 제공하는 EKS, AKS, GKE와 같은)에서는 master node에 접근이 불가능하기에 해당 환경에서는 사용이 제한적이다.
Octant를 사용한 starboard
사실 command 기반의 report는 보기가 불편하다. 또한 kube-hunter 및 kube-bench의 경우 명령으로도 제공이 안되어 불편한 점이 있다. 이를 octant라는 개발자용 kubernete UI를 사용하여 좀더 편리하게 report로 보고 확인할수 있도록 해보자.
아래 사용은 Octant가 이미 설치되어 있다는 가정하에 아래와 같은 plugin 설치 및 사용을 진행한다.
octant-starboard plugin 설치
다음과 같은 명령을 통해 binary를 다운로드 받고
curl -L https://github.com/aquasecurity/starboard-octant-plugin/releases/download/v0.4.0/starboard-octant-plugin_linux_x86_64.tar.gz | tar xvz
mv starboard-octant-plugin ~/.config/octant/plugins/
octant를 실행한다.
octant
자동으로 browser가 실행되면서 localhost:7777로 접속이 된다.
취약점 분석 결과 확인
해당 정보는 앞서 starboard command를 수행한 결과를 기반으로 한다.
만약 octant로 접속된 환경에서 starboard를 통한 report 생성과정을 선행하지 못한 경우 아래 명령을 수행해주어야 한다.
jacob@jacob-laptop:~$ starboard find vulnerabilities deploy/nginx-deployment
관련 pod 및 deployment resource로 이동해보면 Vulnerabilites 라는 메뉴가 추가되어 있고 분석결과를 확인할수 있다.
Config Audit Report
앞서 설명한데로 fairwinds polaris 를 기반으로 configuration에 대한 설정오류를 분석해주는 도구이다.
역시나 해당 정보는 앞서 starboard command를 수행한 결과를 기반으로 한다.
만약 octant로 접속된 환경에서 starboard를 통한 report 생성과정을 선행하지 못한 경우 아래 명령을 수행해주어야 한다.
jacob@jacob-laptop:~$ starboard polaris deploy/nginx-deployment
위와 같이 deployment의 summary에 보면 config audit reports 가 존재한다. (물론 pod도 가능하다.)
현재는 starboard polaris 명령을 수행하지 않아 결과 report를 확인할수 없기 때문에 아래 명령어를 수행하고
jacob@jacob-laptop:~$ starboard polaris deploy/tomcat
다시 octant로 이동해보면 다음과 같은 결과를 확인할 수 있다.
kube-hunter
kube-hunter는 앞서 소개한데로 kubernetes 내부가 아닌 외부에서 kubernetes 시스템 및 서비스에 대한 scanning 부터 다양한 probing을 수행하여 취약점을 발견하는 작업을 수행한다. 아래 링크에 다양한 기능들에 대한 예시가 있으니 참고하면 좋을것 같다.
역시나 해당 정보는 앞서 starboard command를 수행한 결과를 기반으로 한다.
만약 octant로 접속된 환경에서 starboard를 통한 report 생성과정을 선행하지 못한 경우 아래 명령을 수행해주어야 한다.
jacob@jacob-laptop:~$ starboard kube-hunter
위는 octant에서 kube hunter report를 기반으로 출력한 정보이다.
참고
현재 starboard operator가 개발되어지고 있고 현시점(2020.10)에는 alpha version 상태이다.
그래서인지 결과를 UI를 통해 손쉽게 확인할수는 있지만 분석을 진행하는것은 아직 CLI로 진행해야 한다.
kube-bench
역시나 해당 정보는 앞서 starboard command를 수행한 결과를 기반으로 한다.
만약 octant로 접속된 환경에서 starboard를 통한 report 생성과정을 선행하지 못한 경우 아래 명령을 수행해주어야 한다.
jacob@jacob-laptop:~$ starboard kube-bench
이후 node에 가보면 CIS Kubernetes Benchmark 메뉴가 보인다. 해당 메뉴를 통해 앞서 kube-bench 실행에 대한 결과 report를 확인해볼수 있다.
헌데 아쉬운 점이 cli 상에서 확인해본 결과 remediation 정보가 같이 출력되었는데
"results": [
{
"remediation": "Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml\non the master node and set the --terminated-pod-gc-threshold to an appropriate threshold,\nfor example:\n--terminated-pod-gc-threshold=10\n",
"scored": true,
"status": "FAIL",
"test_desc": "Ensure that the --terminated-pod-gc-threshold argument is set as appropriate (Scored)",
"test_number": "1.3.1"
},
{
"remediation": "Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml\non the master node and set the below parameter.\n--profiling=false\n",
"scored": true,
"status": "FAIL",
"test_desc": "Ensure that the --profiling argument is set to false (Scored)",
"test_number": "1.3.2"
},
Octant UI상에서는 Status,Number,Description외에는 출력되지 않았다.
결국 CICD pipeline 상에서 cli로 확인하고 이를 검증하는 process를 가지는것이 가장 바람직한 방식이 될듯하다.(개인의견)
starboard usage
아래와 같은 사용처를 권장하고 있다.
개발팀을 위한 보안 도구 키트
엔터프라이즈 DevOps용 보안 도구 키트
보안 제품 개발을 위한 도구 키트
참고사이트
'Cloud > Cloud Native' 카테고리의 다른 글
How to use Hashicorp Waypoint (0) | 2020.10.27 |
---|---|
Metallb on Minikube (0) | 2020.10.27 |
Octant (0) | 2020.10.02 |
nginx ingress with namespace (0) | 2020.08.24 |
Make Helm chart repo (0) | 2020.07.23 |
- Total
- Today
- Yesterday
- minikube
- openstack backup
- openstacksdk
- kubernetes
- wsl2
- kata container
- macvlan
- K3S
- metallb
- minio
- DevSecOps
- boundary ssh
- ansible
- GateKeeper
- hashicorp boundary
- kubernetes install
- jenkins
- socket
- OpenStack
- ceph
- open policy agent
- mattermost
- Helm Chart
- azure policy
- aquasecurity
- crashloopbackoff
- vmware openstack
- nginx-ingress
- Terraform
- Jenkinsfile
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |