DEV Community: V-ris Jaijongrak

Secure your AWS credentials on GitHub Actions with OIDC

V-ris Jaijongrak — Wed, 07 Jan 2026 14:59:04 +0000

GitHub Actions

Ever wondering if you can tighten the security of your AWS credential for your GitHub Actions (workflow/pipeline that allows GitHub repository to perform Actions enabling CI/CD)?

Mostly, to keep things simple creating an IAM user with Programmable Key would be something people starting to work with AWS Cloud is instructed to follow. (with a caution to store it securely and never expose it to public Internet)

For GitHub Actions, you can store those AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY in the Secrets section and it should be kept securely. Wouldn't this suffice if you want it to be kept safely? Answer is not quite, since we have a better approach to keep it even more secure.

AWS Credential is important and must be kept secret

Once exposed, depending on the permissions allowed for that identity to perform damage could potentially be fatal. Which is why the least-privilege is an important aspect when designing the IAM Users/Roles to perform specific tasks.

AWS IAM Identity Provider (OIDC)

As long as the caller to AWS services is compatible with OIDCv2, you can securely make it exchange the token with short-lived AWS session token that permits the access to AWS service.

With this approach, you can eliminate the need of embedding the AWS secrets (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) into your GitHub Actions secrets and just use role assuming mechanics to assume an IAM role arn to perform actions on selected accounts.

Step-by-step

Create AWS IAM Identity Provider in your account with AWS CLI
```
aws iam create-open-id-connect-provider \
--url https://token.actions.githubusercontent.com \
--client-id-list sts.amazonaws.com
```
Alternatively, you can create one in AWS Console in IAM --> Identity Provider and Add provider (as shown below).

Then, choose OIDC and provide https://token.actions.githubusercontent.com as Provider URL and sts.amazonaws.com as Audience.

Create IAM role with following Trusted Policy (and permission policies to match with your use-case)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:<GITHUB_ORG>/<GITHUB_REPOSITORY>:ref:refs/heads/<GITHUB_BRANCH>"
        }
      }
    }
  ]
}

** replace AWS_ACCOUNT_ID, GITHUB_ORG, GITHUB_REPOSITORY and refs:refs/heads/<GITHUB_BRANCH> to match with your conditions.

On your GitHub Actions add permission for the action to write OIDC (see the following example)

# Need ID token write permission to use OIDC
permissions:
  id-token: write
jobs:
  run_job_with_aws:
    runs-on: ubuntu-latest
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@main # Or a specific version
        with:
          role-to-assume: <Role ARN you created in step 2>
          aws-region: <AWS Region you want to use>
      - name: Additional steps
        run: |
          # Your commands that require AWS credentials
          aws sts get-caller-identity

And we're done. Very simple and neat, with this we can rely on the Token exchange mechanism between GitHub and AWS and can now remove the secrets on GitHub (which by security policy, those even being kept secret should always be rotated. And we no longer need to do that, one less task to keep our Security guys happy :))

Conclusion

This is a comprehensive walkthrough which most of the content are just wrapping up the aws-actions github content, it is an easy-to-follow and can improve your security posture towards AWS deployment.

By creating it secure in the first place, you would not have to spend time to retroactively improve it. But even so, improving security is always a good thing (especially if there is no drawback on performance). Hope you find it a good tip to enhance your GitHub Actions with AWS.

Happy Coding. :)

References:

My journey on AWS Region Migration: What I wished I had aware of

V-ris Jaijongrak — Wed, 17 Sep 2025 13:57:04 +0000

TL;DR

Always consult with Solution architect for end-to-end of use-cases before go-ahead, to save yourself of the troubles you have to improvise for the solutions.

Research on available solutions, deployment can go much smoother when you have plans for them.

Never go on migrating the production environment without foolproof plan that can ensure they will not fail.

Background

For a brief introduction, my company runs a production workload on AWS, recently AWS launched a new region which happens to be much closer to our customers than the current one. The decision was clear that we had to move towards the new region to benefit more from the Cloud environment we used on AWS.

Before, we had not adopted the DR across region and cross-region was not planned for architecture design. We deployed our main workload (containers) on EKS using Aurora/RDS as database, and integration via State Machines and Lambda Functions (via AWS API Gateway). And distribution via CloudFront and S3.

To wrap it up, the image is just a rough and simplified version of the real deployment.

The migration of EKS is smooth enough (with AWS Secrets Manager and External Secrets (in EKS) for variable injections).

The Problems

The requirements for some of the deployments though were not cleared before the migration took place. (IP allowed list for the third party locks the outbound traffic to the public outbound IP on the original region and scheduling the migration to be in the same window would be challenging at the very least)
- Solution: leave the workload that cannot be migrated in the original region, and schedule the migration to be in a later phase. This introduces the use of cross-region communication (via Transit Gateway Peering in this case) which drives the cost and latency up a bit but probably a small cost to pay to get the migration going.
A part of the workload that can't be migrated right away was placed on API Gateway (Private), the caller to the API (deployed on EKS) was not aware of the fact that it place the call without using VPC Endpoint and it was working well before the migration hiding the fact that it is not invoked via the intended design (via Route 53 and redirect the call via ELB). But before the end-to-end test on the migration region was conducted this was not too obvious.
- Solution: via the cross-region communication, call via private API in API-Gateway is resolvable (with VPC Interface endpoint and private DNS entry) but I wanted to mention here as it might get overlooked.
Data integration via S3, the data pipeline (not shown in the diagram) consumed from S3 and was marked not ready for the migration has a strong dependency on the S3 bucket. On the other end S3 also has data-dependency with Aurora/RDS as well (SQL Query statement does the upload to S3 bucket). A gentle reminder, S3 bucket name has to be unique across regions while services on VPC cannot reach S3/S3 Gateway endpoint on different regions.
- Solutions: There are various ways of achieving this depending on the requirements.
  - S3 Replication so that the data can be replicated for each region to serve the workload in the new region, while data-pipeline integration can be served in the origin region (needs Versioning and a carefully designed rule to avoid replication looping)
  - Multi Region Access Points for S3 instead of replicating the whole S3 bucket into destination region, allocating a MRAP could facilitate the access via globally accessible access point (needs to refactor the S3 caller to use the access point)
  - VPC Endpoint Interface for S3 service (+ Route 53 Private Hosted Zone + VPC Peering/Transit Gateway Peering) if Private networking was already a strict requirement for your Cloud Infrastructure you are probably at least half way there and small additional would not be so bad (depends on how much data needs to be transferred between the region)

PS The transit gateway usage here is due to the abstraction of the other VPC attachments (for the data pipeline VPC) and you can use VPC Peering instead if your network topology is simple enough and the VPCs do not have no overlapping IP CIDR and your Network team would not bite your head off for that.

Conclusion

Plan ahead and go through revisions to ensure that you got everything covered.

I have learned to apply those concepts and I appreciate the support I got from my team and the result is a more efficient Cloud platform and I am satisfied with it.

Thank you for reading and following through, I hope you learn something and I am more than happy to answer if you have any questions regarding this.

How I Create a Hanged Man Python game with AWS Q CLI : for AWS Services as a guide for certification exam in minutes

V-ris Jaijongrak — Fri, 13 Jun 2025 09:39:20 +0000

This blog entry will demonstrate on how to build a command line game with Python programming language, but we will use AWS Q CLI to develop the game for us.

Disclaimer: This blog entry is part of the AWS Game challenge in the community to create a game with the help of AWS Q CLI

To start with if you have not installed the Q CLI yet, please consult with this page for instruction. https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html

If you wish to get the source code of the game (in python), you can find it in https://github.com/guxkung/hangman-aws-services

As I frequently take Certification exam and sometimes switching the domain would require me to look up at the service name and definition (too often than I would like to confess), I think wrapping that process up into a game would be something I believe some might see benefits of it as well.

The process is straight-forward enough and AWS Q CLI can get my point without much of the hurdle, but specifying the domain and giving out sufficient keywords for it to catch up on your idea is very similar to project kick-off or grooming in my opinion.

With the use of AI, the skeletal and foundation of the program can be done mostly by AI. We just need to review and check whether there are mistakes in critical path of the processes or misconceptions or hallucinations happened.

For this simple game, I would say it saves me hours of programming from scratch. And it even generate a stub of README.md in the final process as well, it was great.

the first quote I put Q CLI to work with was:

Hello, I want to try and explore capabilities of Amazon Q. This time I wish to build a Hanged man game (word guessing) with AWS provided services as the keyword while providing the description

The response was:

Hello! I'd be happy to help you build a Hangman game that uses AWS service names as the keywords along with their descriptions. This is a fun way to learn about AWS services while playing a game.


Let's create a simple Python-based Hangman game that:
1. Randomly selects AWS services as words to guess
2. Provides the service description as a hint
3. Implements the classic Hangman gameplay mechanics

Here's how we can implement this: (see v1 in github repository)

Let me save this file for you:

The first version of the playable game would look like this.

Welcome to AWS Hangman!
Guess the AWS service name based on its description.

Hint: Fully managed extract, transform, and load service that makes it easy to prepare and load data for analytics

           --------
           |      |
           |      
           |      
           |      
           |     
           -

Word: _ _ _ _


Please guess a letter or the full word: glue
Hint: Fully managed extract, transform, and load service that makes it easy to prepare and load data for analytics

           --------
           |      |
           |      
           |      
           |      
           |     
           -

Word: G L U E
Letters guessed: 
Words guessed: 
Tries left: 6

It is so easy to get a proof of concept setup, but it was not yet reaching of what I set as objective of this game. So I asked Q CLI to improve it even further before we can do a full review. The query was:

let's make the service more advanced and perhaps make it suitable for AWS certification test takers to get a quick recap of what they need to be aware of and perhaps add an update feature available would be appreciated as well.

The response was:

I'll enhance the Hangman game to make it more suitable for AWS certification test takers with additional features for learning and review. Let's create a more advanced version with:

1. Difficulty levels based on certification types
2. More comprehensive service descriptions
3. An update feature to add new services or modify existing ones
4. Score tracking and statistics
5. Category filtering (compute, storage, database, etc.)
6. Learning mode with detailed explanations

I apologize for the timeout. Let's break this down into smaller steps to create an enhanced AWS Hangman game that's useful for certification test takers.

Let's start by creating a basic version of the game with an expanded AWS service database and then add features incrementally:

I apologize for the timeout. You're right - let's break this down into smaller steps to create a more advanced AWS Hangman game for certification test takers. I'll create the enhanced version incrementally.

Let's start by creating the basic structure with an expanded AWS services database that includes certification-relevant information:

(see v2 in github repository)

Now, let's add the game mechanics and certification-focused features:

 ● Completed in 0.1s
I've created an enhanced AWS Hangman game specifically designed for certification test takers! This version includes several advanced features to help you learn and review AWS services while having fun.

## Key Features

1. Expanded AWS Service Database:
   • 20 AWS services with detailed descriptions
   • Categorized by service type (Compute, Storage, Database, etc.)
   • Difficulty levels (Easy, Medium, Hard)
   • Certification-specific study notes for each service

2. Learning-Focused Gameplay:
   • Shows certification study tips after each game
   • Filter games by service category or difficulty level
   • Score system that rewards tackling harder services

3. Content Management:
   • Add new AWS services with your own descriptions and study notes
   • Update existing service information as AWS evolves
   • Persistent storage of services in a JSON file

4. Game Statistics:
   • Track your progress with win/loss statistics
   • Monitor your performance over time

## How to Play

1. Run the game by executing python aws_hangman.py
2. Choose from the main menu options:
   • Play Game: Start a standard game with random service selection
   • Filter by Category: Play with services from a specific category (Compute, Storage, etc.)
   • Filter by Difficulty: Choose Easy, Medium, or Hard services
   • Add New AWS Service: Expand the database with custom entries
   • Update Existing Service: Modify descriptions or study notes
   • View Statistics: See your game performance

During gameplay, you'll:
• See a description of an AWS service
• Guess letters or the full service name
• After completing the game, see certification study notes for that service
• Earn points based on the difficulty level

## Try It Out!

The game is ready to play! I've created two files:
1. aws_hangman.py - The main game code
2. aws_services.json - A database of AWS services with certification notes

To start playing and studying for your AWS certification, simply run:
python aws_hangman.py


This game will help you memorize AWS service names, understand what they do, and learn key certification exam points in an engaging way. You can also customize it by adding more services or updating the study
notes as you learn new information.

Would you like me to explain any specific part of the implementation in more detail?
(see v3 in github repository)

To enhance it even further, I ask Q CLI with the following quote to add auto definition update.

For a starter, I think that is very impressive. However, I think if the Service list itself can be automatically updated with reliable source and up-to-date with updates for the exam themselves that would be superb.

I agree that automatic updates would make this tool even more valuable for exam preparation. Let's enhance the AWS Hangman game to fetch the latest AWS service information and exam updates from reliable 
sources.

Here's how we can implement this feature:

# AWS Hangman with Automatic Updates

I've enhanced the AWS Hangman game with an automatic update feature that fetches the latest AWS service information and certification exam updates from reliable sources. This ensures your study material is 
always current and relevant.

## New Automatic Update Feature

The game now includes a dedicated AWS service updater that can fetch information from three key sources:

1. AWS Documentation - Gets the latest service names, categories, and descriptions directly from the official AWS documentation.

2. AWS Certification Exam Guides - Extracts certification-relevant information from exam guides, including domain knowledge and key topics.

3. AWS Blogs and What's New - Monitors recent AWS announcements to keep you informed about service updates that might appear on exams.

## How the Update System Works

The update system uses web scraping to gather information from official AWS sources:

• It normalizes service names to match the game's format
• Updates existing services with new information
• Adds new services as they're released by AWS
• Enhances certification notes with exam domain information
• Tracks recent service updates that might be relevant for exams
• Creates backups of your service database before making changes

## Using the Update Feature

From the main menu, select option 7: "Update AWS Services Database"

You'll see these update options:
1. AWS Documentation
2. AWS Certification Exam Guides
3. AWS Blogs and What's New
4. All of the above
5. Back to Main Menu

The update process may take a few minutes as it carefully fetches information from multiple sources.

## Files I've Created/Modified

1. aws_hangman.py - Added the update feature to the main menu
2. aws_service_updater.py - Created a dedicated updater script
3. aws_services.json - Enhanced with more services and certification notes
4. requirements.txt - Added dependencies for the updater (requests, BeautifulSoup)
5. README.md - Updated documentation

## Getting Started

1. Install the required dependencies:

   pip install -r requirements.txt


2. Run the game:

   python aws_hangman.py


3. Use the update feature periodically to keep your AWS service information current.

This enhancement makes the AWS Hangman game an even more valuable tool for certification preparation, as it ensures you're always studying with the most up-to-date information about AWS services and 
certification requirements.

Would you like me to explain any specific part of the implementation in more detail?

And that is it, the bug fix I added to the source code is just the type check of input (isalpha() to isalnum()) since some services include number as their names (e.g. Route 53, S3, EC2, etc.)

Hope you have a fun time as much as I had here.

Setup AWS EKS with Karpenter with Terraform

V-ris Jaijongrak — Fri, 17 Jan 2025 08:59:36 +0000

As a speaker at AWS Community Day Thailand 2025, I would like to share the summary of my presentation in this blog.

The trend of micro-services has driven the development process and the CI/CD to an extent that the containers and CI/CD tools have become mainstream. The container orchestration becomes a necessity, then the Kubernetes project emerged and has taken the lead in the world of container orchestration.

This presentation aims to give the audience the first glance at the EKS (Elastic Kubernetes Service) managed by AWS. Setting it up with a careful attention on architecture for security (Private Networking) and Least Privilege IAM policies, Efficiency in cost and performance are the goal. Knowing the basics and doing them right is always a good first step.

In the demo session of this presentation, I shared a terraform template in GitHub repository that can be uses on an EC2 instance to initialize the private subnets, a single NAT gateway in the VPC as its infrastucture.
Note: the handout demo is giving a detailed in constructing the VPC components for self-explanatory and thought process, but alternatively the terraform AWS VPC module is more concise and should be considered.

Then, the demo proceeds on creating the EKS cluster, and provision the managed nodegroup and Karpenter nodepools for workload provisioning.

For anyone who would like to follow along with the slide you can find it with the following link:

presentation slide

AWS EKS with Terraform

V-ris Jaijongrak — Fri, 17 Jan 2025 06:49:00 +0000

บทความที่แล้ว เราได้พูดถึงการสร้างคลัสเตอร์จาก eksctl ซึ่งเป็นโปรแกรมพิเศษสำหรับการสร้าง และบริหารจัดการกับ eks cluster บน AWS โดยเฉพาะ

เพื่อเป็นการทดสอบ เราลงเพียงแค่ตัว kube-apiserver บน EKS Control plane โดยที่ไม่ได้สร้าง worker node บน cluster ยังจำเป็นต้องปรับปรุงมาตรฐานด้านความปลอดภัย ก่อนจะเหมาะสมในการใช้งานได้จริง และในตอนท้ายเราได้ทำลายตัว EKS cluster ไปแล้วเพื่อจะได้ทำการสร้างใหม่ด้วย tools ที่เหมาะกับการจัดการบริหารในระยะยาวมากกว่าอย่าง IaC ในบทความนี้เราจะเจาะลึกมากขึ้นกับ Terraform

เพื่อให้การสร้าง Subnet/NAT Gateway/EKS Cluster/Nodegroup (Worker Node) เป็นไปได้อย่างราบรื่น เราจำเป็นที่จะต้องจัดการกับสิทธิ์ในการเข้าถึงผ่าน IAM เสียก่อน

IAM permissions

ทั้งนี้หากไม่ได้มีจัดการ IAM และเป็น account ส่วนบุคคล อย่างน้อยที่สุดควรใช้เป็น user account ที่มีสิทธิ์ AdministratorAccess การใช้ root account ในการบริหารจัดการหรือใช้งานทั่วไปจัดว่ามีความเสี่ยงในการก่อความผิดพลาด และหากลืมลบออกความเสี่ยงจะเพิ่มเป็นทวีคูณ

การใช้ root account ควรใช้เพื่อแก้ไขปัญหาในการเข้าถึงหรือจำเป็นต้องใช้ในกรณีเฉพาะเช่น สิทธิ์ในการเข้าถึงถูกจำกัดและจำเป็นต้องปลดการจำกัดสิทธิ์ด้วย root account เป็นต้น

หากมีการจำกัดการเข้าถึงผ่าน IAM User/Role เรียบร้อยแล้ว (โดยทั่วไปสิทธิ์ AmazonEC2FullAccess เพียงพอกับการสร้าง cluster แต่ในการใช้งานควรใช้สิทธิื์ที่จำกัดกว่านั้นสำหรับ Worker node เช่น AmazonEKSWorkerNodePolicy หรือ AmazonEKSWorkerNodeMinimalPolicy)

โดยสรุป อย่างน้อยเราต้องการ User/Role สำหรับสร้าง Cluster และอีก Role สำหรับ worker node (EC2 Instance Profile) ในการเข้าถึง AWS Services ที่จำเป็นสำหรับการทำงานของ Worker node

Terraform/OpenTofu

บทความจะอ้างอิงจาก Terraform เป็นหลักแต่ตามหลักการ OpenTofu ก็ควรจะใช้งานฟังก์ชั่นที่จำเป็นสำหรับการสร้างคลัสเตอร์ได้เช่นกัน

หากยังไม่ได้ทำการลง Terraform สามารถดูวิธีการลงได้จากลิ้งค์นี้ https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli

Terraform code สำหรับโปรเจคนี้สามารถ clone ได้จาก: https://github.com/guxkung/eks-terraform.git

อ้างอิงและดัดแปลงจาก AWS IA project และ terraform modules:

Project structure

provider.tf
sg.tf
eks.tf
vpc.tf
variables.tf
config/input.tfvars

Terraform variables.tf

แก้ไขไฟล์ conf/variables.tf โดยเปลี่ยน account-id, vpc-id, vpc-cidr, subnet-cidr ให้เข้ากับ aws account

Public/Private access

ในไฟล์ eks.tf จะสังเกตได้ว่ามีการกำหนดให้ cluster_endpoint_xxx เป็น public_access หรือ private_access ได้

cluster_endpoint_public_access  = true
cluster_endpoint_private_access = false

เพื่อให้เข้าใจการทำงานได้อย่างถูกต้อง เราจะลองทั้งสองแบบโดยที่ค่าเริ่มต้นจะเป็น public_access ด้วย IP Address ของคุณ (หรือใช้ ["0.0.0.0/0"] เพื่อให้เข้าถึงจากที่ไหนก็ได้)

ในโค้ดตัวอย่างมีการแยก branch ไว้ต่างหากแล้ว (public-access/main) โดยให้ใช้ public-access branch สำหรับการทำ public-access และ main สำหรับ private access

git clone https://github.com/guxkung/eks-terraform.git
cd eks-terraform
git checkout public-access

Terraform (public) init, plan, apply

terraform init
terraform plan -var-file=conf/input.tfvars -out eks-public.plan
terraform apply eks-public.plan

Terraform (private) init, plan, apply

ในตัวอย่างถัดไป เราจะเปลี่ยนไปใช้ private access หลังการสร้างสำเร็จแล้ว คุณสามารถใช้ ec2 เป็นหน้าด่านให้กับการเชื่อมต่อเข้ากับ คลัสเตอร์ได้ เราจะใช้ t2.micro ในการเชื่อมต่อดังกล่าว โดยที่การเข้าถึงจาก Internet จะไม่สามารถเข้าถึงได้อีกต่อไป

git checkout main
terraform init
terraform plan -var-file=conf/input.tfvars -out eks-private.plan
terraform apply eks-private.plan

nslookup, dig, curl, kubectl

Destroy stuffs (EKS cluster cost money)

terraform destroy

Closure

Helm-chart, GitOps เป็นของที่แนะนำควบคู่กับการทำ Kubernetes โดยที่อาจจะใช้ tools ช่วยอย่างเช่น Chart Musuem, ArgoCD, Flux, Kubefirst เป็นต้น

หากต้องสร้างเป็นหลาย environment ควรใช้ terragrunt, terraspace เพื่อให้การบริหารจัดการเป็นไปได้อย่างเป็นระบบมากขึ้น

ขอแนะนำให้ใช้ IRSA (IAM Role for Service Account) กับ EKS Pod Identity แทนการใช้ EC2 Instance Profile ในการเข้าถึง บริการต่างๆจากทาง AWS ด้วยเหตุผลด้านความปลอดภัย (แทนที่จะเพิ่มสิทธิ์การเข้าถึงไปบน worker node โดยตรงเราสามารถสร้าง IAM Role ที่สามารถเข้าถึงได้ด้วย OIDC/EKS Pod Identity และให้สิทธิ์ดังกล่าวกับ Service Account บน Kubernetes)

Update จาก re:Invent 2024, EKS มี Auto mode ซึ่งจะทำการคำนวณและปรับ Node โดยอัตโนมัติ แทนการใช้ nodepools/nodegroups/Fargate รวมไปถึง Add-ons ซึ่งหากมีผลที่น่าสนใจจะนำมาเล่าสู่กันฟังในลำดับถัดไปครับ

AWS EKS Primer

V-ris Jaijongrak — Fri, 17 Jan 2025 06:48:43 +0000

What is Container?

จากการที่ Docker ได้ทำให้แนวคิดในการพัฒนา แอปพลิเคชั่นไปอย่างมาก การทำให้แอปพลิเคชั่น สามารถใช้งาน container ได้อย่างแพร่หลาย การ containerized ทำให้การพัฒนาแอปพลิเคชั่น ที่แตกย่อยออกเป็น Microservices ได้รับความสนใจมากขึ้นอย่างต่อเนื่อง การจัดการและควบคุมระบบที่ซับซ้อนมากขึ้นมีความจำเป็นขึ้นเป็นอย่างมาก ทั้งการจัดการ container และระบบแวดล้อม (server, networking, storage) ในระดับเบื้องต้น docker container/compose สามารถตอบโจทย์ของการทำแอปพลิเคชั่นที่ไม่ซับซ้อนได้ แต่หากต้องการการทำระบบที่ซับซ้อนมากขึ้นและสามารถรองรับการทำงานในระดับที่มีการเข้าถึงชุดข้อมูลหรือตัวโปรแกรมในระดับที่จำเป็นต้องจัดการกับความต้องการในระดับนั้นเป็นเรื่องที่ทำได้ไม่ง่ายนัก จึงจำเป็นอย่างยิ่งที่จะต้องมี ระบบจัดการและควบคุม (orchestration) ระบบดังกล่าวมีตัวเลือกให้เลือกใช้งานได้ตามลักษณะของความต้องการของระบบ อย่างเช่น docker swarm/AWS ECS/Google Containers/Azure Container Apps/Kubernetes ในบทความนี้จะเน้นไปที่ตัว Kubernetes ซึ่งมีความยืดหยุ่นสอดรับกับลักษณะงานได้หลากหลาย ตัว API ค่อนข้างเปิดกว้าง สามารถใช้งานได้แม้ไม่ใช่บน Public Cloud Provider (AWS/Azure/GCP) แต่เนื่องจากประสบการณ์ของผู้เขียนใช้งานกับทาง AWS เป็นหลักจึงจะขอยึดที่ EKS (Elastic Kubernetes Service) เป็นหลัก

Container Orchestration on AWS (ECS/EKS)

สำหรับการบริหารจัดการ container บน AWS นั้นหาก service ไม่ได้มีความสลับซับซ้อนจนเกินไป อยากแนะนำให้ลองใช้ ECS โดยการกำหนด Task/Service และกำหนดสเปคพื้นฐานก็จะสามารถใช้งานได้อย่างคร่าวๆได้แล้ว (หมายเหตุ AWS มี solution เช่น Elastic Beanstalk, App Runner ก็สามารถใช้เป็นทางลัดในการพัฒนาและสามารถใช้ container ได้เช่นกัน)

Kubernetes (K8s) เป็น Container Orchestration Project ที่ Google ได้บริจาคให้กับ Cloud Native Computing Foundation (CNCF) ซึ่งเป็นส่วนหนึ่งของ Linux Foundation (ดูแล Linux Project)
การทำงานของ Kubernetes เป็นการบริหารจัดการระบบ container ด้วย API โดยการทำงานของ Kubernetes cluster จะประกอบด้วยองค์ประกอบหลักๆดังนี้

api-server รับชุดคำสั่งของ API ผ่าน HTTP endpoint
kube-proxy เชื่อมต่อระหว่างชุดคำสั่งกับ worker node
kube-controller main loop ที่คอยจัดการกับชุดคำสั่งกับสถานะปัจจุบัน
kubelet computing resource ที่จัดการกับ container บนคอมพิวเตอร์ปลายทาง
kube-scheduler จัดการนำ workload ที่ได้รับคำสั่งไป deploy บน pod/node (kubelet) ปลายทาง

อ้างอิง: https://kubernetes.io/docs/concepts/overview/components/

AWS Networking (VPC, CIDR, Subnets)

VPC - Virtual Private Cloud สำหรับการสร้างโครงข่ายเสมือนแบบจำกัดการเข้าถึงโดยสาธารณะ กล่าวคือ การเข้าถึงจากสาธารณะสามารถทำได้หรือไม่ก็ขึ้นอยู่กับแบบร่างของโครงข่ายดังกล่าว แต่การบริหารจัดการนั้นเป็นแบบจำกัดสิทธิ์โดยผู้ใช้ AWS account นั้นๆ

CIDR - Classless Inter-Domain Routing จำเป็นสำหรับการสร้าง VPC เพื่อกำหนด IP address สำหรับ hosts/services ใน VPC
ข้อจำกัดของการใช้ CIDR ใน VPC สำหรับ Private IP address สำหรับโครงสร้างเครือข่ายขนาดใหญ่ https://aws.amazon.com/th/what-is/cidr/

Regions - สำหรับโครงข่ายในระดับโลก ของ AWS มีการแบ่งการเข้าถึงออกเป็นหลายระดับ ในระดับใหญ่สุดแบ่งจาก สถานที่บนโลกของประเทศต่างๆ เพื่อช่วยให้ความเร็วในการเข้าถึงโครงข่ายเป็นไปได้อย่างมีประสิทธิภาพสูงสุด อย่างเช่น หากการเชื่อมต่อจากประเทศไทย ไปยัง ยุโรป การเชื่อมต่อดังกล่าวจะต้องผ่านโครงข่ายข้ามประเทศหลายต่อ ซึ่งทำให้เกิดความล่าช้าที่ไม่สามารถหลีกเลี่ยงได้ กล่าวคือ หากผู้ใช้งานเชื่อมต่อกับระบบโครงสร้างที่ใกล้กว่าความเร็วของการเชื่อมต่อก็จะมีความเร็วในการเข้าใช้งานที่สูงกว่า อย่างเช่นหากระบบโครงข่ายตั้งบน สิงคโปร์แทนที่จะเป็นยุโรป ความเร็วในการเข้าถึงก็จะมากกว่าการเชื่อมต่อไปยังยุโรป
อนึ่ง ระบบโครงข่ายที่รองรับการเชื่อมต่อไปยังปลายทางเช่น CloudFront, Global Accelerator สามารถทำให้ความเร็วในการเชื่อมต่อดังกล่าวดีขึ้นได้ แต่ยังไงซะการตั้งระบบโครงสร้างเครือข่ายที่ใกล้กับฐานผู้ใช้งาน ก็จะดีกว่าในกรณีทั่วๆไป และรวมไปถึงหากมีการต้องเก็บข้อมูลที่จำเป็นต้องผ่านมาตรฐานการกำกับการเก็บข้อมูลเช่น PDPA, GDPR, HIPAA ก็จะเป็นส่วนหนึ่งในตัวแปรที่จำเป็นต้องคำนึงถึงก่อนวางโครงสร้างเครือข่าย

Availability Zones (AZ) - ในแต่ละ Region นั้นก็มีการแบ่ง data center ออกเป็นอย่างน้อย 3 ที่เพื่อการันตีว่า การให้บริการของ AWS จะไม่สะดุด เมื่อ data center หนึ่งล่มลง

Subnet - เพื่อรองรับการเชื่อมต่อไปยังแต่ละ AZ และควบคุมการเข้าถึงของ host ทั้งแบบเปิดสาธารณะ และแบบปิดการเข้าถึงแบบเป็นส่วนตัว

Security Groups + NACL

ในการทำให้การเชื่อมต่อระหว่าง เครื่องคอมพิวเตอร์บนคลาวด์ ของเราให้ปลอดภัยก็จะขาดเรื่องนี้ไปไม่ได้ หากต้องอธิบายโดยสังเขป สองสิ่งนี้คือ Firewall ที่มีการระบุเป็นระดับเครื่องและระดับเน็คเวิร์ค

Security Group - สามารถระบุการเข้าถึงเครื่องคอมพิวเตอร์ได้แบบเป็นคู่ของ Address + Port โดยที่ Address สามารถที่จะเป็น
- IPv4
- IPv6
- "Prefix-List" แบ่งย่อยได้เป็น AWS Managed กับ Customer Managed สำหรับ AWS Managed ใช้สำหรับการจัดการกับการเข้าถึงบริการของ AWS ที่อาจมีการเปลี่ยนแปลง IP Address จากภายนอกได้ ส่วน Customer Managed ไว้สำหรับการจัดการกับ IP Address ใน VPC ของผู้ใช้เองซึ่งอาจจะเป็นใน VPC ในบัญชีผู้ใช้ หรือ ภายในองค์กรเดียวกันของผู้ใช้ หรือแม้แต่ IP สาธารณะอื่นๆที่ต้องการจัดการก็สามารถทำได้

การใช้ Prefix-List จะทำให้การจัดการแบบรวมศูนย์ง่ายขึ้น อย่างเช่นการเปลี่ยนแปลงบนลิสต์จะสามารถส่งผ่านต่อไปได้โดยไม่ต้องแก้กลับไปยังปลายทาง อย่างเช่น หากมีการ shared service บน subnet เฉพาะ หาก service subnet มีการเปลี่ยนแปลง ปกติแล้วจะต้องแก้ที่ปลายทางทุกรายการ การใช้ Prefix-List จะทำให้การเปลี่ยนแปลงที่จุดตั้งต้นที่จุดเดียวก็สามารถนำไปปรับใช้ได้ทันที

"Security Group Reference" เพื่อให้การอ้างอิงไปยัง Security Group อื่นๆ สามารถทำได้โดยง่าย อย่างเช่น ต้องการกำหนดให้สามารถรับได้เพียงจาก SGR เฉพาะเพียงอันเดียว ซึ่งแม้ว่าตัว networking ข้างล่างจะมีการเปลี่ยนแปลงไป แต่ความหมายในการระบุถึง Security Group นั้นก็จะยังคงอยู่ ทำให้การระบุต้นทาง/ปลายทาง มีความแน่นอน

Note: Security Group เป็น Stateful (หากมีการตอบรับ connection ไปแล้ว คู่ของ connection นั้นก็จะถูกตอบรับไปด้วยกัน) และ Security Group สามารถคอบรับได้อย่างเดียวไม่สามารถปฎิเสธการเข้าถึงได้จากกฎของ Security Group

Network Access Control List (NACL) เป็นการสร้างความปลอดภัยให้กับโครงข่ายในระดับ subnet สามารถตั้งให้ subnet ตอบรับหรือปฎิเสธ connection ได้ด้วย สำหรับ NACL สามารถกำหนด
- Rule number
- IP Address v4,v6 (CIDR)
- Port number
- Allow/Deny โดยปกติ ค่าเริ่มต้นของ NACL จะไม่ได้มีการบล็อค กล่าวคือ Allow all หรือปล่อยผ่านให้จัดการบน Security Group เพียงอย่างเดียว

Create EKS cluster

สำหรับบทความนี้เราจะทำการสร้าง EKS Cluster ผ่านหน้า eksctl หากไม่ถนัดสามารถใช้ AWS Management console แทนได้ options จะมีความคล้ายเคียงกัน

สำหรับการ install eksctl ให้อ้างอิงจาก https://eksctl.io/installation/ โดยให้เลือก ระบบปฎิบัติการให้เหมาะสมกับเครื่องคอมพิวเตอร์ของผู้ใช้งานเป็นหลัก

สำหรับการสร้าง cluster ใหม่
eksctl create cluster -n NAME -r REGION --with-oidc --without-nodegroup --vpc-nat-mode Disable --vpc-cidr "VPC-CIDR"

Note

หากต้องการตรวจสอบความถูกต้องสามารถใส่ option --dry-run ลงไปในคำสั่งได้
หากใช้ AWS CLI จำเป็นต้องมี programmable key/session ที่ใช้งานได้เพื่อให้ eksctl คุยกับ AWS API ได้ (สามารถสร้างชุดใหม่ได้จาก User โดยที่สิทธิ์ในการเข้าถึงของ Programmable Key จะเท่ากันกับ User ที่เป็นผู้ออกชุดกุญแจดังกล่าว)
สามารถระบุ option --vpc-cidr เพื่อให้ cluster ที่สร้างใหม่แชร์ address space กับ vpc ได้โดยตรง ทำให้การบริหารจัดการจะขึ้นตรงกับการจัดการ VPC
ในทางกลับกัน --vpc-private-subnets, --vpc-public-subnets เพื่อให้ cluster ระบุให้ cluster ใช้ subnet ที่ระบุไว้ใน VPC->Subnets private-subnets, public-subnets
สำหรับการทดลองตามบทความนี้ขอแนะนำให้ใช้ --vpc-nat-mode Disable ควบคู่ไปด้วย เพราะว่า เราจะสร้างเพียง EKS Control Plane ซึ่งไม่จำเป็นต้องใช้ NAT Gateway ทั้งนี้เพื่อจะได้สะดวกในการทำลายภายหลังจากเราสามารถยืนยันได้ว่าการสร้าง Cluster ได้สำเร็จลงแล้ว
การสร้าง EKS Cluster มีค่าใช้จ่าย ทางผู้เขียนไม่สามารถรับผิดชอบกับค่าใช้จ่ายที่อาจเกิดขึ้นได้ กรุณาตรวจสอบข้อมูลของการสร้าง ก่อนที่จะทำการสร้างจริงด้วย --dry-run

Access EKS endpoints (public)

สำหรับบทความนี้ เราจะเช็คว่ามีการสร้าง EKS Cluster ที่สามารถเข้าถึงได้ผ่าน public subnet เท่านั้น (สำหรับการเข้าถึงแบบ private จะมีความซับซ้อนมากขึ้นในการจัดการ network เพื่อความง่ายต่อการจัดการ จะกล่าวถึงในบทความถัดไปด้วยการใช้ IaC Terraform)

เมื่อสร้าง Cluster เสร็จจากขั้นตอนที่แล้ว สามารถเช็คจาก การเข้าถึง Cluster endpoint ที่ทาง AWS สร้างเป็น DNS record ไว้ให้ เนื่องจากเราเปิดการเข้าถึงแบบเป็น public ตัว endpoint ที่ถูกสร้างจะสามารถเข้าถึงได้จาก public Internet (ซึ่งโดยปกติไม่แนะนำ เนื่องจากมาตรฐานด้านความปลอดภัย) เราสามารถทำ nslookup ENDPOINT โดยที่ endpoint จะมีหน้าตาประมาณนี้ EKS-CLUSTER.REGION.eks.amazonaws.com

ตรวจสอบว่า endpoint สามารถเข้าถึงได้ผ่านพอร์ต 443 (https)
สามารถใช้ nslookup, dig เพื่อตรวจสอบว่า DNS record ที่ทาง AWS จัดเตรียมให้สามารถแปลงเป็น IP Address ที่ผู้ใช้สามารถเข้าถึงได้, curl เพื่อตรวจสอบว่า endpoint สามารถตอบกลับเป็น http message ของ api ได้ (การเข้าถึง api จำเป็นจะต้องใช้ key และมีการยืนยันสิทธิ์การเข้าถึงของผู้ใช้ก่อน) ซึ่งเพื่อให้การใช้งาน api มีความสะดวกมากขึ้นบน CLI จะขอแนะนำให้ใช้งาน kubectl

kubectl ลงโปรแกรมตามลิ้งค์นี้ตามระบบปฎิบัติการ https://kubernetes.io/docs/tasks/tools/ ข้อควรระวังของเวอร์ชั่น ไม่ควรให้ kubectl version กับ EKS control plane version ห่างกันเกิน 1 เวอร์ชั่นย่อย (+/- 1) อย่างเช่นหาก EKS version 1.30, kubectl version ควรจะเป็น 1.29, 1.30, 1.31 เป็นต้น

หลังจากลง kubectl เรียบร้อยแล้ว สามารถใช้ aws eks update-kubeconfig --name NAME ไฟล์ kubeconfig จะถูก update หลังจากนั้นจะสามารถเรียก Kubernetes API ไปยัง EKS endpoint ได้
kubectl get nodes เพื่อเรียกดู worker node ในคลัสเตอร์เป็นต้น

Destroy stuffs (EKS cluster cost money)

eksctl delete cluster -n NAME -r REGION เพื่อทำการลบ Cluster ที่สร้างไว้ด้านบน
หาก ไม่ได้สร้าง NAT Gateway ตามที่แนะนำไว้ด้านบน (สร้าง Control Plane ไว้บน VPC CIDR, การลบเพียง cluster ด้วย eksctl ก็เพียงพอ

ในบทความถัดไป เราจะพูดถึง IaC (Terraform) ในการสร้าง EKS Cluster ที่สามารถรองรับ Private Networking ได้