What are the three Pod Security Standards tiers and how are they applied?

The three tiers are `privileged` (unrestricted), `baseline` (minimally restrictive), and `restricted` (most restrictive). They are set at the namespace level via labels, each with `enforce`, `audit`, or `warn` label variants to control how strictly the standard is applied.

What does a default-deny-all network policy do?

A default-deny-all network policy uses `podSelector: {}` to block all ingress and egress traffic by default, establishing a secure baseline from which you can then explicitly allow only necessary traffic.

What compliance frameworks does this skill align with?

This skill aligns with the CIS Kubernetes Benchmark (covering RBAC, audit logging, Pod Security Standards, network policies, secrets encryption, and node authentication) and the NIST Cybersecurity Framework (covering defense in depth, network segmentation, security monitoring, access controls, and logging).

Skill

Secure Kubernetes with Policy Implementation

Name: Kubernetes Security Policies
Availability: OnlineOnly
Author: Antigravity

Defense-in-depth Kubernetes security: Pod Security Standards, NetworkPolicy segmentation, RBAC, OPA Gatekeeper, and Istio mTLS.

Get skill

Works with kubernetesopa gatekeeper

Antigravity

Own this? Claim it

Spark score

out of 100

Updated yesterday

Version 15.7.0

Add to Favorites

Why it matters

Implement robust security for your Kubernetes clusters by defining and enforcing Network Policies, Pod Security Standards, and RBAC configurations. This skill helps achieve defense-in-depth and compliance.

Outcomes

What it gets done

Configure Kubernetes Network Policies for segmentation.

Implement Pod Security Standards (Privileged, Baseline, Restricted).

Set up RBAC for least-privilege access control.

Integrate OPA Gatekeeper for advanced policy enforcement.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-k8s-security-policies | bash

Overview

Kubernetes Security Policies

Defense-in-depth Kubernetes security covering Pod Security Standards (privileged/baseline/restricted), NetworkPolicy segmentation, least-privilege RBAC, OPA Gatekeeper admission control, and Istio mTLS/authorization, mapped to CIS and NIST compliance frameworks. Use when implementing network segmentation, Pod Security Standards, RBAC, admission control, or multi-tenant cluster security; use companion skills for manifest generation or GitOps policy deployment.

What it does

Provides a comprehensive guide for implementing defense-in-depth security for Kubernetes clusters using NetworkPolicy, Pod Security Standards, RBAC, and admission control - covering namespace-level pod security enforcement, network segmentation, least-privilege access, and policy-as-code enforcement with OPA Gatekeeper.

When to use - and when NOT to

Use this skill to implement network segmentation, configure Pod Security Standards, set up RBAC for least-privilege access, create security policies for compliance, implement admission control, or secure multi-tenant clusters. Do not use it for tasks unrelated to Kubernetes security policies - related skills exist for secure manifest generation (k8s-manifest-generator) and automated policy deployment (gitops-workflow).

Inputs and outputs

Pod Security Standards are set at the namespace level via labels for three tiers: privileged (unrestricted), baseline (minimally restrictive), and restricted (most restrictive), each with enforce/audit/warn label variants.

Network policies cover: default-deny-all (podSelector: {} blocking all ingress/egress), allow-frontend-to-backend (namespace-scoped pod-selector ingress rule on a specific port), and allow-DNS (egress to kube-system on UDP 53) - reference template in assets/network-policy-template.yaml.

RBAC configuration covers namespace-scoped Role (e.g. a pod-reader granting get/watch/list on pods), cluster-wide ClusterRole (e.g. a secret-reader), and RoleBinding tying subjects (users, service accounts) to a role - reference patterns in references/rbac-patterns.md.

Pod security context example locks down a pod with runAsNonRoot: true, a specific runAsUser/fsGroup, seccompProfile: RuntimeDefault, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, and dropping all Linux capabilities.

Policy enforcement with OPA Gatekeeper is shown via a ConstraintTemplate (a Rego rule requiring specific labels) and a matching Constraint applied to Deployments requiring app and environment labels.

Service mesh security via Istio covers PeerAuthentication enforcing strict mTLS cluster-wide and AuthorizationPolicy allowing traffic only from a named service-account principal.

Ten best practices: enforce Pod Security Standards at the namespace level, use Network Policies for segmentation, apply least-privilege RBAC everywhere, enable admission control (OPA Gatekeeper/Kyverno), run containers as non-root, use read-only root filesystems, drop all capabilities unless needed, implement resource quotas/limit ranges, enable audit logging, and scan images regularly.

Compliance framework alignment: CIS Kubernetes Benchmark (RBAC, audit logging, Pod Security Standards, network policies, secrets encryption at rest, node authentication) and NIST Cybersecurity Framework (defense in depth, network segmentation, security monitoring, access controls, logging).

Troubleshooting: verify NetworkPolicy support via kubectl get nodes -o wide and kubectl describe networkpolicy <name>; diagnose RBAC denials via kubectl auth can-i list pods --as system:serviceaccount:default:my-sa.

Integrations

Built on Kubernetes-native resources (NetworkPolicy, Role/ClusterRole/RoleBinding, Pod Security Standards labels), OPA Gatekeeper for policy-as-code admission control, and Istio (PeerAuthentication, AuthorizationPolicy) for service mesh mTLS and authorization.

Who it's for

Platform and security engineers hardening Kubernetes clusters - configuring Pod Security Standards, network segmentation, least-privilege RBAC, admission control, or service mesh mTLS - who want working policy templates mapped to CIS/NIST compliance requirements.

FAQ

Common questions

Discussion