ซึ่งทาง Kubernetes เอง ได้ทำฟีเจอร์มารองรับการแก้ปัญหานี้แล้ว เป็น Kind ประเภท Secret นั่นเองครับ เลยขอบันทึกวิธีทำไว้สักหน่อย

ทำความเข้าใจก่อน ทำไมต้องแยก Sensitive Data

ก่อนจะไปถึงวิธีการ มาทำความเข้าใจก่อนว่าทำไมเราต้องแยก Sentitive Data ออกไป (ขอนอกเรื่อง Kubernetes สักหลายย่อหน้า เดี๋ยวโพสต์จะสั้นไป!!)

หากใครทำงานคนเดียว เก็บ Source Code ไว้เป็น Private ในเครื่องตัวเองเท่านั้น (หรือ Git Repository แบบ Private) และไม่ได้ใช้ Clound หรือทำพวก Scaling ด้วยแล้ว อาจไม่จำเป็นต้องใช้ก็ได้

แต่ถ้าเราทำงานเป็นทีมเมื่อไร เรื่องการกำหนดขอบเขตการเข้าถึงข้อมูลเป็นเรื่องสำคัญมาก เราคงไม่ต้องการให้ทีมทุกคนรู้ Password ในการเข้าสู่ระบบ หรือไม่ต้องการให้รู้ Token ในการควบคุม API ของบริการสำคัญๆ ดังนั้นแล้ว เราจะมีวิธีการจัดการพวก Sensitive Data กันมาบ้างอยู่แล้ว ที่นิยมทำกัน เช่น

1. ง่ายสุดๆ คือ ฝัง Sensitive Data ลงในโค้ดเลย แล้ว if-else จากเงื่อนไขอะไรบางอย่าง เช่น IP Server, URL Domain, Environment Variable
2. ซับซ้อนขึ้นมาหน่อย คือ ทำไฟล์ Config แยกจากโค้ด และ ignore ไม่ขึ้นไปอยู่บน Repository ดังนั้นเมื่อ Deploy เสร็จ จะมีทีมหลีดหรือผู้มีสิทธิ์เข้าถึง Sensitive Data และ Server เท่านั้น ที่จะไปวางไฟล์ Config (หรือไฟล์ Config อาจจะไปอยู่บน Server แต่ละ Environment รอไว้อยู่แล้ว)
3. ซับซ้อนขึ้นไปอีก คือ ผู้ดูแลระบบสร้าง Environment Variable ไว้ในแต่ละ Server Environment จากนั้น เมื่อ Deploy Code ไปที่ Environment ไหน โค้ดที่เขียนก็จะเรียกใช้ Environment Variable ตามชื่อ Key ที่ตกลงกันไว้
4. Advance ไปเลย คือ ทำ Config File Server แยกไปอีกเครื่อง และ sync มาที่ server ของระบบที่จะใช้งาน จากนั้นโค้ดจะเรียกใช้ Config ตามที่อยู่ของไฟล์ที่ตกลงกันไว้

และวิธีอื่นๆ อีกหลายวิธี ซึ่งแต่ละวิธีมันก็มีความเหมาะสมที่จะใช้งานในแต่ละระบบและกระบวนการทำงานของแต่ละทีม

แต่ถ้าทีมทำงานมีเงื่อนไขอยากทำ Scaling, Automate หรือ DevOps ล่ะ เช่น

1. Source Code ต้องมาจากแหล่งเดียว และเป็นชุดเดียวกันเสมอในทุก Environment (Single Source of Truth)
2. Sensitive Data จะต้องรู้ได้บางคนเท่านั้นที่มีสิทธิ์
3. โค้ดจะต้องทำ Continuous Integration และ Continuous Deployment ได้
4. โค้ดจะต้อรองรับการทำงานบน Server ที่ Scaling ได้
5. มีการควบคุม Version ใน Deployment (Version Control)

เอาแค่ 5 เงื่อนไขนี้ วิธีการข้างต้น 4 ข้อ ก็ดูจะไม่ครอบคลุมทุกเงื่อนไข

ดังนั้น วิธีใช้ Secret ใน Kubernetes ที่จะเขียนในโพสต์นี้ จะเป็นวิธีการมาตรฐานที่ Kubernetes ได้ทำฟีเจอร์ออกมาให้ใช้ มีความคล้ายกับการทำ Config File Server เพียงแต่เป็นเหมือน Container ที่ใช้คุณสมบัติของ Kubernetes นั่นเอง

โครงสร้างของ Secret ใน Kubernetes

ตามภาพเลยครับ จะแยก Secret ออกมาจาก Pod (แต่ยังอยู่ใน Node และ Cluster เดียวกัน) ดังนั้น เวลาจะใช้งานใน Pod ไหนก็ต้อง จะต้องระบุ Secret และ Key ที่จะใช้ เพื่ออ้างอิงถึง Sensitive Data ที่เราต้องการ

ตัวอย่างที่จะใช้ในโพสต์ต่อไปนี้ จะอ้างอิงจากโพสต์เดิมที่
ลองทำ Kubernetes บน Amazon EKS แบบง่ายๆ ด้วย eksctl

เริ่มต้นสร้าง Kubernetes Secret

สร้างไฟล์ YML ขึ้นมา เพื่อสร้างชุด secret โดยในที่นี้ผมใช้ไฟล์ชื่อ eks-myweb-secret.yml

apiVersion: v1
kind: Secret
metadata:
  name: myweb-secret
  namespace: myweb
  labels:
    app: myweb-secret
data:
  secret_username: aWZldw==
  secret_password: cGFzczEyMzQ=

จากนั้นทำการ apply ด้วยคำสั่งดังนี้

kubectl apply -f eks-myweb-secret.yml

และลองทำการเช็คดูว่าสร้างสำเร็จไหม ด้วยคำสั่งดังนี้

kubectl get secrets -n myweb

โดยในที่นี้ผมใช้ namespace ชื่อ myweb นะครับ

เราจะเห็นผลลัพธ์ตามภาพด้านล่าง

สังเกตว่า Type เป็น Opaque หมายถึง เป็นการกำหนดการเข้าถึงเองโดยผู้ใช้งาน ซึ่ง Type นี้จะเป็น default ให้อัตโนมัติ หากอยากใช้ Type อื่นๆ ก็มีให้เลือก 8 ตัว อยู่ที่รูปแบบที่เราอยากจะทำ สามารถไปหาอ่านได้ที่ Kubernetes Secret

มาดูรายละเอียดภายใน Secret กัน

หากต้องการดูรายละเอียดว่า Secret นี้มีอะไร ให้ใช้คำสั่งนี้

kubectl describe secrets/myweb-secret -n myweb

โดยชื่อ myweb-secret คือชื่อ Secret ของผมนะ (ตามที่ระบุใน YML File )

จะแสดงรายละเอียดของ Secret ขึ้นมา

คราวนี้เราเห็นแล้วว่า Secret มี Key อะไรบ้าง แต่อยากเห็นเนื้อหาข้างใน ก็สามารถดูได้ด้วยนะครับ ด้วยคำสั่งนี้

kubectl get secret myweb-secret -n myweb -o jsonpath='{.data}'

เราก็จะเห็นข้อมูลใน Secret ดังนี้

และหากใครใช้ Mac หรือ Linux ก็ decode ข้อมูล base64 ออกมาดูได้เลยว่าคืออะไร ตามภาพครับ

ทำให้ Pod เรียกใช้งานตัวแปรใน Secret

เมื่อเราสร้าง Secret รอไว้แล้ว คราวนี้ถึงเวลาเรียกใช้ โดยผมได้แก้ไข Source Code ให้มีการอ่าน Environment จาก Secret ไว้ สองตัว คือ SECRET_USERNAME กับ SECRET_PASSWORD

จากนั้นทำการ build image, tag และ push image ไปไว้ใน Docker Repo เป็น version 3 (docker.io/ifew/docker-test-php:v3)

ต่อมา เราจะแก้ไขไฟล์ Deployment YML ที่เอาไว้สร้าง Pod, โดยแต่เดิม มีการเรียกใช้ Environment Variable ตรงๆ ในไฟล์เลย ดังนี้

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb-deployment
  namespace: myweb
  labels:
    app: myweb
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myweb
  template:
    metadata:
      labels:
        app: myweb
    spec:
      containers:
      - name: phpfpm
        image: docker.io/ifew/docker-test-php:v3
        ports:
        - containerPort: 80
        env:
        - name: MYSQL_DB_HOST
          value: mydb.host.com
        - name: MYSQL_DATABASE
          value: test
        - name: MYSQL_USER
          value: ifew 
        - name: MYSQL_PASSWORD
          value: password1234
        - name: MYSQL_ROOT_PASSWORD
          value: password1234
        - name: TEST
          value: test

โดยวิธีการเรียกใช้ Secret จะมีรูปแบบโค้ดดังนี้

- name: SECRET_USERNAME
  valueFrom:
    secretKeyRef:
      name: myweb-secret
      key: secret_username

อธิบายทีละค่า

• name: SECRET_USERNAME คือ กำหนด ชื่อ Key ของ Environment Variable ที่จะถูกนำไปใช้ในโค้ด
• valueFrom.secretKeyRef.name: myweb-secret คือ ชื่อ Secret ที่เราสร้าง
• valueFrom.secretKeyRef.key: secret_username คือ ชื่อ Key ที่ใช้อ้างไปหา Value ใน Secret

ซึ่งผมจะเพิ่ม env สองตัว ที่เรียกใช้จาก Secret, ดังนั้นไฟล์ที่แก้ไขของ Deployment YML ผมจะได้รูปแบบนี้

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb-deployment
  namespace: myweb
  labels:
    app: myweb
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myweb
  template:
    metadata:
      labels:
        app: myweb
    spec:
      containers:
      - name: phpfpm
        image: docker.io/ifew/docker-test-php:v3
        ports:
        - containerPort: 80
        env:
        - name: MYSQL_DB_HOST
          value: mydb.host.com
        - name: MYSQL_DATABASE
          value: test
        - name: MYSQL_USER
          value: ifew 
        - name: MYSQL_PASSWORD
          value: password1234
        - name: MYSQL_ROOT_PASSWORD
          value: password1234
        - name: TEST
          value: test
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: myweb-secret
              key: secret_username
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: myweb-secret
              key: secret_password

หลังจากแก้ไข Deployment YML เรียบร้อย ก็ทำการ Apply อีกครั้ง

kubectl apply -f eks-myweb-deploy.yml

และลองทดสอบดูครับ ว่ามีการเรียกใช้งานถูกต้องไหม

หากต้องการอัพเดทค่าใน Secret ล่ะ ทำอย่างไร?

ให้แก้ไข Secret YML ไฟล์ และทำการ Apply ใหม่ จากนั้นขั้นตอนสำคัญคือ จะต้อง Restart Pod ด้วย เพื่อให้อ่าน Environment Variable ใหม่ ด้วยคำสั่ง

kubectl -n myweb rollout restart deployment myweb-deployment

โดยที่ myweb คือชื่อ namespace และ myweb-deployment คือชื่อของ Deployment ที่ผมตั้งไว้

จากนั้นลองทดสอบใหม่ ก็จะเห็นการเปลี่ยนแปลงทันที

สรุป

Kubernetes ได้ทำฟีเจอร์ Secret ออกมาเพื่อให้เราใช้ เราก็ใช้เถอะ ซึ่งที่ผมเขียนมา เป็นหนึ่งในรูปแบบที่ Kubernetes แนะนำ แต่จริงๆ สามารถทำอีกวิธีหนึ่งได้คือ ทำเป็น Config File จาก Pod โดยการไปสร้าง Volumes และทำการ Mount Path จากนั้นก็เรียกข้อมูลจาก File Path นั้นได้เลย (เหมือนวิธี Config File Server ที่ทำๆ กันมา) ใครสนใจลองไปหาอ่านต่อได้ที่ Using Secrets as Files from a Pod

Reference

• https://kubernetes.io/docs/concepts/configuration/secret/
• Cover Image from https://www.conjur.org/blog/four-ways-to-keep-kubernetes-secrets-secret/

วิธีจัดการ Kubernetes บน Amazon EKS

ตัว Amazon EKS (Amazon Elastic Kubernetes Service) มีวิธีการจัดการสองแบบ คือ

• eksctl – ที่เป็น CLI tool ของ Amazon เอง ในการจัดการ Amazon EKS โดยเฉพาะ
• AWS CLI – ที่เป็น CLI tool ของ Amazon ที่ไว้จัดการ Service ต่างๆ ของ Amazon รวมถึง Amazon EKS ด้วย

จากที่ลองทดสอบเล่นทั้งสองแบบ eksctl ใช้งานง่ายกว่ามาก เรียกว่าเป็น Automated Tool สำหรับ shortcut คำสั่งในการจัดการ EKS เลย แต่ก่อนจะไปต่อ เราควรต้องมีความรู้ในสามเรื่องนี้ก่อน เพื่อจะได้ไม่ไป งง กลางทาง

1. AWS Service
2. Docker
3. Kubernetes

เริ่มต้นใช้งาน Amazon EKS

ไม่ว่าจะเลือกวิธีการใดก็ตาม สิ่งที่ต้องทำ มีดังนี้

• ติดตั้ง AWS CLI , สร้าง Access Key ID และ Configure AWS CLI – เพื่อให้เครื่องเราสามารถเชื่อมต่อและควบคุม Account AWS ของเราได้
• ติดตั้ง kubectl – เป็นตัว Core เพื่อใช้ควบคุม Kubernetes Clusters
• ติดตั้ง eksctl – เพื่อไปใช้ร่วมกับ kubectl อีกที ในการควบคุม Kubernetes Clusters บน Amazon EKS
• AWS IAM Permissions – โดย Account AWS เราจะต้องได้รับสิทธิ์ที่เกี่ยวข้องทั้งหมดสำหรับการควบคุม Amazon EKS ทั้งหมด รวมไปถึง ECR, Network, EC2 ด้วยครับ

โครงสร้าง Kubernetes และสิ่งที่จะต้องทำบน EKS

ในรายละเอียด สามารถอ่านจากบล็อกต่างๆ ได้เลยครับ ผมขอสรุปไวๆ ดังนี้

1. Kubernetes Cluster – จำเป็นต้องสร้างก่อนเลย เพื่อใช้เป็น Cluster ของชุด Server เช่น ควบคุม (Control) กระจาย (Distribution) ตั้งกำหนดการ (Scheduling)
2. Control Plane หรือ Master Node – ตัวนี้ก็จะเป็นต้องมี แต่ EKS จะสร้างให้อัตโนมัติ โดยอิงจาก Config ที่เรากำหนดในไฟล์ yml หรือใน AWS Console เช่น Min/Max Node, Min/Max Pod ใช้เพื่อควบคุมสิ่งต่างๆ ใน Cluster
3. Node – ตัวนี้จำเป็นต้องสร้าง เสมือนเครื่อง Server ของเรา สามารถปั๊มเพิ่ม ลด ได้ตามจำนวนที่กำหนด
4. Pod – ตัวนี้จำเป็นต้องสร้าง คือกลุ่มของ Container ของเรา

สร้าง Kubernetes Cluster

ให้รันคำสั่งตามนี้ครับ

eksctl create cluster --name=test-php-web --region ap-southeast-1 --managed --nodes=2 --node-type=t2.micro --with-oidc --ssh-access --ssh-public-key ifew_orm_macbook --profile few_orm

คำอธิบาย

• –name=test-php-web คือ ชื่อ Cluster
• –region ap-southeast-1 คือ Zone ทวีป AWS ที่เราจะใช้งาน ในที่นี้คือสิงคโปร์
• –nodes=2 คือ จำนวน node หรือจำนวนเครื่อง ec2 ที่จะถูกเปิดขึ้นมา (Optional)
• –node-type=t2.micro คือ type class ของเครื่อง ec2 ที่จะถูกเปิดขึ้นมา (Optional)
• –managed คือ บอกว่าจะสร้างแบบ Managed nodes ไม่ใช่แบบ Fargate
• –with-oidc คือ เปิดให้ใช้ OIDC ใน cluster นี้ได้ (Optional)
• –ssh-access คือ เปิดให้ใช้ SSH Access ใน cluster นี้ได้ (Optional)
• –ssh-public-key ifew_orm_macbook คือ ระบุ Public Key สำหรับ SSH Access (Optional)
• –profile few_orm คือ บอกว่าใช้ AWS Profile ไหนในการรันคำสั่งนี้ (Optional)

สร้าง Namespace

ในที่นี้ ผมขอเสริมเรื่องการสร้าง namespace นิดนึง ไว้จำกัดขอบเขตการทำงาน และเพื่อความปลอดภัย กันพลาดพลั้งไปลบอะไรออก

kubectl create namespace myweb

• myweb คือ ชื่อของ namespace ที่จะใช้

จะได้หน้าตาแบบนี้

สร้าง YML File สำหรับ Deployment

สร้างไฟล์ yml ขึ้นมา เพื่อ config pod และการ deployment ในที่นี้ผมใช้ไฟล์ชื่อ eks-myweb-deploy.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myweb-deployment
  namespace: myweb
  labels:
    app: myweb
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myweb
  template:
    metadata:
      labels:
        app: myweb
    spec:
      containers:
      - name: phpfpm
        image: xxxxx.dkr.ecr.ap-southeast-1.amazonaws.com/test:v1
        ports:
        - containerPort: 80
        env:
        - name: MYSQL_DB_HOST
          value: mydb.host.com
        - name: MYSQL_DATABASE
          value: test
        - name: MYSQL_USER
          value: ifew 
        - name: MYSQL_PASSWORD
          value: password1234
        - name: MYSQL_ROOT_PASSWORD
          value: password1234
        - name: TEST
          value: test

จากนั้นทำการรันคำสั่ง

kubectl apply -f eks-myweb-deploy.yml

จะได้หน้าตาแบบนี้

ถ้าอยากรู้ว่าสร้างจริงไหม มีอะไรใน namespace เราแล้วบ้าง ให้ใช้คำสั่งนี้ครับ

kubectl get all -n myweb

myweb คือ ระบุชื่อ namespace

จากนั้นจะได้ข้อมูลดังนี้

ใน config ผมสร้างไว้ 2 pod ดังนั้น และถ้าใช้งานได้ ตรง Status จะขึ้นว่า Running

ลองไปดูใน AWS Console โดยเข้าไปที่เมนู EKS > เลือกชื่อ Cluster ที่เราสร้าง > เลือก Node ที่เราสร้าง > Pods จะแสดงรายการสองกลุ่ม คือ กลุ่ม Node Processes กับกลุ่ม Pod ที่เราสร้างขึ้นมา

ตอนนี้แอพเราขึ้นไปรันรอไว้แล้ว แต่ยังไม่มีช่องทางเข้านะครับ เราต้องสร้าง Service ขึ้นมาก่อน

สร้าง YML File สำหรับ Service

สร้างไฟล์ yml ขึ้นมา เพื่อ กำหนด Service และให้มีช่องทางเข้าไป Pod ที่เราสร้าง โดยผมจะสร้างแบบมี Load Balance ด้วย และตั้งไฟล์ชื่อ eks-myweb-service.yml

apiVersion: v1
kind: Service
metadata:
  name: myweb-service
  namespace: myweb
  labels:
    app: myweb
spec:
  selector:
    app: myweb
  ports:
  - name: http
    port: 80
    targetPort: 80
  type: LoadBalancer

จากนั้นทำการรันคำสั่ง

kubectl apply -f eks-myweb-service.yml

จะได้หน้าตาแบบนี้

ลองดูสิ่งที่อยู่ใน namespace อีกครั้ง

จะเห็นว่า มี Service เพิ่มเข้ามาแล้ว โดย Type เป็น LoadBalancer ตามที่ได้ config ใน yml ของเรา
ส่วน URL ที่ใช้เข้า App เรา อยู่ตรง External-IP นั้นเอง

ลองเข้า App ที่สร้างขึ้นมา

เปิด Brower และเข้า URL จาก External-IP ที่แสดงในขั้นตอนก่อนหน้านี้ ก็สามารถใช้งานได้แล้วครับ

Tip: ใช้งาน HTTPS ผ่าน ACM Certificate

โดยให้สร้าง ACM certificate ขึ้นมา และใน yml ไฟล์ของ service ให้เพิ่มสองส่วนตามภาพด้านล่าง

โดยรายละเอียดวิธีติดตั้ง ให้ดูได้ที่ https://aws.amazon.com/premiumsupport/knowledge-center/terminate-https-traffic-eks-acm/

สรุป

สำหรับ Kubernetes ผมเองเรียกว่าเบสิกมากๆ เป็นมือใหม่เลย ได้ลองเรียนรู้ใช้งานมาสักพัก เลยอยากสรุปไว้ให้ผู้อ่าน ที่กำลังริเริ่มอยากทดลองใช้ Kubernetes มาได้ใช้ด้วยกันครับ ผ่านบริการของ Amazon EKS ก็หวังว่าจะช่วยให้การเริ่มต้นได้ง่ายขึ้น และเอาไปต่อยอดเพื่อใช้งานระดับ Advance ต่อไป

หากใครอยากได้สรุปคำสั่งต่างๆ รวมถึงโค้ดตัวอย่าง ทั้งหมดในโพสต์นี้
สามารถไปดูได้ที่ https://github.com/ifew/eks-test-php

Reference

• https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html