DEV Community: Theerapong

Install Kubernetes 1 master (self-hosted kubernetes)

Theerapong — Mon, 21 Feb 2022 07:59:19 +0000

Ubuntu 18.04 &&& K8s 1.22.6 &&& Docker 19.03

จะได้ K8s v1.20.14

# the following commands for both Master & Workers

{
sudo cat /sys/class/dmi/id/product_uuid
sudo ufw disable
sudo swapoff -a
sudo sed -i '/swap/d' /etc/fstab
}




{
sudo modprobe br_netfilter
lsmod | grep br_netfilter
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
}

{
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system
}







sudo kubeadm reset

sudo apt-get remove docker-ce docker-ce-cli containerd.io -y
sudo apt-get remove --purge docker-ce docker-ce-cli containerd.io -y

{
sudo apt-get update -y
sudo apt-get install ca-certificates curl gnupg lsb-release -y
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update -y
sudo apt-get install docker-ce=5:19.03.15~3-0~ubuntu-bionic docker-ce-cli=5:19.03.15~3-0~ubuntu-bionic containerd.io -y
# sudo apt-get install docker-ce docker-ce-cli containerd.io -y
sudo usermod -aG docker $USER
newgrp docker
docker ps
}



{
sudo mkdir /etc/docker
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF
sudo systemctl enable docker
sudo systemctl daemon-reload
sudo systemctl restart docker
docker info | grep Cgroup
}



{
sudo apt-get update -y
sudo apt-get install -y apt-transport-https ca-certificates curl
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update -y
# sudo apt-get install -y kubeadm=1.19.16-00 kubelet=1.19.16-00 kubectl=1.19.16-00
sudo apt-get install -y kubeadm=1.22.7-00 kubelet=1.22.7-00 kubectl=1.22.7-00
sudo apt-mark hold kubelet kubeadm kubectl
}



# the following commands for only One Master

sudo kubeadm init --pod-network-cidr=192.168.0.0/16

# Then, copy the command from the result of the Master node to the Worker nodes. 

kubectl create -f https://docs.projectcalico.org/archive/v3.20/manifests/tigera-operator.yaml
kubectl create -f https://docs.projectcalico.org/archive/v3.20/manifests/custom-resources.yaml

watch kubectl get pods -n calico-system
kubectl get nodes -o wide




mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

[Thai] เกี่ยวกับ Chaos Engineering

Theerapong — Wed, 16 Feb 2022 06:55:32 +0000

คร่าวๆก็คือว่า

(จาก https://www.youtube.com/watch?v=rgfww8tLM0A )

Netflix เปลี่ยนจากวัฒนะธรรมที่ว่า ถ้าระบบ fail จะต้องทำอะไร
ไปเป็น เมื่อไหร่ระบบจะ fail

ทาง Netflix จึงสร้าง chaos platform ใว้ เพื่อหาว่า traffic เท่าไหร่จะกระทบระบบ หรือ เมื่อไหร่ระบบจะ fails

คือจะมีการทดลองบน production ก่อนที่ลูกค้าจะเจอ issues

โดยใช้เครื่องมือชื่อว่า ChAP: Chaos Automation Platform (จะมี Chaos Monkey , และ อื่นๆ)

แล้ว chaos engineering ต่างจาก testing อย่างไร

ในหนังสือ Oreilly (มีทฤษฎีเยอะมาก) เขากล่าวว่า testing โดยพวก fault injection ก็จะได้แค่ผลลัพธ์แค่ผลลัพธ์เดียว

แต่าถ้าอยากที่จะหาว่ามีวิธีอะไรบ้างที่ complex system จะ fail ได้ ก็อาจใช้แนวทาง testing แบบ injecting communication failures เช่น latency และ errors (งง หาอ่านอีกทีครับ)

แต่ experiment ที่ทำกับ chaos engineering เราจะได้ knowledge ใหม่ (หรือความรู้ใหม่), information ใหม่ๆ และแนวทางใหม่ๆ

ในหนังสือบอกว่า chaos engineering คือรูปแบบของ experimentation ที่จะ gernerate ความรู้ใหม่ๆของระบบ (infra/cluster) ให้กับเรา , ซึ่งจะเรียกว่า testing ไม่ได้ !!

คอนเซ็ปหลักการทำ (ยังไม่ชัวร์)

สร้างสมมติฐาน (hypothesis) และสรุป เช่น ถ้าเราทำบางสิ่งบางอย่าง ระบบจะ fail
Vary Real World Events (แก้อีกที)
เพราะการทำ chaos นี้มันจะทำให้เกิดบางเหตุการณ์ real world event เช่น
ถ้าตัดการเชื่อมต่อระหว่าง server กับ internet ดังนั้น server ก็จะ down แน่นอน ,
เพิ่ม event ที่คาดไม่ถึง เพื่อให้รบกวน (disturb) ตัว system/application (Steady State)
รันบน production
ทำการ automate บ่อยๆ
ระบุผลกระทบ และหาวิธีลดผลกระทบที่จะเกิดขึ้น

เนื่องจาก run บน production , จะไม่ให้กระทบกับ users

🛠 เครื่องมือในการทำ Chaos Engineering ดังนี้

บางเครื่องมือเริ่มต้นจาก Netflix , บางอันอาจไม่ใช่
บางเครื่องมืออาจจะไม่ถูก support แล้ว (อาจต้องหาตัวอื่นแทน)

Chaos Monkey

จะ random เข้าไป kill ตัว services/micro-services แล้วดูว่าตัว server จะเป็นยังไง

มีสอง dependencies ที่ใช้ คือ MySQL และ Spinnaker (คือที่ Netflix ใช้)

MySQL ใช้ track ตัว termination, schedule
Spinnaker คือ continuous delivery platform

*** ถ้าใน GitLab ใช้ ChaosKube แทน (มันคือ Chaos Monkey นะครับ)

🛠 Chaos Gorilla

จะ kill ทั้ง Availability Zone

🛠 Chaos Kong

จะ kill ทั้ง region เลย

🛠 Latency Monkey

จะสร้าง delay ให้กับ requests

แล้วเราค่อยมาดูว่าจะเกิดอะไรขึ้นกับ cluster

🛠 Janitor Monkey

หาว่า resources อะไรที่ไม่ถูกใช้งาน
ถ้าไม่ใช้ก็ต้องลบทิ้ง

🛠 Security Monkey

หาว่ามีการตั้งค่าอะไรที่ไม่ถูกต้องบ้าง เช่น มีการคอนฟิก security group ที่ผิด , คอยดูว่า SSL certificates ยังมีความถูกต้อง (ไม่ใกล้หมดอายุ)

🛠 Facebook Storm

เกี่ยวกับปัญหาใดๆใน data center

🛠 Litmus Chaos

(จาก https://github.com/litmuschaos/litmus)

เป็น Chaos Engineering platform
ทำ chaos บน K8s on-premises ได้
ทำบน staging ก่อน แล้วค่อยไปทำบน production เพื่อหา bug หรือข่องโหว่ได้
มีหลายๆ experiments ให้ที่ https://hub.litmuschaos.io/

โปรแกรมนี้ ถ้ามองจาก high-level ก็จะประกอบด้วย

(1) Chaos Control Plane : เป็น management tool , ใช้ทำ workflows
(2) Chaos Execution Plane Services : เป็น agent ที่จะ execute & monitor การ experiment ใน K8s

Use cases ของ Litmus Chaos

สำหรับ Developers : ให้เป็น extension ของ unit testing หรือเป็นส่วนหนึ่งของ testing
สำหรับคนทำ CI/CD pipeline : ทำ stage ให้กับ Litmus นี้ เพื่อหาว่า pipeline มัน fail เพราะ bug อะไร
สำหรับ SREs : ใช้บอกจุดอ่อนของ system/infra ก็เพิ่มเพิ่มความทนทาน (resilience)

🛠 Gremlin

เป็น Software-as-a-Service หรือ Chaos-as-a-Service
จะโจมตี system , network เพื่อทดสอบความทนของ system
เราต้องกำหนดเองว่าการโจมตีไหนเหมาะกับเรา (เราต้องรับผิดชอบตัวเอง)
อาจต้องมีการติดตั้ง agent ใน server/container/pods ของเป้าหมาย

ตอนติดตั้ง

allow port 11371 สำหรับ gpg ด้วย
ถ้าใช้ port ของ gpg ไม่ได้ ให้เปลี่ยนไปใช้ port 80 แทน ดังนั้น คำสั่งในการติดตั้งคือ

# Install Gremlin
echo "deb https://deb.gremlin.com/ release non-free" | sudo tee /etc/apt/sources.list.d/gremlin.list

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 9CDB294B29A5B1E2E00C24C022E8EF3461A50EF6

sudo apt-get update && sudo apt-get install -y gremlin gremlind

# Register Gremlin client to its Control Plane
gremlin init

https://gremlin.com/

ตัวฟรีทำอะไรได้บ้าง

ใช้ได้ 1 team
ติดตั้งได้ 1 agent
2 Targets ต่อเดือน (แต่ละ target โจมตีได้ไม่จำกัด)

ตย scenario

💻 [เกี่ยวกับ Blackhole]

Unavailable Dependency: ถ้า dependency มัน unavailable จากนั้น users จะเจออะไร

Database Secondary Failover Time: เมื่อมีการ failover ที่ database ทดสอบว่าจะเร็วเท่าไหร่ที่ app จะเปลี่ยน connection จาก primary database ไปยัง secondary database

Kubernetes - Availability - Blackhole a Kubernetes node : จะเกิดอะไรขึ้นถ้า 1 node ของ K8s ไม่สามารถใช้งานได้

💻 [เกี่ยวกับ CPU]

Find Anomalous CPU Consumption : ทดสอบ CPU consumption บน host หรือ บน containers แบบ random จากนั้นเราก็จะเห็นว่าตัว monitor ของเราตรวจจับการใช้งาน CPU ได้อย่างถูกต้องหรือไม่

Monitoring & Alerting Verification : โปรแกรม Gremlin จะรัน CPU attack ให้กับ VM แล้วเราก็จะสามารถเห็น CPU มัน spike ขึ้นสูง

💻 [เกี่ยวกับ Disk]

Testing Kubernetes Storage Volume Limits : ทดสอบว่าขนาดพื้นที่ space ที่ pod ใช้ ยังไม่ถึง limit ที่กำหนดไว้ตรงคอนฟิก Deployment, นอกจากนี้เราก็จะเห็นว่าจะเป็นอย่างไรถ้ามี disk เต็ม (ตัว workload จะ handle อย่างไร , จะ crash หรือ data loss หรือไม่)

💻 [เกี่ยวกับ DNS]

Kubernetes - Availability - DNS outage : จะทดสอบให้ DNS ใช้งานไม่ได้, แล้วมาดูว่าตัว app ยังสามารถรับส่ง traffic ระหว่าง users ได้หรือไม่ , (K8s จะ handle อย่างไร ซึ่งถ้ามีการตั้งค่า DNS failover อย่างถูกต้อง ทาง users ก็ไม่ควรที่จะได้รับผลกระทบ)

💻 [เกี่ยวกับ IO]

💻 [เกี่ยวกับ Latency]

Unreliable Networks : เนื่องจาก microservice ต้องมีการเรียกใช้ API , จะกระทบกับ users อย่างไร ถ้าเรียก API ใช้เวลา 100 วินาที หรือ 1,000 วินาที

💻 [เกี่ยวกับ Memory]

Kubernetes - Validate Container Resilience Mechanism: OOMKiller - ปกติตัว Linux จะมีเครื่องมือจัดการ Memory ที่ชื่อว่า OOMKiller , การทดสอบนี้จะดูว่าจะเกิดอะไรขึ้นถ้ามีการใช้งาน Memory สูง , ตัว OOMKiller ของ Linux จะ work หรือไม่

ที่เห็น : Lens หลุด

Test Monitoring and Alerting for the Basics : จะทดสอบใช้งาน memory ให้สูงๆ แล้วเราก็ดูว่า เครื่องมือ monitoring ของเราสามารถตรวจจับการใช้งาน memory ได้อย่างถูกต้องหรือไม่

💻 [เกี่ยวกับ Package Loss]

💻 [เกี่ยวกับ Process Killer]

💻 [เกี่ยวกับ Shutdown]

💻 [เกี่ยวกับ Thread Bomb]

💻 [เกี่ยวกับ Time Travel]

DynamoDB Timeout Testing : ตรวจสอบว่า DynamoDB Java client ถูกคอนฟิกด้วย 500ms connection timeout

เพิ่มเติม

ถ้าใช้ scenarios ประเภท attack CPU แล้วถ้าใช้คำสั่ง ps -ef | grep gremlin จะเห็นว่า จริงๆแล้ว ตัว agent ก็รันโดยการส่ง parameter เข้าไปดังรูป

วิธีที่มีคนทำ

อาจเอาขั้นตอนของ chaos ไปอยู่ใน CD pipeline
ส่วนเครื่องมืออย่าง Gremlin ไม่จำเป็นต้องเอากระบวนการ chaos นี้ไว้ใน CD pipeline คือ ถ้าอยากจะทดสอบ VM หรือ cluster ก็เริ่มทดสอบเมื่อไหร่ก็ได้

รายละเอียดยังมีเพิ่มครับ

...
อ้างอิง
https://principlesofchaos.org/
https://learning.oreilly.com/library/view/chaos-engineering/

https://www.youtube.com/watch?v=3CNNhK9JTDk

CVSS หรือการระบุความรุนแรงของช่องโหว่

Theerapong — Sat, 06 Feb 2021 09:10:21 +0000

CVSS หรือ The Common Vulnerability Scoring System คือระบบการบอกระดับความรุนแรงของช่องโหว่ (ในระบบไอทีต่างๆ) ซึ่งการมี CVSS นี้ก็จะช่วยให้ software developers, testers, security engineer หรือเจ้าหน้าที่ทางด้านไอทีอื่นๆ สามารถประเมินได้ว่า ช่องโหว่ที่มีอยู่นั้นสามารถถูกคุกคามได้มากน้อยเพียงใด และสามารถบรรเทาหรือรับมือได้อย่างไร

ช่องโหว่ในทางซอฟแวร์คือ ?

ช่องโหวของซอฟแวร์ หรือ a software vulnerability คือข้อบกพร่องใด้ๆก็ตามในโค๊ด (sorce code) ซึ่งอาจจะถูกเจาะได้ หรือผู้โจมตีสามารถใช้ประโยชน์จากข้อบกพร่องที่มีอยู่นี้ ซึ่งสาเหตุของช่องโหว่ อาจมาจากตรรกะการเขียนที่ผิดพลาด (faulty logic), มีกระบวนการตรวจสอบต่างๆที่ไม่เพียงพอ (inadequate validation mechanisms), ไม่มีการป้องกันเวลาโปรแกรมใช้หน่วยความจำเกิน (buffer overflows), APIs ไม่มีการป้องกัน หรือเพราะใช้ libraries ของคนอื่น ซึ่งสิ่งเหล่านี้มักเป็นปัญหาที่ทำให้เกิดช่องโหว่

ช่องโหว่ที่มีอยู่ก็จะเป็นความเสี่ยงของผู้ใช้และองค์กร ซึ่งผู้โจมตีก็อาจจะสามารถเจาะเข้าสู่ระบบ, ทำลายระบบ, ทำให้ระบบมีการหยุดทำงาน, ขโมยข้อมูล หรือติดตั้งโปรแกรมอันตรายต่างๆ (malware) เข้าสู่ระบบ เว้นแต่ว่า เมื่อช่องโหว่นั้นๆถูกพบและถูกแก้ไข (ถูก patch) โดยการอัพเดท ก็จะทำให้ระบบมีความปลอดภัย

ช่องโหว่ถูกรายงานอย่างไร ?

วิธีการรายงานช่องโหว่ก็จะขึ้นอยู่กับประเภทของซอฟแวร์ซึ่งถูกพบ ชนิดของช่องโหว่ และปัจจัยต่างๆ โดยปกติแล้วช่องโหว่จะถูกพบและรายงานโดยนักวิจัย หรือนักทดสอบระบบ ไม่ว่าจะเป็นคนที่ทำหน้าที่นี้แบบ full-time หรือ คนที่เป็น freelance แบบนักล่าเงินรางวัล (bug bounty)

ช่องโหว่เล็กๆน้อยๆที่ไม่เป็นอันตรายมาก ที่สามารถแก้ไขโดยผู้ใช้งานทั่วไปได้ ก็อาจะไม่ถูกรายงาน แต่ถ้ามีช่องโหว่ระดับอันตรายแล้วถูกพบโดยเหล่าอาชยากรทางไซเบอร์ ก็พวกเขาอาจจะไม่รายงานช่องโหว่ดังกล่าวให้กับเจ้าของซอฟแวร์ ซึ่งตามหลักแล้วเมื่อพบช่องโหว่ก็ควรรายงานให้กับบริษัทผู้พัฒนาซอฟแวร์นั้นๆ

ช่องโหว่ที่พบในซอฟต์แวร์ที่มีลิขสิทธิ์อาจจะถูกรายงานไปยังบริษัทต้นทาง หรือองค์กร MITRE แต่ถ้าเป็นช่องโหว่ที่พบในพวก open source ก็อาจจะรายงานไปยังกลุ่ม community ของ open source นั้น

เมื่อช่องโหว่ถูกรายงานไปยังหน่วยงานเช่น MITRE จากนั้นทางหน่วยงานก็จะระบุหมายเลขของช่องโหว่ดังกล่าว แล้วทาง MITRE ก็จะแจ้งไปยังหน่วยที่เกี่ยวข้องต่อไป (vendor หรือ project manager) ซึ่งผู้รับผิดชอบต่างๆก็จะมีเวลาให้ 30 ถึง 90 วันในการแก้ไขช่องโหว่ดังกล่าวก่อนที่รายละเอียดของช่องโหว่จะถูกเปิดเผยต่อสาธาราณะ ซึ่งนี่ก็จะเป็นการลดความเป็นไปได้ที่ผู้โจมตี (attackers) อาจจะเจาะช่องโหว่ก่อนที่จะถูกแก้ไข

CVSS คือ?

CVSS หรือ The Common Vulnerability Scoring System คือระบบ (มาตรฐาน, standard) การกำหนดระดับความรุนแรงของช่องโหว่ ซึ่งระบบหรือมาตรฐานนี้ผู้ภายใต้การกำกับดูแลของหน่วยงาน FIRST (the Forum of Incident Response and Security Teams) ซึ่งเป็นองค์กรไม่แสวงผลกำไร ซึ่งระบบหรือมาตรฐานดังกล่าวได้นิยามความรุนแรงของช่องโหล่ตั้งแต่ 0.0 จนถึง 10.0 (ซึ่งระดับ 10.0 ถือว่ามีความรุนแรงสูงสุด) ซึ่งระบบหรือมาตรฐานล่าสุด (เมื่อ June 2019) คือเวอร์ชั่น CVSS 3.1

ระบบหรือมาตรฐานดังกล่าวก็จะช่วยให้นักวิจัยทางด้าน security, ผู้ใช้ หรือองค์กรต่างๆได้มีมาตรฐานในการวัด การรายงานและติดตามความรุนแรงของช่องโหว่ได้เข้าใจได้ตรงกัน และ CVSS ก็จะช่วยให้ทีม security และนักพัฒนาสามารถเรียงลำดับความสำคัญในการรับมือกับภัยคุกคามและพร้อมจัดการกับทรัพยากร (hardware, software) ได้อย่างมีประสิทธิภาพ

CVSS ระบุระดับความรุนแรงได้อย่างไร?

ระดับความรุนแรงของช่องโหว่แต่ละตัว หรือแต่ละ CVSS นั้น เป็นการนับคะแนน (scoring) จากหลายๆปัจจัยหรือองค์ประกอบหรือ Base score รวมกัน ซึ่งแต่ละปัจจัยหรือแต่ละองค์ประกอบก็จะมีเกณฑ์การนับคะแนนเฉพาะของตัวเอง ซึ่งแรกๆนั้น ผู้รายงานช่องโหว่อาจจะกำหนดระดับความรุนแรงชั่วคราวได้

Base score ของCVSS ถูกวัดโดย

– คะแนน subscore ความสำเร็จของการถูกเจาะ
– คะแนน subscore ผลกระทบ
– คะแนน subscore ขอบเขต
แต่ละ subscore ก็จะมีตัวชี้วัดที่จะใช้ประเมินขอบเขตของการโจมตี, ความสำคัญของข้อมูลและระบบที่ได้รับผลกระทบ

Base score

ตัว Base score จะแสดงให้เห็นลักษณะหรือพฤติกรรมเฉพาะของช่องโหว่ได้ และลักษระดังกล่าวไม่ควรที่จะเปลี่ยนไปเปลี่ยนมา สำหรับการคำนวณหรือนับคะแนนของ base score นั้น ทางผู้รายงานช่องโหว่ต้องคำนวณจากทั้งสาม subscore (ที่กล่าวมาก่อนหน้า)

Exploitability subscore

Exploitability subscore หรือคะแนน subscore ความสำเร็จของการถูกเจาะ จะวัดจากองค์ประกอบต่างที่ทำให้เกิดช่องโหว่ ซึ่งองค์ประกอบเหล่านี้ก็จะช่วยให้นักวิจัยรู้ว่าช่องโหว่นี้จะสามารถถูกเจาะโดยผู้โจมตีได้อย่างไร ซึ่ง subscore นี้ประกอบด้วยตัวชี้วัดดังต่อไป

Reference:

Eddie Segal,
https://blog.malwarebytes.com/malwarebytes-news/2020/05/how-cvss-works-characterizing-and-scoring-vulnerabilities/
[1] https://www.first.org/cvss/specification-document