DEV Community: devtocash

Platform Engineering 2.0 in 2026: How Internal Developer Platforms Are Eating DevOps

devtocash — Fri, 26 Jun 2026 10:29:05 +0000

Introduction

In 2023, platform engineering was a buzzword. In 2026, it's eating DevOps.

The data tells the story: Gartner predicts 80% of large engineering organizations will have a platform engineering team by 2026. The CNCF Platform Working Group released its Platform Engineering Maturity Model in late 2025. And at KubeCon North America 2025, platform engineering talks outnumbered pure Kubernetes talks for the first time.

Here's what happened: DevOps promised self-service. Developers would own their infrastructure, deploy their own code, manage their own observability. In practice, that meant every developer needed to understand Docker, Kubernetes, Terraform, Helm, PromQL, LogQL, and twelve different YAML dialects. The cognitive load crushed productivity. Developers spent 40% of their time on infrastructure toil that wasn't their specialty.

Platform Engineering fixes this. An Internal Developer Platform (IDP) takes all that infrastructure complexity and packages it behind a self-service interface that developers actually want to use. The platform team builds and runs the platform as a product, with the developers as their customers.

This guide covers what Platform Engineering 2.0 looks like in 2026 — the tools, the patterns, the anti-patterns, and a concrete path to build your first IDP.

What Is an Internal Developer Platform?

An Internal Developer Platform (IDP) is a curated, self-service layer that abstracts infrastructure complexity for application developers. It's the paved road — developers stay on the road and move fast; if they need to go off-road, they can, but the platform makes the common path effortless.

The Golden Path

Imagine an engineer joins your company on Monday. By Tuesday morning, they've spun up a new microservice with:

A GitHub repository with CI/CD pipelines pre-configured
A Kubernetes namespace with resource quotas, network policies, and RBAC
TLS certificates provisioned automatically via cert-manager
Observability: metrics, logs, and traces flowing to Grafana
A database instance with backups configured
Their service registered in the internal service catalog

All of this happens from a single catalog-info.yaml in their repo, or a self-service UI. No Kubernetes manifests. No Terraform modules. No JIRA ticket to the "DevOps team." That's an IDP.

IDP != DevOps Team

This is the most common misconception. An IDP is not a centralized DevOps team that manually provisions infrastructure for developers. That's just re-creating the pre-DevOps silo with a new name. A real IDP is automated, self-service, and governed — the platform team writes software and config that enables developer self-service. The developer clicks a button (or pushes YAML to a repo), and infrastructure appears.

For the broader context of how Platform Engineering fits alongside DevOps and SRE, see our SRE vs DevOps vs Platform Engineering comparison.

Platform Engineering vs. DevOps vs. SRE: The 2026 Dynamic

These three disciplines are distinct but overlapping. In 2026, the boundaries are clearer:

Discipline	Primary Customer	Primary Concern	Key Metric
DevOps	The deployment pipeline	Speed of delivery	Deployment frequency, lead time
SRE	The production system	Reliability	SLO attainment, error budget burn
Platform Engineering	The developer	Cognitive load, productivity	Developer onboarding time, time-to-10th-deployment

Platform Engineering is what makes DevOps scalable. When you have 5 engineers, DevOps works fine — everyone understands the infrastructure. At 50 engineers, DevOps becomes a bottleneck. At 200 engineers, without a platform, it collapses into tribal knowledge and operational chaos.

How They Interact

In a mature 2026 organization:

Platform Engineering builds and runs the IDP. They own the CI/CD templates, the infrastructure provisioning system, the service catalog, and the developer portal.
SRE owns reliability SLOs, incident response, and observability standards. They provide the platform team with reliability requirements (like "every service must expose RED metrics").
DevOps — as a dedicated role — is fading into Platform Engineering. The remaining "DevOps" is a culture: teams that build software also participate in its operation, enabled by the platform.

The platform engineering team's golden rule: platform teams build platform, stream-aligned teams build product. Neither builds both.

The Core Components of an IDP in 2026

A well-architected IDP has six core components. Every platform team should have a plan for each.

1. Developer Portal (Service Catalog)

The developer portal is the front door to your platform. It's where developers go to see all services, their owners, documentation, dependencies, and operational health.

Backstage remains the dominant open-source portal, with v3.0 released in late 2025 bringing native plugin federation. Port has gained significant market share by positioning itself as "Backstage without the maintenance burden" — a managed SaaS offering with a polished UI and simpler onboarding. Cortex leads in engineering teams focused on service quality scores and team health metrics.

Key capability in 2026 portals: scorecards. These automatically grade services on production readiness — is observability configured? Are SLOs defined? Is security scanning passing? Scorecards make governance visible and gamified.

2. Infrastructure Orchestration

This is the engine room of the IDP. When a developer declares "I need a Postgres database and a Kafka topic," the orchestration layer provisions them. In 2026, the leading approaches are:

Crossplane — Kubernetes-native infrastructure composition. You define a PostgreSQLInstance Custom Resource, and Crossplane provisions it in AWS/GCP/Azure. This is the CNCF approach and the most popular for greenfield platforms in 2026.
Terraform (HCP) — HashiCorp Cloud Platform with no-code modules lets platform teams define "golden path" Terraform modules that developers instantiate without writing HCL.
Kubernetes Operators — For Kubernetes-native workloads, operators abstract Day 2 operations. The platform team wires operators together behind a self-service interface.

3. CI/CD Templates

Developers should not write CI/CD pipelines from scratch for every service. The platform provides:

Golden pipeline templates: A single canonical pipeline that covers build → test → scan → deploy for 90% of services.
Language-specific templates: Python, Go, Node.js, Java — each with the right build tools and test frameworks pre-configured.
Deployment strategies: canary, blue-green, and rolling updates as configurable options, not custom code.

GitHub Actions reusable workflows (v2 with composable actions) and GitLab CI/CD templates dominate this space. ArgoCD remains the standard for GitOps-based deployment.

For the security side of platform pipelines, see our Kubernetes Security Best Practices guide.

4. Observability Integration

The platform doesn't just provision infrastructure — it provisions observability. When a new service is created, the platform automatically:

Scrapes Prometheus metrics via a ServiceMonitor or PodMonitor
Ships logs to Loki via the OTel Collector
Enables distributed tracing via Tempo
Creates a Grafana dashboard from the service template
Configures basic SLO-based alerts

The developer writes zero observability config. The platform handles it, with sensible defaults and an escape hatch for customization. For a complete observability implementation guide, check our OpenTelemetry Tutorial 2026.

5. Security & Compliance Guardrails

A platform that's fast but insecure is not fast — it's reckless. IDP guardrails include:

Container image scanning (Trivy, Grype) as a pipeline gate
Kubernetes network policies applied by namespace
OPA/Gatekeeper policies enforcing deployment standards
Secret management (Vault, External Secrets Operator) with no hardcoded credentials
SBOM generation and vulnerability tracking

The platform doesn't ask developers to "be secure." It makes security the path of least resistance.

6. Developer CLI & API

Every IDP needs a programmatic interface. Backstage CLI and the Platform API (REST or gRPC) let developers interact with the platform from their terminal and from automated tooling. In 2026, the CLI trend is toward natural language interfaces — see the AI section below.

Platform as Product: The Mindset Shift

The single most important idea in Platform Engineering 2.0 is treating the platform as a product. Your developers are not your subordinates — they're your customers. If your platform doesn't solve their problems, they'll route around it.

What "Platform as Product" Means in Practice

You hire (or designate) a Platform Product Manager. This person's job is not writing code. It's understanding developer pain points through user research, prioritizing the platform roadmap, and measuring adoption.
You define platform SLOs. The platform team commits to uptime, latency, and self-service SLAs. If a developer can't provision a new service in under 10 minutes, that's a platform incident.
You measure DevEx. DORA metrics measure delivery speed. DevEx metrics measure developer satisfaction: Net Promoter Score for the platform, time-to-10th-deployment, friction logs, and quarterly developer surveys.
You dogfood the platform. Platform engineers use the platform for their own tooling. If it's painful for them, it's painful for everyone.
The platform has a marketing function. Internal newsletters, office hours, and documentation that developers actually read. Adoption is built, not assumed.

The "Thinnest Viable Platform" Principle

The most common Platform Engineering mistake is building an IDP too big, too soon. Teams spend 12 months building a beautiful developer portal with every feature imaginable. They launch it. Nobody uses it.

The alternative: build the Thinnest Viable Platform (TVP). Ship something that solves one concrete problem within 4 weeks:

Week 1-2: Deploy Backstage with the GitHub integration. Now developers can see all services in one place. That's it. That's your v0.1.
Week 3-4: Add the CI/CD plugin so developers can see build status. v0.2.
Month 2: Add scaffolder templates for one language (say, Python). Now developers can create new Python services from a template. v0.3.

Each increment adds real value that developers can feel. Adoption grows organically.

The 2026 Tool Landscape

The Platform Engineering tool ecosystem has exploded since 2023. Here's the landscape organizations are navigating in 2026.

Developer Portals (The Front Door)

Tool	Model	Best For	2026 Differentiator
Backstage	Open-source (CNCF)	Large orgs with dedicated platform investment	Plugin ecosystem, v3.0 federation
Port	SaaS	Mid-size orgs prioritizing time-to-value	UX polish, no maintenance overhead
Cortex	SaaS + self-hosted	Engineering managers needing team health data	Scorecards, DORA metric dashboards
OpsLevel	SaaS	Service maturity tracking	Catalog-driven standards enforcement

Infrastructure Orchestration (The Engine)

Tool	Model	2026 Position
Crossplane	Open-source (CNCF)	The standard for Kubernetes-native IaC. Compositions define platform APIs.
Terraform HCP	SaaS + open-source	Mature, but facing competition from Crossplane for k8s-native use cases
Pulumi	Open-source + SaaS	Real language IaC (TypeScript/Python/Go); strong for platform teams that prefer code over YAML
AWS Proton / GCP Config Connector	Cloud-managed	Cloud-specific IDP building blocks; limited by vendor lock-in

CI/CD Integration

Tool	2026 Role in IDP
GitHub Actions	Reusable workflows + composable actions. Most popular for IDP pipeline templates
GitLab CI/CD	Strong CI/CD catalog; good for self-hosted requirements
ArgoCD	Standard for GitOps deploys; ApplicationSets for multi-service templating
Dagger	Container-native CI/CD; good for platform teams that want portable pipelines

2026 Trend: Convergence Around Backstage + Crossplane + ArgoCD

The most common IDP stack observed in 2026 mid-size orgs (50-200 engineers) is:

Backstage (or Port) as the developer portal
Crossplane for infrastructure composition
ArgoCD for GitOps deployment
GitHub Actions for CI pipeline templates
OpenTelemetry + Grafana for observability
External Secrets Operator for secret management

This stack is 100% open-source, CNCF-graduated or incubating, and avoids vendor lock-in.

Anti-Patterns: The Platform Engineering Graveyard

More platform initiatives fail than succeed. Here are the patterns to avoid, based on real-world postmortems from 2023-2025.

Anti-Pattern 1: "Build It and They Will Come"

The platform team spends 8 months building a perfect IDP in isolation. Launch day: developers log in, click around, and go back to their existing workflows. The platform team gets frustrated. Developers get defensive.

Fix: Involve 3-5 developer "champions" from stream-aligned teams from day one. They co-design the platform, test early versions, and become advocates within their teams. Platform adoption is a social engineering problem, not a technical one.

Anti-Pattern 2: The Platform Becomes a Bottleneck

An IDP should reduce time-to-provision from days to minutes. But bad platforms become the new bottleneck: "I need a Redis cluster" → ticket to platform team → 3 days later → "It's ready." This is worse than the DevOps silo it replaced.

Fix: If a platform action requires manual approval or manual execution by the platform team more than 10% of the time, it's not self-service. Measure time-to-provision and keep it under 10 minutes for common requests.

Anti-Pattern 3: Golden Path That's a Straitjacket

The golden path is meant to handle 80% of use cases. But if the escape hatch is sealed shut, teams with legitimate edge cases suffer. A platform that can't accommodate the data engineering team's GPU workloads or the mobile team's build requirements will be bypassed.

Fix: Golden path for common cases. Well-documented, well-tested "off-road" paths for everything else. The platform must say "here's the easy way, and here's how to go custom if you need to."

Anti-Pattern 4: Ignoring Developer Experience

A platform with powerful infrastructure capabilities but terrible UX will fail. Confusing UI, undocumented APIs, 10-step provisioning processes — developers will route around you.

Fix: Invest in UX. A platform engineer who can write Terraform but can't empathize with a frontend developer's workflow will build the wrong thing. Hire or train for product thinking.

Anti-Pattern 5: No Platform SLOs

The platform team that doesn't define SLOs can't tell if they're succeeding. "Developers seem happy" is not a metric.

Fix: Define platform SLOs: "99.9% of service provisioning requests succeed within 5 minutes," "95% of CI pipeline runs complete within 10 minutes." These are the platform's own SLOs — and the platform should burn its own error budget.

Case Study: 50-Engineer Fintech Org

Let's make this concrete with a composite case study based on real 2025-2026 implementations.

The Organization: A fintech with 50 engineers, 35 microservices, running on AWS EKS. 18 months ago, they had 12 engineers and DevOps was "Søren knows Terraform."

The Problem (at 35 engineers):

New service creation took 3-5 days: JIRA ticket → wait → manual Terraform → wait → manual CI setup
4 different CI pipeline patterns across teams — no standardization
Security scanning was inconsistent; 30% of services had no vulnerability scanning
On-call engineers couldn't find which team owned a service during incidents
Søren was the bottleneck for everything infrastructure-related

The Solution (phased over 8 months):

Month 1-2: Formed a Platform Engineering team (3 people: 2 engineers + 1 product manager from engineering). Deployed Backstage with GitHub catalog integration. Immediate win: everyone could see all services and their owners.

Month 3-4: Built Crossplane compositions for the 5 most-requested infrastructure patterns: stateless API service, Kafka consumer, cron job, Postgres RDS instance, Redis cluster. Built Backstage scaffolder templates for each. Result: new service provisioning went from 3-5 days to under 15 minutes.

Month 5-6: Standardized CI/CD pipelines using GitHub Actions reusable workflows. Enforced Trivy image scanning and OPA policies as pipeline gates. Created Backstage scorecards that gamified compliance.

Month 7-8: Integrated observability: every scaffolded service automatically got Prometheus metrics scraping, Loki log shipping, Tempo tracing, and a baseline Grafana dashboard. Defined platform SLOs and started measuring.

The Results (after 12 months):

Time to 10th deployment for new engineers: from 14 days to 2 days
Service provisioning time: from 3-5 days to under 15 minutes
Security scanning coverage: from 70% to 100%
Developer NPS for infrastructure tooling: from -12 to +38
Platform team size: remained at 3 people serving 50 engineers (a 1:17 ratio that scales to roughly 200 engineers)

The key to success: they didn't build everything at once. They shipped incrementally, measured adoption, and iterated based on developer feedback.

Originally published at devtocash.com

Kubernetes Security Best Practices 2026: Complete Hardening Guide

devtocash — Fri, 26 Jun 2026 06:35:33 +0000

Kubernetes Security Best Practices 2026: The Complete Hardening Guide

Introduction

A single misconfigured Kubernetes cluster can expose your entire infrastructure in minutes. In 2025 alone, over 60% of organizations reported at least one Kubernetes security incident — and the majority traced back to preventable misconfigurations, not zero-day exploits.

Kubernetes ships with minimal security defaults. Everything is open. Pods can talk to each other freely. Service accounts carry cluster-admin privileges by default. Secrets sit in etcd unencrypted. If you deploy a vanilla cluster and walk away, you are effectively running with the doors unlocked.

This guide walks through 4 critical security layers you must implement in any production Kubernetes cluster. Each section includes real, copy-paste-ready YAML manifests and CLI commands. Whether you run EKS, GKE, AKS, or bare-metal kubeadm clusters, these practices apply universally.

Who this is for: DevOps engineers, SREs, platform engineers, and anyone responsible for production Kubernetes clusters. You should be comfortable with kubectl and basic YAML. No prior security specialization required.

What you will implement by the end of this guide:

Fine-grained RBAC with least-privilege principles
Pod Security Admission replacing deprecated PSPs
Zero-trust network policies with default-deny
Image vulnerability scanning with Trivy in CI/CD

Let's lock it down.

1. RBAC: Least Privilege from Day One

Role-Based Access Control (RBAC) is your first and most important line of defense. The principle is simple: every user, service account, and application should have exactly the permissions it needs — nothing more.

The Problem with Default RBAC

Out of the box, Kubernetes grants the system:masters group (used by kubeadm init) cluster-admin. Every default service account in the kube-system namespace gets elevated privileges. The default service account in every namespace exists automatically and — unless you explicitly bind it — has no permissions. But many teams accidentally grant it broad access during development and forget to revoke it.

Here is the most common anti-pattern we see in production audits:

# BAD: cluster-admin bound to default service account
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dangerous-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: default
  namespace: default

This gives every pod in the default namespace unrestricted control over the entire cluster. If any pod gets compromised, the attacker owns everything.

RBAC Best Practices

1. Use namespace-scoped Roles, not ClusterRoles, whenever possible.

A Role is bound to a single namespace. A ClusterRole is cluster-wide. Most applications only need access to resources in their own namespace.

# GOOD: namespace-scoped Role for a web application
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: webapp-role
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "update"]

2. Create a dedicated ServiceAccount for every application.

Never use the default service account. Always create a named ServiceAccount and bind it to a specific Role.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: webapp-sa
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: webapp-binding
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: webapp-role
subjects:
- kind: ServiceAccount
  name: webapp-sa
  namespace: production

Then reference it in your Deployment:

spec:
  serviceAccountName: webapp-sa
  automountServiceAccountToken: true

3. Avoid wildcard verbs and resources.

Every * in your RBAC rules is a potential escalation path. Be specific:

# BAD
verbs: ["*"]
resources: ["*"]

# GOOD: explicit
verbs: ["get", "list", "watch"]
resources: ["pods", "services"]

4. Use kubectl auth can-i to verify permissions.

Before deploying, test what a service account can actually do:

kubectl auth can-i create deployments \
  --as=system:serviceaccount:production:webapp-sa \
  --namespace=production

5. Separate human users from machine accounts.

Use OIDC (OpenID Connect) for human authentication. Service accounts are for pods and CI/CD pipelines. Map OIDC groups to Kubernetes roles — never give individual users cluster-admin. Tools like Dex, Keycloak, or cloud-provider IAM (aws-iam-authenticator for EKS, GCP IAM for GKE) handle this cleanly.

6. Audit your RBAC regularly.

Run this one-liner to find overly permissive bindings:

kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

You will be surprised how many cluster-admin bindings accumulate over time. RBAC auditing tools like kubescape, kube-bench, or popeye can automate this check.

RBAC for CI/CD Pipelines

CI/CD systems (GitHub Actions, GitLab CI, ArgoCD) need API access to deploy. The pattern: create a ServiceAccount with the minimum permissions required for deployments, extract its token, and inject it into your pipeline secrets.

kubectl create serviceaccount cicd-deployer -n production
kubectl create rolebinding cicd-deployer-binding \
  --role=webapp-role \
  --serviceaccount=production:cicd-deployer \
  -n production

# For Kubernetes 1.24+, create a long-lived token:
kubectl create token cicd-deployer -n production --duration=8760h

Store that token in your CI secrets manager — never in source code.

2. Pod Security Standards & Pod Security Admission

Pod Security Policies (PSPs) were deprecated in Kubernetes 1.21 and removed in 1.25. The replacement is Pod Security Admission (PSA) — a built-in admission controller that enforces Pod Security Standards at the namespace level.

The Three Pod Security Standards

Standard	Description	Key Restrictions
Privileged	Unrestricted. Equivalent to no policy.	None. Use only for system namespaces.
Baseline	Prevents known privilege escalations. Minimum for production.	No hostNetwork, hostPID, hostIPC, hostPorts, privileged containers, or hostPath volumes.
Restricted	Hardened following Pod hardening best practices.	Everything Baseline restricts, plus: must run as non-root, seccomp profile required, capabilities dropped to NET_BIND_SERVICE only, read-only root filesystem.

Enforcing PSA with Namespace Labels

PSA uses namespace labels — no separate CRD needed. Apply a label to any namespace:

# Enforce the restricted policy on a namespace
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted

# Also set audit and warn modes for visibility
kubectl label namespace production \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

Three enforcement modes exist for each label:

enforce: reject pods that violate the policy
audit: allow but log violations to the audit log
warn: allow but show a warning to the user

Gradual rollout strategy: Start with warn and audit modes for a week. Fix all warnings. Then switch to enforce. Never jump straight to enforce=restricted on existing production namespaces — you will break running workloads.

Writing a Restricted-Compliant Pod

Here is a pod that passes the restricted Pod Security Standard:

apiVersion: v1
kind: Pod
metadata:
  name: secure-nginx
  namespace: production
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: nginx
    image: nginx:1.25-alpine
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
        add: ["NET_BIND_SERVICE"]
      readOnlyRootFilesystem: true
    volumeMounts:
    - name: tmp
      mountPath: /tmp
    - name: nginx-cache
      mountPath: /var/cache/nginx
  volumes:
  - name: tmp
    emptyDir: {}
  - name: nginx-cache
    emptyDir: {}

Key points:

runAsNonRoot: true — the container must not run as UID 0
seccompProfile: RuntimeDefault — blocks dangerous syscalls by default
capabilities.drop: ["ALL"] — strip all Linux capabilities
readOnlyRootFilesystem: true — attackers cannot write to the filesystem
allowPrivilegeEscalation: false — no setuid binaries

Exemptions (When You Need Them)

Some system workloads genuinely need privileged access — CNI plugins, CSI drivers, monitoring agents. Use namespace exemptions:

# In kube-apiserver.yaml
apiVersion: v1
kind: Pod
spec:
  containers:
  - command:
    - kube-apiserver
    - --admission-control-config-file=/etc/kubernetes/admission.yaml

And in the admission configuration:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "restricted"
    exemptions:
      namespaces: ["kube-system", "cert-manager", "ingress-nginx"]
      usernames: ["system:serviceaccount:kube-system:calico-node"]

3. Network Policies: Zero-Trust Inside the Cluster

Kubernetes networking is flat by default. Every pod can reach every other pod in the cluster, across all namespaces — with zero built-in filtering. If one pod gets compromised, it can scan your entire internal network, hit internal APIs, and pivot to databases.

Network Policies are your internal firewall. They are Kubernetes-native resources that control traffic flow at Layers 3 and 4 (IP and port level). Think of them as security group rules for pods.

Default-Deny: Lock Everything First

Start by denying all ingress and egress traffic. Then selectively open only what each application needs:

# Default deny all ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}          # selects all pods
  policyTypes:
  - Ingress

# Default deny all egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress

With these two policies in place, no pod can receive or initiate traffic. Then layer on allow rules for specific flows:

# Allow frontend → backend on port 8080
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Real-World Zero-Trust Policy Patterns

Pattern 1: Allow only from the ingress controller

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        name: ingress-nginx
  - podSelector:
      matchLabels:
        app.kubernetes.io/name: ingress-nginx

Pattern 2: Allow DNS egress only (block everything else)

egress:
- to:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: kube-system
  - podSelector:
      matchLabels:
        k8s-app: kube-dns
  ports:
  - protocol: UDP
    port: 53

Pattern 3: Allow egress only to specific external IPs

egress:
- to:
  - ipBlock:
      cidr: 10.0.0.0/8    # internal VPC only
      except:
      - 10.0.0.0/28        # except management subnet

Cilium: Beyond Basic Network Policies

If your CNI is Cilium (increasingly common in 2026 for eBPF-based networking), you get Layer 7 policies — filtering by HTTP method, path, or DNS name:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/.*"

Layer 7 policies let you declare: only GET requests to /api/v1/ endpoints are allowed — no POST, no DELETE, no /admin. A compromised frontend pod cannot abuse backend endpoints it should not access.

Testing Network Policies

Use netshoot (a network debugging container) to verify connectivity:

kubectl run netshoot --rm -it --image nicolaka/netshoot -- /bin/bash

# From inside, test connectivity:
curl backend-service.production.svc.cluster.local:8080

# Test DNS:
nslookup kubernetes.default

Always test both positive (traffic that should flow) and negative (traffic that should be blocked) cases. Network policies are easy to misconfigure — a single missing label selector can leave a hole wide open.

4. Image Security: Scan Every Container with Trivy

Running containers from untrusted or unverified images is the most common entry point for supply-chain attacks. In 2024, a compromised xz-utils backdoor nearly made it into production containers worldwide. In 2025, multiple malicious NPM and PyPI packages were found embedded in popular Docker images.

The rule: every image that enters your cluster must be scanned. Trivy, by Aqua Security, is the de-facto open-source scanner — fast, comprehensive, and CI/CD-friendly. It scans OS packages, language dependencies, and misconfigurations in a single pass.

Scanning Images

trivy image nginx:1.25-alpine

# Filter by severity — only flag HIGH and CRITICAL
trivy image --severity HIGH,CRITICAL nginx:1.25-alpine

# Output as JSON for pipeline integration
trivy image --format json --output trivy-report.json myapp:latest

# Scan filesystem for IaC misconfigurations
trivy config ./kubernetes/

Integrating Trivy into CI/CD

The most effective pattern: scan in your pipeline and block deployments for HIGH or CRITICAL findings.

GitHub Actions — Trivy scan step:

- name: Scan container image with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:${{ github.sha }}
    format: sarif
    output: trivy-results.sarif
    severity: HIGH,CRITICAL
    exit-code: 1

GitLab CI — Trivy scan job:

trivy-scan:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy image --severity HIGH,CRITICAL --exit-code 1 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  allow_failure: false

Trivy Operator: Continuous Cluster Scanning

For runtime scanning of images already deployed in your cluster, install the Trivy Operator:

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set trivy.ignoreUnfixed=true

Query vulnerability reports across your namespaces:

kubectl get vulnerabilityreports -n production
kubectl describe vulnerabilityreport replicaset-myapp-7d4f8b9c6d-nginx

Image Pinning and Digest-Based References

Never use floating tags like :latest in production. Pin to a content-addressable digest:

# BAD: floating tag, can change underneath you
image: nginx:latest

# GOOD: digest pinning, immutable reference
image: nginx@sha256:aed492c4d72c4a4e2f4d7d5e1f3b6c8a9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4

Extract the digest of any image:

docker inspect nginx:1.25-alpine | jq -r '.[0].RepoDigests[0]'

Combine digest pinning with automated PRs from Renovate or Dependabot to keep digests updated without manual toil.

Conclusion

Kubernetes security is a layered defense. Start with RBAC — if every pod runs as cluster-admin, nothing else matters. Then enforce Pod Security Standards to prevent containers from escaping their sandbox. Lock down the network with default-deny policies so a compromised pod can't pivot. Finally, scan every image with Trivy to catch vulnerabilities before they reach production.

Each of these four layers independently raises the bar. Together, they turn a wide-open cluster into a hardened environment where an attacker needs to defeat multiple defenses to cause real damage. The YAML in this guide is production-ready — copy, adapt, and apply it today.

Originally published at devtocash.com

Docker Multi-Stage Builds: Slash Your Image Size by 90%

devtocash — Thu, 25 Jun 2026 16:06:27 +0000

A typical Node.js Docker image weighs 1.2 GB. A Go binary image can be 800 MB. Most of that weight comes from build tooling, dev dependencies, and operating system packages that have no business being in a production container.

Docker multi-stage builds solve this by separating the build environment from the runtime environment. You compile your application in a fat container with all the tools, then copy only the final artifact into a minimal runtime image.

The result: images that are 10x to 50x smaller, faster to deploy, and more secure.

A multi-stage Dockerfile has multiple FROM statements. Each FROM begins a new stage. You can copy artifacts from earlier stages into later ones, leaving behind everything you do not need.

Key Topics

Introduction
How Multi-Stage Builds Work
Real-World Examples by Language
Advanced Multi-Stage Patterns
Image Size Optimization Techniques

Read the full article: https://devtocash.com/blog/docker-multi-stage-builds

Originally published at devtocash.com

Error Budgets: Stop Wasting Your SRE Team's Time

devtocash — Thu, 25 Jun 2026 15:56:19 +0000

You have a 99.9 percent SLO target. Your team is on-call, paged for every 500 error, and deployments freeze because error rates are slightly elevated. Meanwhile, your feature velocity has ground to a halt.

Error budgets exist to break this cycle. They provide a clear, data-driven framework for deciding when to prioritize reliability and when to prioritize feature development. This guide covers what error budgets are, how to calculate them, how to implement them with Prometheus, and how to build an error budget policy your team will actually use.

An error budget is the maximum amount of time or number of failures your service can experience in a given period before violating its SLO.

Key Topics Covered

Introduction
What is an Error Budget?
Calculating Error Budgets
Implementing Error Budgets with Prometheus
Burn Rate Alerts

Read the full article on DevToCash: https://devtocash.com/blog/error-budgets-sre-guide

Originally published at devtocash.com

Test Post - Error Budgets Guide

devtocash — Thu, 25 Jun 2026 15:54:00 +0000

This is a test article about error budgets in SRE.

Error budgets are a critical concept in Site Reliability Engineering that help teams balance reliability with feature velocity.

Error Budgets Will Save Your SRE Team (If You Actually Use Them)

devtocash — Thu, 25 Jun 2026 15:28:56 +0000

Error budgets will save your SRE team.

Most teams set a 99.9% SLO then burn out engineers paging for every 500 error. That's anti-SRE.

What is an Error Budget?

1 minus your SLO target. For 99.9% over 30 days, that's 43.2 minutes of allowed downtime.

Burn Rate Alerts

Fast burn (14.4x): page-level alert
Slow burn (2x): ticket-level

Read the complete guide: https://devtocash.com/blog/error-budgets-sre-guide