We offer private, instructor-led training for application, platform, and security teams that define or consume Kubernetes workload policies and defaults.
The groups need a common interpretation of what a control protects and what a rejection means. A secure default is useful when its consumers understand the required behavior and exception boundary.
LearnKube uses an illustrative application and policy set to connect those decisions. Participants compare compatible changes, policy feedback, and the responsibilities behind an exception review.
Hands-on learning and the skills engineers take back to work.
Preview: course-wide figures are not yet available.
Teams can use Pod Security Standards as a common description of workload restrictions. Pod Security Admission separately determines whether violations are enforced, audited, or warned about. Understanding that distinction helps application, platform, and security engineers interpret the same result. The course compares policy intent, configured behavior, and workload requirements using a supplied or illustrative example.
I ask what a successful deployment proves about the policy in use. A warning, an audit record, and a rejection are different outcomes, so teams need shared evidence before concluding that a required control is enforced.
— Daniele Polencic, LearnKube founder and Kubernetes instructor
| Decision to align | Common basis | Shared exercise |
|---|---|---|
| Required protection | Workload and policy settings | Explain the control's purpose |
| Enforcement expectation | Enforce, audit, and warn | Compare admission outcomes |
| Compatible correction | Application runtime requirements | Review a rejected workload |
| Exception ownership | Evidence and approval boundary | Assess a justified variation |
Teya's DevSecOps work pairs common Kubernetes and infrastructure controls with platform-team collaboration on defaults. Office hours, guides, and training support the adoption of those practices.
For teams sharing policy decisions, we recommend a four-day workshop that connects controls to workload behavior and the evidence needed for review. A supplied or illustrative policy set gives the groups concrete decisions to compare.
This proposed agenda follows one application and its security requirements. The technical work makes differences between application changes, policy settings, and approval responsibilities visible.
Day 1
We connect images, Pods, Deployments, Services, and probes to the application's required behavior. Each role identifies which settings are application needs and which are shared restrictions.
Hands-on exercises
Day 2
We examine Helm and Kustomize defaults alongside the API and admission path. Participants distinguish what templates suggest from what the platform actually enforces.
Hands-on exercises
Day 3
We connect Services, ingress, network policies, and placement to the intended application connections. The group discusses service mesh controls without assuming every environment needs the same implementation.
Hands-on exercises
Day 4
We examine secrets, storage, resource settings, scaling, and RBAC as parts of the workload contract. Participants review the application and explain the evidence needed for any justified exception.
Hands-on exercises
Your security, platform, and application teams, shared defaults, and review boundaries can shape the agenda. Get in touch to tailor the workshop to how your teams work together.
When groups interpret a warning as proof that a policy blocks a workload, the instructor can compare admission modes on the same example. The discussion connects the required protection to observable enforcement.
Our instructor was knowledgeable, could related to real world work experience.
— Jon, Cybersecurity Engineer at Research Innovations.
Tell us which teams define and consume workload policies, which defaults or exceptions need review, and how approval responsibilities differ. We will recommend a shared technical focus and role-specific exercises.