On 13 May 2025 I spent a morning and early afternoon at an AWS Activation Day in the Netherlands, a hands-on format for container security on Amazon EKS. The agenda mixed AWS fundamentals, a talk from the Dutch consultancy SLTN IT Services on service mesh choices for OpenShift, and two lab sessions listed as run by Isovalent (which Cisco acquired in 2024). I do not show lab consoles, and the Isovalent slides were marked confidential, so I do not describe or reproduce them. This post covers the AWS and SLTN slides and the public agenda.
The agenda
The day ran from 10:30 to 15:00, with about half of it spent in labs.
The slide listed:
- 10:30 to 10:45: Introduction and Container Security
- 10:45 to 11:00: OpenShift Mesh-up, thoughts on OSSM and Cilium
- 11:00 to 12:00: Lab 1, how to implement zero-trust security with Cilium on EKS (Isovalent)
- 12:00 to 12:45: lunch break
- 12:45 to 14:30: Lab 2, deep dive on security and observability
- 14:30 to 15:00: closing quiz and networking
AWS: container security on EKS
The opening AWS section started from the managed container services map (ECR for the image registry, ECS, EKS and Fargate for hosting) and a slide on why container security is different: scale, short-lived workloads, insecure image sources, lack of expertise, network configuration and lack of visibility.
The EKS control plane slide: it survives single-AZ events and carries a 99.95% SLA.
The next slide covered security and multi-tenancy considerations: identity and access management, network access to other containers (network policies and network encryption), noisy neighbours (limits, quotas, limit ranges, pod priority), RBAC and service accounts, pod security, policy engines such as Gatekeeper and OPA, runtime security, and data and secrets management. A detection-and-response slide then named the AWS services that watch for problems: Amazon Detective for investigations, Amazon GuardDuty for threat detection, Amazon Inspector for vulnerability management and AWS Security Hub for posture management.
The “Get started” slide offered three next steps: EKS Security Best Practices, a Container Security Activation Day and an Amazon EKS HealthCheck with a security solutions architect. The best-practices guide is public: Amazon EKS best practices guide on security. If you run EKS, read it before the next audit rather than after.
SLTN: OpenShift Service Mesh 3 and Cilium
The session branded SLTN IT Services B.V. was titled “OSSM v3.0 and Isovalent Cilium, OpenShift Service Mesh-up”. It started with the basic question, “Why do we need a service mesh?”, and the answer on the slide: microservices demand secure, observable and resilient communication, a mesh abstracts networking, security and observability away from the applications, and the benefits are mTLS, traffic control, policy enforcement and deep visibility.
The slide framed both OpenShift Service Mesh and eBPF-based meshes as valid options.
The most useful slide for me was the one on OpenShift Service Mesh 3 (Istio ambient):
- it uses the Istio control plane to define mesh policies
- ambient mode removes sidecars and adds ztunnel (L4 mTLS) and waypoints (L7 features)
- it still relies on user-space proxies and traffic redirection
- ambient mode was still in Technology Preview at the time
- it integrates with OpenShift monitoring and Kiali for visualisation
OSSM 3 with Istio ambient, including the caveat that it was Technology Preview in May 2025.
The contrast the talk set up is the one I use with clients: ambient removes the per-pod sidecar, but the data path still goes through user-space proxies, while Cilium implements networking, policy and mesh features with eBPF in the kernel. I compare the two in more depth in Cilium vs Istio: Service Mesh Comparison.
Observability: Kiali and Prometheus on the OSSM side, Hubble UI and Grafana on the Cilium side.
Isovalent: Cilium labs on EKS
The agenda lists two Isovalent-run labs after the SLTN talk: zero-trust security with Cilium on EKS, then a deeper lab on security and observability. Isovalent publishes this style of lab openly, short and browser-based, at isovalent.com/labs, so you can repeat them without an event. I am not describing the lab content or the Isovalent presentation here.
My take
The pairing was sensible. The AWS part gave the checklist (identity, network policy, runtime, secrets), and a hands-on lab on the CNI is a fitting way to practise the network items on that checklist. If you are choosing between a sidecar-free mesh and eBPF networking, the key questions are whether you need L7 policy everywhere, who operates the control plane, and how you will observe flows. For the policy side, see Kubernetes Network Policies and Zero Trust and Cilium and eBPF for Kubernetes networking and security.
