Jan 16
Loading video player...
Stop giving every pod the keys to your kingdom! In this live workshop we dive deep into Kubernetes Service Accounts and show why the default account is (thankfully) locked down—then demonstrate how a more-privileged SA can delete its own Deployment with a single cURL call. What you’ll learn How every pod automatically receives a token that can talk to the Kubernetes API. Why running with the default service account usually results in a 403 “Forbidden.” Creating / assigning a custom Service Account with higher RBAC privileges. Using curl inside a pod to delete its own Deployment (live demo). Best practices: follow least-privilege, audit SA tokens, and never ship unnecessary privileges. ⏱ Timestamps 00:00 Intro & goal of the exercise 00:32 Default Service Account and mounted API token 02:00 Shell into the pod & locate the token 03:00 Using curl to call the Kubernetes API (gets 403) 03:55 Listing available Service Accounts 04:30 Patching the Deployment to use a privileged SA 05:15 Successful API delete call – pod kills itself 06:10 Takeaways & security tips Resources ► Sample YAML & commands – GitHub link ► Kubernetes Service Accounts & RBAC docs – https://kubernetes.io/docs/ ► Blog: Automating token rotation & SA auditing – link If this helped tighten your cluster security, like & subscribe for weekly Kubernetes & DevSecOps content. Got questions? Drop them below—I reply to every comment! 🔐🚀