4 posts tagged with "devsecops"

A security scanner gave our main site 49/100, "Critical CSP gaps". There was no Content-Security-Policy at all, the favicon alone weighed 601 KB, and nobody had looked at how the frontends were cached or compressed.

The stack: three React + Vite single-page apps, each served by nginx in a container, behind a host nginx and Cloudflare, talking to FastAPI backends. Two environments, dev and prod, on two VPSs.

Managed Kubernetes hands you workload identity. AKS runs an OIDC issuer for the cluster, publishes its discovery documents, and Entra already trusts them — a pod gets an Azure token and nobody thinks about it.

On plain VMs, none of that exists. The nodes have no Azure identity to assume, and the workloads still need Key Vault and Blob Storage. The default answer at that point is a service principal secret in a Kubernetes Secret: a static cloud credential, sitting on a node, rotated by nobody. It is the same credential CI pipelines are still carrying, in a different place.

There is a better answer, and the cluster already does most of it. Every Kubernetes cluster signs service-account tokens with a private key. Those tokens are already OIDC-shaped JWTs. Publish the public half over HTTPS, point Entra at it, and the cluster becomes an identity provider it always was.

This is what that took on a production RKE2 cluster running on bare VMs.

Long-lived cloud credentials in CI are the most reliably exploited secret in any organisation. They are copied into a settings page once, they never expire, and nothing tells you when one leaks. Federated identity — OIDC — removes them: the pipeline presents a short-lived token that the cloud verifies against your CI provider, and no static key exists to steal.

The migration is genuinely worth doing. It also fails, almost always, at exactly one step.

A comprehensive learning resource for DevOps professionals, security teams, and developers new to automated security scanning