Ship It Weekly - DevOps, SRE, Platform and Cloud Engineering News

This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.In this Ship It Conversations episode, I talk with Erik Osterman of Cloud Posse about Terraform modules, infrastructure as code frameworks, internal developer platforms, and why AI makes conventions more valuable, not less.Erik is the founder and CEO of Cloud Posse, which has published more than 180 open source Terraform modules, and he hosts Cloud Posse's weekly DevOps Office Hours.We start with what AI has done to open source infrastructure projects, then get into what makes a good Terraform module: consistent naming, a consistent interface, not so small that it wraps a single resource, and not so large that it has a hundred inputs nobody can test.We also talk about CloudFormation, Pulumi, and why HCL's constraints helped build the module ecosystem. Erik explains where Crossplane fits, and why accounts, IAM, networking, DNS and certificates all come before the cluster.A big part of the conversation is frameworks. Erik argues that nobody actually runs "vanilla Terraform," because Terraform alone doesn't handle state layout, promotion, authentication, tool installation or repository structure. Every team ends up building its own framework, usually undocumented. We talk about Terragrunt, Atmos, naming conventions, brownfield adoption, and breaking a monolithic root module into services.Near the end, we get into AI and self-service. Erik's team now generates most of its infrastructure work with AI, and it works because the conventions, agent skills, MCPs and pipelines are already in place. Self-service doesn't have to mean another no-code platform.The big takeaway: AI can generate infrastructure code faster than ever, but without conventions it is generating into chaos.Highlights• What makes a good Terraform module• Root modules vs. child modules• CloudFormation, Terraform, Pulumi, and why constraints helped HCL win• Where Crossplane fits, and what has to exist before the cluster• Why internal developer platforms like Backstage come after zero-to-one• Why infrastructure as code needs frameworks, not just modules• Agent skills, MCPs, and self-service without a no-code platformLinksCloud Posse: https://cloudposse.comAtmos: https://atmos.toolsCloud Posse on GitHub: https://github.com/cloudposseDevOps Office Hours: https://tsn.io/2gq7vErik Osterman on LinkedIn: https://www.linkedin.com/in/ostermanMore episodes and show notes: https://tsn.io/NqkdPOn Call Brief: https://tsn.io/Gpz2dLMGT Awards: https://lmgt.org

This week on Ship It Weekly: AWS is retiring Amazon DevOps Guru and pointing customers toward CloudWatch and the newer Amazon DevOps Agent. Kubernetes disclosed a vulnerability where StatefulSet and ControllerRevision permissions can allow cross-namespace pod creation under specific conditions. A vulnerability in Undici can let a malicious WebSocket server crash a Node.js process through compressed data. And Cloudflare launched a new CLI as AI agents grow from 25 percent to 48 percent of Wrangler usage.The bigger theme this week is how the systems around our infrastructure are changing. Managed cloud services still have lifecycles that eventually become migration work. Kubernetes authorization can depend on what controllers do with the resources users are allowed to manipulate. Applications acting as clients still process untrusted data. And infrastructure tooling is starting to treat AI agents as first-class users rather than humans who happen to automate commands.In the lightning round: another Kubernetes vulnerability affecting Windows nodes can expose NetNTLMv2 credentials through NTLM coercion. GitHub now supports custom runners for Dependabot version and security updates. And external systems like a CMDB or internal developer portal can push repository properties into GitHub while remaining the source of truth.And the human closer comes from Lorin Hochstein and SRE Weekly. Some availability risks are probably never going away. Resources are finite, networks fail, security controls can affect availability, and production systems have to change. Preventing individual failures still matters, but incident response is part of reliability engineering too. Sometimes improving reliability means getting better at handling the failures you cannot eliminate.LinksAmazon DevOps Guru End of Support - https://tsn.io/GQHN8Kubernetes CVE-2026-2270: Cross-Namespace Pod Creation - https://tsn.io/BsNs8Undici CVE-2026-85024: WebSocket Denial of Service - https://tsn.io/LncLdCloudflare: Introducing the cf CLI - https://tsn.io/Wk3maCloudflare Forge - https://tsn.io/bAPJuLightning RoundKubernetes CVE-2026-76654: Windows NTLM Coercion - https://tsn.io/36Kc3GitHub: Custom Runners for Dependabot - https://tsn.io/tYl9KGitHub: External Custom Properties - https://www.tellerstech.com/go/s-1fd1396d/Human CloserOmnipresent Availability Risks in Cloud Software - https://www.tellerstech.com/go/s-076db9dd/Our LinksThis Week’s On Call Brief - https://tsn.io/fKB9VShip It Weekly - https://tsn.io/NqkdPOn Call Brief - https://tsn.io/Gpz2d

This week on Ship It Weekly: GitHub Actions workflow execution protections are now generally available, giving organizations more control over who and what can trigger individual workflows. Cisco is patching critical vulnerabilities in Secure Email Gateway, including an actively exploited issue that can lead to remote command execution as root. Helm 3 has reached its final minor release and is heading toward end-of-life in February 2027. And GitHub’s ubuntu-latest Actions runner is preparing to move from Ubuntu 24.04 to 26.04.The bigger theme this week is infrastructure that changes even when your code does not. GitHub is making CI execution permissions more explicit, Helm teams now have a defined migration deadline, and the ubuntu-latest transition is a good example of how a completely unchanged workflow can suddenly be running in a different environment. Pinning everything forever is not necessarily the answer. The important part is knowing which dependencies are allowed to move and testing those changes deliberately.In the lightning round: GitHub Actions checks, workflow runs, and statuses will begin following your configured retention period on October 1. GitHub Advanced Security can now enforce configurations from the enterprise level. GitHub added API support for tracking when self-hosted Actions runner versions lose support. And AI Scan for pull requests can now be used without requiring CodeQL default setup.And the human closer starts with a sentence almost every infrastructure engineer has heard during an incident: “But nothing changed.” Maybe nothing changed in the application, but the runner image changed, a dependency moved, a certificate expired, DNS changed, or an external service behaved differently. Latest tags, loose version constraints, external APIs, and even support windows are dependencies. The goal is not to freeze everything forever. It is to avoid accidental mutability, where something can change without the team realizing it was ever allowed to change.LinksGitHub Actions Workflow Execution Protectionshttps://tsn.io/fbqifCisco Secure Email Gateway Security Advisoryhttps://tsn.io/jX2wkHelm 3 End of Lifehttps://tsn.io/Ii7jbUbuntu 26.04 GitHub Actions Runners and ubuntu-latest Migrationhttps://tsn.io/7IJ9kGitHub Actions Retention Changeshttps://tsn.io/idFxyGitHub Advanced Security Configuration Enforcementhttps://tsn.io/8vRMxGitHub Actions Self-Hosted Runner Lifecycle APIhttps://tsn.io/9UhY1GitHub Code Scanning AI Scanhttps://tsn.io/ULAVWThis Week’s On Call Briefhttps://www.tellerstech.com/go/26w38/Ship It Weeklyhttps://tsn.io/NqkdPOn Call Briefhttps://tsn.io/Gpz2d