AWS Summit Bangkok 2026

For audience to follow along or catch up later on.

Transcript

1. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.
2. D e v e l o p e r Z o n e : L i g h t n i n g T a l k s EKS Hardening: Defense- in-Depth and Policy-as- Code with Kyverno V-ris Jaijongrak AWS Community Builder Lead Platform Engineer at Pi Securities PCL © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.
3. Contact me LinkedIn: Speaker Deck:
4. Key Takeaways After this session, you will learn • How to strategize hardening your Cloud with Defense-in- depth and Zero-trust principle • Insights of Hardening the Kubernetes cluster (EKS) with Best Practices • How the policy-as-code can help you re-design Security Strategy inside the clusters
5. Agenda • Introduction • Security Implementation in AWS • Tools and Approach to enhance EKS Security
6. If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology. Bruce Schneier
7. Defense-in- depth strategy Multi-layered defense strategy to minimize the attack plane, severity in multiple parts of the architectures - Network Accessibility (Allowed Lists, WAF, NACL, Security Groups) - Secure Software and its supply chain (establishes trust of secure software) - Authentication and Authorization (who performs what) - Data Security (Encryption, Backup and restore, HA, DR) - Network Instrumentation (audit)
8. Zero-trust Until the trust is “earned”, you should never trust the requester without confirming the credentials This is important especially if the confidentiality is non- negotiable with that being the case, securing the network (via tunneling/encryption, mTLS) Without the trust being established, only non destructive, non secretive operations can be performed
9. Kubernetes & Service Account Cloud Native platform emphasizes on the container orchestration solution There are various ways to provision Kubernetes cluster on AWS but the most common would be via EKS (Elastic Kubernetes Service) RBAC (authorized entities) can perform actions in K8s environments For Services, roles are provided for Service Accounts
10. IAM Policy, IAM Role IAM controls who (identities) can do what (actions) on which resources, based on explicitly defined permissions. Each policy can then be set its effect to be allowed/denied. Principal is mandatory for the resource-based policies. (as identity- based is explicitly defined via association, but resources such as S3 bucket has no such thing) IAM Role uses this concept to authorize the access to AWS services to authenticated identities
11. IRSA -> EKS Pod Identity Previously, IRSA (Iam Role for Service Accounts) are used to map RBAC for Services Accounts in EKS (via OIDC and STS) This has a real caveat with large scale clusters which can easily overwhelm the requests to STS and bottleneck the scaling EKS Pod Identity can help alleviate the issue via caching the responses on node (i.e., the same repetitive request can be responded from the cache instead of individually repeating the same request/response)
12. Kubernetes Security Standard PSS (Pod Security Standard) describing how pods should be secured, the most common would be: runAsUser, runAsGroup, allowPrivilegeEscalation, privileged, capabilities
13. Network Policies Network Policies describing how pods communications are allowed/denied.
14. Kubernetes Security Tools • In-depth Kubernetes security requires Observability solution to ensure that the malicious activities are properly handled • OTEL (Open Telemetry) can be used to expose logs/traces/metrics • Falco can be used to audit the events within the cluster • Controlling Admission Policy (for dynamic via webhooks) is a challenging task for wide-range used of permissions in the cluster. • Container Image Scan
15. Policy-as-code (PaC) Similar to IaC (Infrastructure as Code), this pattern describe security policy as code so that the benefit of IaC are adopted. Portability, Idempotent, Stateless policies can then be adopted onto Kubernetes cluster (or PaC compatible) Once defined, it can be easily portable to control components with similar nature. Famous adaptations are OPA (Open Policy Agent) and Kyverno
16. Graduated CNCF Project (Security & Compliance) famous for Policy as Code targeting Kubernetes Policies are broadly defined for real world use-cases with report (OpenReports) support built-in Many examples and playgrounds are made available to make it easy for early adaptations and testing Kyverno
17. System Architecture Plain EKS with private networking example terraform can be found in:
18. Policy Demo Applying Kyverno in the cluster with my dev.to blog can be found here:
19. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Summary S T R A T E G Y Defense-in-Depth Multi-layered security across network access, supply chain, auth & authorization, data encryption, and audit instrumentation. P R IN C I P L E Zero-trust No requester is trusted until credentials are confirmed. Untrusted entities are limited to non-destructive operations only. A R C H IT E C T U R E Private EKS Cluster EKS nodes in private subnets. Only Bastion/VPN & NAT Gateway in public subnet. Minimal internet-facing surface area. A W S & K U B E R N E T E S S E C UR I T Y ST A C K IAM Roles & Policies EKS Pod Identity RBAC Pod Security Standards Network Policies Falco · OpenTelemetry Container Image Scanning Pod Identity improves on IRSA by caching STS responses at the node level, avoiding bottlenecks at scale. PSS enforces runAsNonRoot, no privilege escalation, and dropped capabilities. P O L I C Y - A S - C O D E · K Y V E R N O ( C N C F G R A D UA T E D ) apiVersion: kyverno.io/v1 kind: ClusterPolicy spec: validationFailureAction: Enforce rules: - name: check-run-as-non-root validate.pattern: runAsNonRoot: true Portable · idempotent · stateless · version-controlled security. OpenReports compliance built-in.
20. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Please complete the session survey in the mobile app Thank you