DEV Community: Amaresh Pelleti

Microsoft Defender for Cloud Now Protects AWS RDS

Amaresh Pelleti — Fri, 24 Jul 2026 18:43:41 +0000

Microsoft Defender for Open-Source Relational Databases went generally available for AWS RDS on June 1, 2026, and billing started that same day. If you were running it in preview, nothing breaks — you keep the same protection. If you haven't touched it yet, this is the setup: which engines it covers, the exact portal steps, and the IAM permissions it needs on the AWS side.

This matters specifically if you're running Azure as your primary security posture tool but keeping databases in AWS RDS — which is a more common split than it sounds, especially in shops that grew through acquisition or multi-cloud contracts.

What Changed for Defender for Cloud on AWS RDS

Before June 1, this was a preview feature. Now it's GA, which in Microsoft's terms means billing is active and the feature is fully supported rather than best-effort. If you enabled it before the GA date, you keep receiving database threat protection and sensitive data discovery without doing anything — Microsoft carried preview users forward automatically.

The plan detects and investigates unusual activity in your RDS databases: unexpected query patterns, suspicious login attempts, and access from anomalous locations. It also runs sensitive data discovery against your AWS account and feeds those findings into your broader security posture, a capability shared with Defender Cloud Security Posture Management (CSPM).

Which Database Engines Are Covered

Five RDS instance types are supported:

Aurora PostgreSQL
Aurora MySQL
PostgreSQL
MySQL
MariaDB

That's the full list — SQL Server and other proprietary engines on RDS aren't part of this specific plan. If you're running those, you're looking at a different Defender for Databases offering.

Prerequisites Before You Enable It

Four things need to be true before you start:

You need an active Azure subscription.
Defender for Cloud must already be enabled on that subscription.
You need at least one AWS account already connected to Defender for Cloud, with the access and permissions that connection requires.
Your RDS instances need to be in a supported region — this plan covers all public AWS regions except Tel Aviv, Milan, Jakarta, Spain, and Bahrain.

If you haven't connected an AWS account to Defender for Cloud at all yet, do that first — it's a separate onboarding step from what's covered here.

Step-by-Step: Enabling Defender for Cloud on AWS RDS

Sign in to the Azure portal.
Search for and select Microsoft Defender for Cloud.
Select Environment settings.
Select the relevant AWS account.
Find the Databases plan and select Settings.
Toggle open-source relational databases to On.
Select Configure access.
In the deployment method section, select Download.
Follow the instructions to update the CloudFormation stack in your AWS account — this creates or updates the template with the permissions Defender needs.
Confirm the checkbox that the CloudFormation template was updated in your AWS environment.
Select Review and generate.
Review the summary and select Update.

Turning the plan on also enables sensitive data discovery for RDS resources automatically — it's a shared feature with Defender CSPM, so you don't configure it separately.

What Defender Changes in Your RDS Parameter Groups

This is the part that catches people off guard: enabling the plan doesn't just add a monitoring agent, it modifies parameter and option group settings on your actual RDS instances so Defender can consume audit logs. You don't set these manually — Defender configures them for you — but you should know what's changing before you flip the toggle.

For PostgreSQL and Aurora PostgreSQL, Defender sets log_connections and log_disconnections to 1. For Aurora MySQL cluster parameter groups, it turns on server_audit_logging and expands server_audit_events to include CONNECT and QUERY.

MySQL and MariaDB use an option group instead, built around MARIADB_AUDIT_PLUGIN. Defender expands SERVER_AUDIT_EVENTS to include CONNECT and adds rdsadmin to the excluded users list so its own service account doesn't get logged as suspicious activity.

⚠️ Important: MARIADB_AUDIT_PLUGIN only works on MariaDB 10.2 and later, MySQL 8.0.25 and later, and all MySQL 5.7 versions. If you're running something older, the plan can't fully instrument that instance. You'll likely also need to reboot affected instances for parameter changes to take effect — plan that maintenance window before you enable this in production, not after.

If you're using the default parameter group, Defender doesn't modify it directly — it creates a new group prefixed defenderfordatabases* and applies it instead.

Required AWS Permissions for Defender for Cloud on RDS

The CloudFormation stack creates a role called DefenderForCloud-DataThreatProtectionDB with a specific, scoped set of RDS permissions — not broad admin access. The role can describe and modify parameter groups, option groups, and DB instances/clusters, tag resources, and download log file portions. It cannot delete databases, modify security groups, or touch IAM itself.

If your security team reviews IAM changes before they land — and they should — this is a reasonable role to point them at. It's purpose-built for exactly what the plan needs: reading and writing audit-related configuration, not general database administration.

For the exact permission list and current pricing, check the official setup guide and the Defender for Cloud pricing page — Microsoft updates both directly rather than through this kind of write-up, so they're the source of truth for anything billing-related.

Frequently Asked Questions

Q: Do I need to do anything if I already had this enabled in preview?
A: No. Preview users carried forward automatically on June 1, 2026, and continue receiving protection without re-enabling anything.

Q: Does this cover Amazon Aurora specifically, or just standard RDS?
A: Both Aurora PostgreSQL and Aurora MySQL are covered, alongside standard PostgreSQL, MySQL, and MariaDB instances.

Q: Will enabling this require downtime on my RDS instances?
A: Possibly. Parameter group changes to static parameters don't take effect until the instance reboots, so plan a maintenance window rather than enabling this against production without notice.

Q: Can I disable it later without losing other Defender CSPM features?
A: Yes. Disabling open-source relational database protection just toggles that specific plan off in Environment settings — it doesn't affect other Defender for Cloud plans on the same AWS account.

Quick Summary:

Defender for Open-Source Relational Databases on AWS RDS went GA June 1, 2026; preview users carried forward automatically
Covers Aurora PostgreSQL, Aurora MySQL, PostgreSQL, MySQL, and MariaDB — not SQL Server or other proprietary engines
Setup is entirely in the Azure portal, but requires updating a CloudFormation stack in your AWS account
Enabling it modifies RDS parameter/option groups to enable audit logging — some instances need a reboot
The DefenderForCloud-DataThreatProtectionDB role is scoped to audit configuration, not general database admin

Check your RDS engine version against the MARIADB_AUDIT_PLUGIN compatibility requirements before you enable this — an unsupported engine version means partial coverage without an obvious warning.

GPT-5.6 Explained: Sol, Terra, and Luna Pricing

Amaresh Pelleti — Fri, 24 Jul 2026 18:43:00 +0000

GPT-5.6 launched publicly on July 9, 2026, after a limited preview to trusted partners on June 26. It ships as three separate models instead of one — Sol, Terra, and Luna — priced and positioned differently enough that picking the wrong one for your workload is an easy way to overpay.

Here's what each tier is actually for, the exact per-token pricing, and how OpenAI's own benchmark claims stack up against Anthropic's Fable 5.

What Is GPT-5.6

It's OpenAI's next model family after GPT-5.5, split into three tiers instead of a single flagship release. Sol is the top tier — OpenAI calls it its "workhorse" and "best coding model yet," built for complex reasoning, coding, and agentic workflows. Terra sits in the middle. Luna is the fastest and cheapest of the three.

The staggered rollout — limited preview June 26, public release July 9 — was reportedly tied to U.S. government review requirements before wider availability, rather than a technical readiness issue on OpenAI's end.

Sol, Terra, and Luna: The Three GPT-5.6 Variants

Sol is positioned as the model for serious work: enterprise tasks, coding, scientific research, and security work. OpenAI also calls it its "strongest cybersecurity model yet," citing use in threat modeling, code review, patching, and blue-teaming. Sol is also described as the operating agent behind ChatGPT Work.

Terra is the middle tier — according to OpenAI, it's competitive with the previous GPT-5.5 flagship while costing about half as much. If your workload doesn't need Sol's coding-specific strength, Terra is the tier to default to.

Luna is the fastest and most budget-friendly of the three, aimed at high-volume, cost-sensitive use rather than complex reasoning tasks.

How Sol Compares to Claude Fable 5

OpenAI's specific claim, per Sam Altman: Sol is 54% more token-efficient on coding tasks than its predecessor. Independently, on the Artificial Analysis Coding Agent Index, Sol scored 80 — 2.8 points ahead of Anthropic's Fable 5 — while using less than half the output tokens and costing roughly one-third less for a comparable task.

⚠️ Note: Benchmark scores from any single index are a snapshot, not a guarantee of real-world performance on your specific codebase. Treat the Coding Agent Index number as a starting point for evaluation, not a replacement for testing Sol against your own AI coding workflow before switching.

GPT-5.6 Pricing

Pricing is per million tokens, and the spread between tiers is significant:

Model	Input	Output
Sol	$5.00	$30.00
Terra	$2.50	$15.00
Luna	$1.00	$6.00

Sol costs five times more per input token than Luna, and the output cost gap is even wider. If you're running high-volume, low-complexity tasks — classification, simple extraction, short-form generation — Luna's pricing makes it the obvious default rather than reaching for Sol by habit.

What Changed From GPT-5.5

The headline change isn't a single smarter model — it's three models, tiered explicitly by cost and capability instead of OpenAI picking one balance point for everyone. Terra matching GPT-5.5's capability at roughly half the price is the more interesting shift for most users than Sol's coding gains, since Terra is likely the tier most general ChatGPT and API usage defaults to.

For teams already comparing AI tool options, the three-tier pricing structure is closer to how open-source LLMs are typically offered — pick your cost/capability point explicitly — than OpenAI's previous single-flagship approach.

Getting Access to GPT-5.6

GPT-5.6 is available through ChatGPT, Codex, and the OpenAI API as of the July 9 public release. Sol specifically powers ChatGPT Work as its operating agent, so if your organization is on that tier, you're likely already interacting with Sol rather than Terra or Luna by default.

Frequently Asked Questions

Q: Which GPT-5.6 model should I use for coding?
A: Sol. OpenAI built it specifically for complex reasoning and agentic coding work, and it's the tier benchmarked against Anthropic's Fable 5 for coding-agent performance.

Q: Is Terra worth using over Sol for general tasks?
A: For most non-coding use, yes — Terra is reported to match GPT-5.5's capability at about half the cost, which makes it the more efficient default for general-purpose work.

Q: Why was GPT-5.6 released in two stages?
A: A limited preview went to trusted partners on June 26, with the public release following on July 9 — reportedly due to government review requirements rather than a technical delay.

Q: Does GPT-5.6 replace GPT-5.5 in ChatGPT immediately?
A: It's available now through ChatGPT, Codex, and the API. OpenAI hasn't published a forced sunset date for GPT-5.5 access in the sources checked for this article.

Quick Summary:

GPT-5.6 launched publicly July 9, 2026, after a June 26 limited preview
Three tiers: Sol (flagship, coding/reasoning), Terra (balanced, ~half GPT-5.5's cost), Luna (fastest, cheapest)
Sol scored 80 on the Artificial Analysis Coding Agent Index, 2.8 points ahead of Anthropic's Fable 5
Pricing per million tokens: Sol $5/$30, Terra $2.50/$15, Luna $1/$6
Available now via ChatGPT, Codex, and the OpenAI API; Sol powers ChatGPT Work

Match the tier to the task before you default to Sol for everything — Terra's price-to-capability ratio is the bigger practical shift in this release for most non-coding workloads.

Terraform Helm Provider Migration: v3 Breaking Changes

Amaresh Pelleti — Fri, 24 Jul 2026 18:42:17 +0000

If your terraform plan started throwing schema errors after a routine provider update, you're probably looking at the Terraform Helm provider migration from v2 to v3. HashiCorp rewrote the provider on top of the Terraform Plugin Framework in v3.0.0, and it changed how you write set, kubernetes, and registry configuration — not just internally, but in your actual .tf files.

The latest release is v3.2.0, published June 4, 2026. Here's exactly what changed, the before/after syntax, and the state upgrade errors people are hitting in the GitHub issue tracker.

What the Terraform Helm Provider Migration Changed

Three things break when you jump from v2.x to v3.x:

set, set_list, and set_sensitive inside helm_release and helm_template go from repeatable blocks to a single list attribute of nested objects.
The kubernetes block on the provider becomes a single object attribute (kubernetes = { ... } instead of kubernetes { ... }).
The registry block — which used to support multiple repeated blocks — becomes a registries list attribute.

None of these are cosmetic. Terraform's plugin framework handles blocks and list-of-object attributes differently in state, which is why a straight version bump without touching your HCL will fail to plan.

Why HashiCorp Migrated to the Plugin Framework

The old provider ran on Terraform Plugin SDKv2, which HashiCorp has been retiring across its provider ecosystem in favor of the newer Plugin Framework. The framework uses Terraform Plugin Protocol Version 6, compatible with Terraform 1.0 and above, and gives providers more precise control over schema validation and state handling than SDKv2 allowed.

For the Helm provider specifically, that meant converting the repeatable-block pattern (common in SDKv2-era providers) into list attributes, which the framework models more cleanly. It's the same category of change other HashiCorp providers have gone through — annoying for a version bump, but not unique to Helm.

Migrating set, set_list, and set_sensitive Blocks

This is the change you'll hit in almost every helm_release resource. Before v3, you wrote repeated set blocks:

resource "helm_release" "example" {
  name  = "my-release"
  chart = "my-chart"

  set {
    name  = "service.type"
    value = "ClusterIP"
  }
}

In v3, set is a list of objects instead:

resource "helm_release" "example" {
  name  = "my-release"
  chart = "my-chart"

  set = [
    {
      name  = "service.type"
      value = "ClusterIP"
    }
  ]
}

The same conversion applies to set_list and set_sensitive — both change from repeated blocks to list-of-object attributes, in both helm_release resources and the helm_template data source. If you have five set blocks in a release today, they collapse into one set = [...] attribute with five entries.

Migrating the kubernetes and registry Blocks

The provider-level configuration changes too. kubernetes goes from a block to a single object:

# Before — v2.x
provider "helm" {
  kubernetes {
    config_path = "~/.kube/config"
  }
}

# After — v3.x
provider "helm" {
  kubernetes = {
    config_path = "~/.kube/config"
  }
}

registry is the trickier one, because it wasn't just a block-to-object change — it also went from singular to plural, since the provider supports multiple registries:

# Before — v2.x
provider "helm" {
  registry {
    url      = "oci://localhost:5000"
    username = "username"
    password = "password"
  }
}

# After — v3.x
provider "helm" {
  registries = [
    {
      url      = "oci://localhost:5000"
      username = "username"
      password = "password"
    }
  ]
}

If you had multiple registry blocks before, they all move into the same registries list, one object per entry.

State Upgrade Errors During the Terraform Helm Provider Migration

Two issues show up repeatedly in the terraform-provider-helm GitHub tracker. The first: existing state written under v2.x sometimes isn't read correctly after upgrading to v3, because the state upgrader doesn't always cleanly translate the old block-based schema into the new object/list schema. The second, tracked separately, is the provider failing to upgrade resource state to v3 at all in certain configurations.

HashiCorp shipped a hotfix in v3.0.1 (the same day as v3.0.0) specifically for a state upgrader bug affecting the values attribute type — so if you hit an error mentioning values, make sure you're on at least v3.0.1, not v3.0.0.

⚠️ Note: Run terraform plan in a non-production workspace first after the upgrade. If the plan shows unexpected diffs on resources you didn't touch, that's usually the state upgrader mismatch, not a real infrastructure drift. Don't apply until the plan is clean.

Should You Run the Terraform Helm Provider Migration Now

If you're still pinned to a 2.x version, there's no forced deadline, but 2.x isn't getting new features — the changelog shows all active development going into 3.x since mid-2025. The safer path is a deliberate migration rather than an accidental one: pin your provider version explicitly, do the HCL rewrite in a branch, and test the plan against a non-production state before rolling it into your main branch.

If you've already been through a Helm 4 migration on the chart side, this is a smaller lift by comparison — it's syntax, not runtime behavior. The version history since 3.0.0 has been mostly bug fixes and small additive features, not further breaking changes:

v3.0.0 (June 18, 2025) — the breaking migration itself
v3.0.1 (June 18, 2025) — state upgrader hotfix for values
v3.0.2 (June 23, 2025) — fixed plan errors on version specs, postrender execution, sensitive value redaction
v3.1.0 (Oct 27, 2025) — added qps, resources, set_wo, take_ownership, configurable operation timeouts
v3.1.1 (Nov 17, 2025) — fixed an "inconsistent result after apply" error
v3.1.2 (May 21, 2026) — Windows OCI chart fix, dependency updates
v3.2.0 (June 4, 2026) — added a linux/s390x build target for IBM Z platforms

Nothing after 3.0.x changes your HCL syntax again — once you've done the initial migration, later upgrades are safe minor bumps.

Frequently Asked Questions

Q: Do I have to migrate to Terraform Helm provider v3?
A: Not immediately, but v2.x isn't receiving new features. If you're managing Helm deployments long-term, plan the migration on your own schedule rather than waiting for a forced upgrade.

Q: My set blocks are gone after upgrading — did I lose configuration?
A: No, but you need to rewrite them as a set = [...] list attribute. The provider won't auto-convert set { } blocks in your .tf files — that part is manual.

Q: What Terraform version does v3 require?
A: 1.0 and above, since it runs on Terraform Plugin Protocol Version 6.

Q: I'm getting a "values" attribute error after upgrading — what's wrong?
A: You're likely on v3.0.0 exactly. Upgrade to at least v3.0.1, which shipped a same-day hotfix for this state upgrader issue.

Quick Summary:

Terraform Helm provider v3.0.0 (June 18, 2025) rewrote the provider on the Plugin Framework, requiring Terraform 1.0+
set, set_list, and set_sensitive change from repeated blocks to a single list-of-objects attribute
kubernetes becomes an object attribute; registry becomes a plural registries list
State upgrade errors are common — check GitHub issues #1722 and #1698 if resources don't read correctly post-upgrade
Latest version is v3.2.0 (June 4, 2026); no further HCL syntax changes since the 3.0.0 migration

Pin your provider version explicitly before you touch anything, then do the HCL rewrite in a branch you can terraform plan against before merging.

Anthropic Academy: Free Claude Courses and Certificates

Amaresh Pelleti — Fri, 24 Jul 2026 18:41:33 +0000

Anthropic Academy launched in March 2026 with 13 free, self-paced courses split across three tracks — no-code AI Fluency, developer-focused API and Claude Code training, and cloud platform integration for Bedrock and Vertex AI. The catalog keeps growing; Claude Code in Action and Introduction to Cowork are among the newest additions on the platform today.

Every course is free, requires only an email to sign up, and issues a certificate on completion. Here's what's actually in each track and where to start depending on whether you write code or not.

What Is Anthropic Academy

It's Anthropic's own training platform, hosted on Skilljar at anthropic.skilljar.com, separate from Anthropic's product documentation. Where the docs tell you how a feature works, the Academy walks you through using it — structured lessons, hands-on exercises, and a graded assessment at the end of each course.

The Academy is organized into three tracks, and Anthropic is explicit about who each one is for. You don't need programming experience for the first track. You do for the second and third.

The Three Learning Tracks Inside Anthropic Academy

For Everyone (6 courses, no coding required):

Claude 101
AI Fluency: Framework & Foundations
AI Fluency for Students
AI Fluency for Educators
Teaching AI Fluency
AI Fluency for Nonprofits

For Developers: API & Integration (4 courses, Python or CLI experience needed):

Building with the Claude API
Claude Code in Action
Introduction to Agent Skills
Introduction to MCP

Cloud Platform Integration (2 courses):

Claude with Amazon Bedrock
Claude with Google Vertex AI

That's 12 of the original 13 — the count has moved since launch as Anthropic adds new material.

For Everyone: No-Code AI Fluency Courses

This track is aimed at managers, students, educators, and anyone who wants to understand what Claude actually does without writing a line of code. Claude 101 is the starting point Anthropic recommends for this group — it covers the fundamentals of prompting and using Claude responsibly, not the API.

The AI Fluency courses go deeper into a specific framework (Anthropic calls it the "4D framework") for collaborating with AI tools effectively and ethically, rather than treating them as a black box you type questions into. If you're evaluating other free AI courses alongside this one, the AI Fluency track is closer to a workplace-skills course than a technical tutorial.

For Developers: API, MCP, and Claude Code Courses

This is the track worth your time if you're actually building something. Building with the Claude API covers integration basics. Claude Code in Action goes further — it's built around real usage patterns rather than just getting started with Claude Code for the first time.

Introduction to MCP and Introduction to Agent Skills round out the developer track. If you've been reading about how MCP works but haven't set one up yourself, this course is a more structured path than piecing it together from docs. Same goes for Claude's Agent Skills — the course walks through building one rather than just explaining the concept.

⚠️ Note: Anthropic scopes this track to people with Python or CLI experience. If you're coming from the no-code track, Claude 101 and Building with the Claude API is a reasonable bridge before jumping into Claude Code in Action.

Cloud Platform Courses: Bedrock and Vertex AI

These two courses exist because a meaningful share of Claude usage happens through a cloud provider's managed API rather than Anthropic's own API directly. If your organization standardizes on AWS or Google Cloud for procurement and compliance reasons, these courses cover the platform-specific setup and quirks that the general API course doesn't.

Anthropic Academy vs. the Coursera AI Fluency Courses

Separately from the Skilljar-hosted Academy, Anthropic launched five AI Fluency courses on Coursera on May 28, 2026, co-taught with Professors Rick Dakan and Joseph Feller, who developed the AI Fluency framework the courses are built on. These are listed as Community Impact courses on Coursera — free, and aimed at the same non-technical audience as the Academy's "For Everyone" track, but distributed through Coursera's platform instead of Anthropic's own.

The five Coursera courses are AI Fluency: Framework and Foundations, AI Fluency for Educators, Teaching AI Fluency, AI Fluency for Students, and AI Fluency for Nonprofits — the same course names that also appear in the Academy's no-code track. If you already have a Coursera account and prefer that platform's interface, the content overlaps enough that it doesn't matter which one you pick.

How to Get Started with Anthropic Academy

Go to anthropic.com/learn and click through to the course catalog, or go directly to anthropic.skilljar.com. Sign up with an email — no payment method required at any point.

If you're non-technical, start with Claude 101. If you're a developer who already uses Claude day to day, skip straight to Claude Code in Action or Introduction to MCP rather than starting from the beginner track — the courses aren't sequenced to require completing earlier ones first.

Frequently Asked Questions

Q: Is Anthropic Academy actually free, or is there a paid tier?
A: Every course is free. You need an email to register, but no payment method is required anywhere in the signup flow.

Q: Do I need a Claude subscription to take these courses?
A: For the no-code AI Fluency track, no — those courses focus on concepts and prompting practice. The developer track assumes you can access the Claude API, which has its own separate pricing.

Q: What's the difference between Anthropic Academy and the Coursera courses?
A: They're two different distribution channels for overlapping content. The Academy (on Skilljar) has the full 13+ course catalog including developer and cloud tracks. The five Coursera courses are specifically the AI Fluency track, co-taught with academic partners.

Q: Do I get a real certificate?
A: Yes — each course issues a certificate on completion of the final assessment, which Anthropic and third-party writeups describe as suitable for adding to a LinkedIn profile or resume.

Quick Summary:

Anthropic Academy launched March 2026 with 13 free courses across three tracks: no-code, developer, and cloud platform
The no-code track (Claude 101, AI Fluency courses) requires no programming experience
The developer track covers the Claude API, Claude Code, MCP, and Agent Skills — Python/CLI experience expected
A separate set of five AI Fluency courses launched on Coursera on May 28, 2026, co-taught with academic partners
Every course is free with a certificate on completion; sign up at anthropic.com/learn

If you're a developer, skip the intro track and start with Claude Code in Action or Introduction to MCP — you don't need to complete earlier courses first.

Kubernetes 1.36: What's New and What Breaks

Amaresh Pelleti — Fri, 24 Jul 2026 18:39:13 +0000

Kubernetes 1.36 shipped on April 22, 2026, and it's a security-and-hardware release more than a feature release. Eighteen enhancements graduated to stable, 25 moved to beta, and the two changes most teams will actually notice are User Namespaces going GA and Mutating Admission Policies replacing a chunk of what you used to need a webhook for.

Amazon EKS and EKS Distro added support for 1.36 on June 2, 2026, so if you're on AWS you can upgrade now. Here's what changed, what's deprecated, and what to check before you touch a production cluster.

What's New in Kubernetes 1.36

The release is codenamed ハル (Haru) — spring, clear skies. Of the 18 features that reached stable, most fall into two buckets: security isolation and Dynamic Resource Allocation (DRA) for GPU and specialized hardware. Here's the short list of what matters operationally.

Security and isolation:

User Namespaces for pods — stable
Fine-Grained Kubelet API Authorization — stable
API for External Signing of Service Account Tokens — stable
Mutating Admission Policies — stable

Storage and performance:

Speed up Recursive SELinux Label Change — stable
VolumeGroupSnapshot — stable
OCI VolumeSource — stable
PSI (Pressure Stall Information) support via cgroupv2 — stable

Hardware and DRA:

Device Taints & Tolerations for DRA — stable
DRAAdminAccess for ResourceClaims — stable
Partitionable Devices — stable

That's not the full list of 18, but it's the set with day-to-day impact. The rest are DRA refinements most teams won't touch unless they're running GPU workloads.

User Namespaces and Fine-Grained Kubelet Authorization Reach Stable

User Namespaces is the headline change. It maps the root user inside a container to an unprivileged user on the host node. So a process that thinks it's root inside the container has no elevated privileges outside it. This has been in alpha or beta since 1.25 — it's now safe to turn on by default for new workloads without waiting on more bug fixes.

Fine-Grained Kubelet API Authorization is the other stable feature worth checking. Before this, RBAC rules for the kubelet API were coarse — you either had access to the node's endpoints or you didn't. Now you can scope permissions down to specific paths like nodes/configz, nodes/healthz, and nodes/pods individually. If you've been granting broad node-level access to monitoring or debugging tools because there wasn't a narrower option, this changes that. You can tighten your RBAC configuration around exactly what each tool needs.

Mutating Admission Policies Replace Simple Webhooks

This is the change most platform teams will actually use. Mutating Admission Policies let you define mutations — like injecting a sidecar, adding a label, or setting a default resource limit — directly as a Kubernetes object using CEL (Common Expression Language), instead of standing up and maintaining a mutating webhook.

The practical upside: no more running a webhook deployment, managing its TLS certs, and worrying about what happens to admission if that pod goes down. The policy lives in the API server's own admission chain.

⚠️ Note: This doesn't replace every use case for webhooks. Complex mutation logic that needs external API calls or stateful lookups still needs a webhook. Mutating Admission Policies work well for anything you can express as a CEL expression against the object being admitted — sidecar injection, label defaulting, resource limit defaults.

What's Moving to Beta in Kubernetes 1.36

The 25 beta graduations are a mixed bag, but a few change daily workflows:

In-Place Pod-Level Resources Vertical Scaling — beta. You can now adjust a pod's CPU and memory without restarting it, extended from container-level scaling that landed earlier.
kuberc — beta, enabled by default. This splits kubectl user preferences (aliases, defaults) from cluster connection config in your kubeconfig. If you've ever had a teammate's personal kubectl aliases accidentally end up in a shared kubeconfig file, this is the fix.
Constrained Impersonation — beta. Impersonation now requires both impersonate and a new impersonate-on permission, so a user with impersonate rights can't impersonate into arbitrary identities without an explicit grant.
Node Declared Features — beta. Nodes now report which feature-gated capabilities they actually support, so the scheduler can filter on it instead of guessing.

None of these are breaking on their own, but kuberc being on by default means your kubeconfig files may start behaving differently the moment you upgrade kubectl to a 1.36-compatible version.

What Kubernetes 1.36 Deprecates and Removes

Two changes here are worth flagging before you upgrade.

.spec.externalIPs on Services is deprecated. It's being phased out over the next several releases, not removed outright in 1.36. The reason is CVE-2020-8554, a known man-in-the-middle risk where arbitrary external IPs can be claimed on a Service. If you're using externalIPs anywhere, the release notes point you toward LoadBalancer services, NodePort, or the Gateway API as replacements.

The gitRepo volume driver is being removed. It's been deprecated since 1.11, so this shouldn't surprise anyone still paying attention, but it will break any manifest that still references it.

Neither of these is new to 1.36 specifically — they're continuations of deprecation timelines that started earlier. What is specific to this window: Ingress NGINX officially retired on March 24, 2026, with no further releases or security patches. If you haven't already moved off it, the migration path to Gateway API is worth doing before you touch your 1.36 upgrade, not during it. Combining two migrations at once makes rollback harder if something goes wrong.

Upgrading to Kubernetes 1.36

If you're running self-managed clusters, this is a standard kubeadm upgrade — check your CNI and CSI driver compatibility matrices first, since 1.36 introduced schema changes for resources and DRA-related CRDs that older third-party controllers may not handle.

If you're on EKS, Amazon added 1.36 support on June 2, 2026, across all AWS regions including GovCloud. You can upgrade through the EKS console, eksctl, or your existing IaC pipeline. AWS specifically recommends running EKS cluster insights before you kick off the upgrade — it flags compatibility issues with deprecated APIs or add-ons ahead of time instead of surfacing them mid-upgrade.

Before you upgrade anything with active traffic, confirm your resource requests and limits are still accurate. Pod-level vertical scaling moving to beta means some autoscalers may start behaving differently once they detect the new API is available.

Frequently Asked Questions

Q: Is Kubernetes 1.36 a breaking release?
A: Not dramatically. The deprecations (externalIPs, gitRepo volumes) are phased, not immediate removals. The bigger operational risk is combining this upgrade with an overdue Ingress NGINX migration — do those separately.

Q: Do I need to enable User Namespaces manually?
A: Yes. It's stable, meaning it's supported and safe to use, but it's not on by default for existing workloads. You opt in per-pod via the pod spec.

Q: When does EKS support Kubernetes 1.36?
A: Since June 2, 2026, across all AWS regions where EKS is available, including GovCloud.

Q: What replaces Ingress NGINX now that it's retired?
A: The Kubernetes project recommends the Gateway API as the long-term replacement, with Envoy Gateway, Istio Gateway, Traefik, and Kong Gateway as common implementations.

Quick Summary:

Kubernetes 1.36 released April 22, 2026, with 18 features graduating to stable and 25 to beta
User Namespaces and Mutating Admission Policies are the two changes most teams will use immediately
Fine-Grained Kubelet API Authorization lets you scope node access down to specific endpoints
.spec.externalIPs is being phased out over several releases due to CVE-2020-8554
EKS supports 1.36 as of June 2, 2026 — upgrade via console, eksctl, or IaC

Run kubectl version and check it against your CNI/CSI vendor's 1.36 compatibility notes before you schedule the upgrade — that's the step most teams skip and regret.

GitHub Copilot AI Credits: How Usage-Based Billing Works

Amaresh Pelleti — Wed, 22 Jul 2026 10:11:13 +0000

Your Copilot bill works differently now. On June 1, 2026, GitHub moved every Copilot plan from premium requests to usage-based billing, and GitHub Copilot AI Credits became the meter that decides how much model usage you get each month. The subscription prices didn't change — what you get for them did.

If you use Copilot Chat, the CLI, or the coding agent daily, this affects you directly. Here's what changed, what each plan now includes, and how to keep the bill predictable.

[IMAGE: articles/images/2026-07-13-github-copilot-ai-credits-featured.png | alt: "github copilot ai credits usage-based billing meter across Copilot plans"]

AI Credits Replace Premium Requests

The old model gave you a monthly pool of Premium Request Units, where each interaction with a premium model cost a fixed number of requests. That's gone. Under usage-based billing, Copilot now bills by actual token consumption — input, output, and cached tokens — at the published API rate for each model.

One AI credit equals $0.01 USD. So a $10 Copilot Pro plan carries 1,000 base credits of model usage.

Two things disappeared along with premium requests. First, the fallback experience: Copilot no longer drops you to a lower-cost model when you run out of quota. When your credits are gone, you either buy more, upgrade, or wait for the monthly reset. Second, the fixed per-request cost — a short chat message and a long agentic session used to cost the same premium request. Now they don't, because billing follows tokens.

GitHub Copilot AI Credits by Plan

Subscription prices stayed the same, and a new Max tier was added at the top:

Plan	Price	Base credits	Flex allotment	Total monthly
Copilot Pro	$10/month	1,000	500	1,500
Copilot Pro+	$39/month	3,900	3,100	7,000
Copilot Max	$100/month	10,000	10,000	20,000
Copilot Business	$19/user/month	$19 in credits	—	pooled per org
Copilot Enterprise	$39/user/month	$39 in credits	—	pooled per org

The flex allotment is extra headroom on top of your base credits — Pro effectively gets $15 worth of model usage for its $10 price. Business and Enterprise credits pool across all users in the organization, so a heavy user can draw from what a light user doesn't touch.

⚠️ Note: Business and Enterprise plans get promotional credits through August 2026 — $30/month for Business and $70/month for Enterprise instead of the standard $19 and $39. If your team's usage looks fine right now, re-check it in September when the promo ends.

The Free plan includes 2,000 code completions and a small credit allowance, with model access through auto model selection only. Student accounts keep unlimited completions.

What Consumes AI Credits (and What Stays Unlimited)

Code completions and next edit suggestions remain unlimited on every paid plan. They don't touch your credits at all. If your Copilot usage is mostly tab-completion while you type, this whole change barely affects you.

Credits are consumed by:

Copilot Chat — every conversation, scaled by length and model choice
Copilot CLI and the cloud coding agent
Copilot Spaces and Spark
Third-party coding agents running through your Copilot subscription
Copilot code review — which burns both AI credits and GitHub Actions minutes

That last one surprises people. Automated code review on a busy repo is a recurring cost on two meters at once, so check both if you've wired it into every pull request.

How Token-Based Billing Actually Works

Because billing follows tokens, the same feature can cost very different amounts depending on how you use it. Three factors drive the number:

Conversation length. Each message in a chat re-sends context. Long-running conversations consume more input tokens per message, so ten short chats cost less than one marathon session covering the same questions.

Agentic features. The coding agent makes multiple model calls per task — planning, editing, verifying. A single "fix this issue" instruction can fan out into dozens of calls. In practice, agentic workflows are where credits drain fastest.

Model selection. Frontier models bill at higher API rates than smaller ones. Paid plans get a 10% discount on model costs when you use auto model selection instead of pinning a specific model.

Unused credits don't roll over. Your allowance resets to the full monthly amount at 00:00 UTC on the first day of each calendar month, and whatever you didn't use is forfeited.

Annual Plans Keep the Old Pricing — For Now

Monthly Pro and Pro+ subscribers were migrated automatically on June 1, 2026. Annual subscribers weren't. If you're on an annual plan, you stay on premium request pricing until your plan expires — but GitHub raised the model multipliers for annual holdouts on the same date, so the old pricing isn't quite what it used to be.

When an annual plan expires, the account transitions to the Free tier with the option to upgrade back into a usage-based plan. There's no path to renewing into premium requests.

Keeping Your Copilot Bill Predictable

When your included credits run out mid-month, you have three options: upgrade to a higher plan (you're charged only the price difference), set a budget for additional usage, or wait for the reset. Additional usage is billed at $0.01 per credit and can be capped — once you hit the cap, Copilot's premium features pause until you pay for consumed credits or the month rolls over.

For organizations, the billing docs cover budget controls at the enterprise, cost center, and individual user level, plus the choice to allow or block overage spending entirely. Set these before rollout, not after the first surprising invoice.

Three habits that stretch a credit allowance:

Use auto model selection unless you have a real reason to pin a model — the 10% discount adds up
Start new chats instead of continuing long conversations — shorter context means fewer input tokens
Reserve agentic workflows for tasks that justify the fan-out, and lean on unlimited completions for routine coding

If the math stops working for your usage pattern, it's worth comparing against Copilot alternatives or a dedicated agentic tool — the Claude Code vs Codex comparison covers the two most common candidates. And if you're staying, the Copilot tips and tricks guide helps you get more out of the features that are still unlimited.

[IMAGE: articles/images/2026-07-13-github-copilot-ai-credits-diagram.png | alt: "token metering flow splitting into included credits, overage budget, and unlimited completions lane"]

Frequently Asked Questions

Q: Did GitHub Copilot prices increase in 2026?
A: The subscription prices stayed the same — Pro is $10, Pro+ is $39, Business is $19/user, Enterprise is $39/user. What changed is the metering: premium requests were replaced by AI credits billed on token consumption. A new Copilot Max tier was also added at $100/month with 20,000 total credits.

Q: Do code completions use GitHub Copilot AI credits?
A: No. Code completions and next edit suggestions are unlimited on all paid plans and never consume credits. Only chat, CLI, agents, Spaces, Spark, and code review draw from your credit allowance.

Q: What happens when my AI credits run out?
A: Premium features pause unless you've set a budget for additional usage. You can upgrade plans (paying only the difference), buy additional usage at $0.01 per credit up to your budget cap, or wait for the monthly reset on the first of the month at 00:00 UTC.

Q: Do unused Copilot AI credits roll over to the next month?
A: No. Unused credits are forfeited and your allowance resets to the full monthly amount on the first day of each calendar month.

Q: I'm on an annual Copilot plan — am I affected?
A: Not immediately. Annual subscribers keep premium request pricing until their plan expires, though model multipliers increased on June 1, 2026. After expiry, the account moves to the Free tier with the option to upgrade into a usage-based plan.

Quick Summary:

GitHub Copilot AI Credits replaced premium requests on June 1, 2026 — billing now follows token consumption at each model's published API rate
1 credit = $0.01; Pro gets 1,500 total monthly credits, Pro+ gets 7,000, the new $100 Max tier gets 20,000
Code completions and next edit suggestions stay unlimited on all paid plans
Auto model selection gives paid plans a 10% discount on model costs
Business/Enterprise promo credits ($30/$70 per month) end in August 2026 — recheck team budgets in September
Unused credits don't roll over; overage can be capped with a dollar budget

Check your projected usage in the Copilot billing dashboard before the promotional credits expire — that's the number that predicts your September invoice.

Google Cloud Data Agent Kit: Build Pipelines from Your IDE Without the Boilerplate

Amaresh Pelleti — Mon, 20 Jul 2026 15:57:40 +0000

Writing data pipeline code is repetitive. You pull raw files from Cloud Storage, figure out the schema, decide whether to push through BigQuery or Spark, write the SQL or PySpark, wire up the orchestration, add the governance checks — and repeat this for every new dataset. Most of that work is boilerplate that follows known patterns.

Google Cloud Data Agent Kit is an open-source suite of AI skills, MCP tools, and IDE plugins that drops into VS Code and Claude Code to handle that boilerplate for you. You describe what you want to do with your data. The agents figure out the execution path.

[IMAGE: articles/images/2026-07-05-google-cloud-data-agent-kit-featured.png | alt: "google cloud data agent kit in VS Code IDE showing BigQuery pipeline generation with AI agents"]

What the Google Cloud Data Agent Kit Actually Does

The kit has four distinct layers:

Agentic skills — pre-codified workflows for the tasks you run repeatedly: query optimization, data validation, drift detection, ML model lifecycle management, and governance enforcement. These are the "skills" that agents draw on when you give them a goal.

MCP tools — Model Context Protocol connections that give the agents secure, authenticated access to your cloud data services (BigQuery, AlloyDB, Spanner, GCS) without requiring you to copy credentials into your editor or manually configure connection strings.

IDE plugins — native integrations for VS Code, Claude Code, Gemini CLI, Codex, and Antigravity CLI. The plugin surfaces a Unified Data Hub — a single view of your data estate, including datasets, orchestration pipelines, and active jobs.

Intelligent routing — the agents automatically pick the right compute engine for each task. BigQuery handles SQL-native analytics and ELT. Spark handles custom Python transformations and distributed ML training. You don't configure this — the agent chooses based on what the task requires.

The kit itself is in preview, but the two agents it packages are GA:

Data Engineering Agent — builds pipeline transformations from natural language descriptions and enforces governance rules
Data Science Agent — manages the full model lifecycle from data wrangling through training, scaling across BigQuery Dataframes and Serverless Apache Spark

Installing Google Cloud Data Agent Kit in VS Code and Claude Code

VS Code:

Open the Extensions panel (Ctrl+Shift+X / Cmd+Shift+X)
Search for "Google Cloud Data Agent Kit"
Install and authenticate with your Google Cloud account

Setup takes under a minute and configures the MCP connections automatically.

Claude Code:

Install via the Claude Code Plugin system. Once installed, Data Agent Kit's tools appear in Claude Code's available MCP tools, and you can invoke the Data Engineering Agent directly from the CLI.

Both environments give you access to the same agents and MCP connections — the difference is UX. VS Code gives you the Unified Data Hub sidebar for browsing datasets. Claude Code gives you conversational access from the terminal.

⚠️ Note: You need an active Google Cloud project with BigQuery API enabled. The agents authenticate with your existing gcloud auth credentials — no separate service account setup required for initial testing.

Building a Data Pipeline: What It Looks Like End to End

A real example from the kit's starter pack: starting with raw files in Cloud Storage and ending with batch inference results in Cloud Spanner — without leaving the IDE.

The Data Engineering Agent handled:

Creating a Spark notebook for initial data ingestion
Setting up Iceberg table management in BigQuery for the processed data
Generating a dbt project for the transformation layer
Wiring up an end-to-end orchestration pipeline

The Data Science Agent then:

Trained a XGBoost model on the processed dataset
Ran batch inference at scale
Pushed results to Cloud Spanner

Each step was triggered through natural language in the IDE — "create a pipeline to ingest these GCS files into BigQuery with Iceberg table management" — not by writing the pipeline code manually.

That doesn't mean zero code is involved. The agents generate code that you review and run. But the scaffolding, connection boilerplate, and orchestration wiring is generated rather than hand-written.

Connecting to BigQuery, GCS, and Spanner via MCP

The MCP layer is what makes the agents actually useful rather than just generating generic code. Because the agents connect directly to your cloud services, they can:

Inspect your actual dataset schemas before generating transformation code
Validate that generated SQL runs against your real BigQuery tables
Read GCS file metadata to determine the right ingestion approach
Check existing orchestration jobs before creating new pipeline steps

This matters because a generic AI assistant generating pipeline code doesn't know your actual schema or data. The MCP connection gives the agents context about your real data estate. For a deeper look at how MCP works, see what is Model Context Protocol.

For GCP data management compared to AWS and Azure, Data Agent Kit is a BigQuery-native integration — it works best in environments already invested in GCP data services.

[IMAGE: articles/images/2026-07-05-google-cloud-data-agent-kit-diagram.png | alt: "MCP architecture connecting VS Code to BigQuery, GCS, AlloyDB, and Spark via Data Agent Kit"]

When to Use It and When to Write Pipeline Code Yourself

Google Cloud Data Agent Kit is genuinely useful for:

Prototyping new pipelines — instead of spending an hour setting up the scaffold before you can even test your logic, you describe the data flow and get working code in minutes. Then you refine it.

Repeated ad-hoc data exploration — querying GCS files, visualizing dataset distributions, pulling quick stats without leaving your editor.

Standard transformation patterns — dbt project setup, Iceberg table management, standard ELT flows. These are well-understood patterns that the agents handle reliably.

It's less useful for:

Highly custom orchestration — if your pipeline has unusual scheduling requirements, specific failure recovery logic, or dependencies across multiple data systems with complex ordering, the generated scaffolding becomes a starting point rather than a finished product.

Performance-critical workloads — generated Spark code is correct but not always optimally tuned. You'll still need to profile and optimize queries that run at scale with strict SLA requirements.

The honest framing: this is a tool that eliminates boilerplate, not business logic. The parts of pipeline engineering that require understanding of your specific data, compliance requirements, and performance constraints still require human judgment.

Official documentation: Google Cloud Data Agent Kit extension docs and the GCP blog announcement.

Frequently Asked Questions

Q: Does Google Cloud Data Agent Kit work with non-GCP data sources?
A: The current version focuses on GCP services — BigQuery, AlloyDB, Spanner, GCS, and Serverless Apache Spark. The MCP tools are built specifically for GCP authentication and API patterns. Cross-cloud connections aren't supported in the current release.

Q: Is the Data Agent Kit free to use?
A: The kit itself is open-source and free to install (currently in preview). You pay for the underlying GCP services (BigQuery queries, Spark compute, GCS storage) at standard GCP rates. There's no additional charge for the Data Engineering Agent or Data Science Agent.

Q: Can I use it with Gemini CLI instead of VS Code?
A: Yes. The Data Agent Kit supports Gemini CLI, Claude Code, VS Code, Codex, and Antigravity CLI. The agents and MCP connections work the same across environments.

Q: What happens to my data when the agents access it?
A: The MCP tools use your existing Google Cloud credentials and IAM permissions. The agents don't copy data to external systems — they read metadata and execute queries against your GCP services within the permissions of your authenticated account.

Q: Does this replace dbt or Dataform for transformations?
A: No. The Data Engineering Agent can generate dbt projects as part of a pipeline setup, but it doesn't replace dbt as a transformation framework. It uses dbt for the parts where dbt is the right tool — the same way an experienced engineer would.

Quick Summary:

Google Cloud Data Agent Kit is an open-source suite of AI agents and MCP tools that integrates into VS Code and Claude Code
Two GA agents: Data Engineering Agent (pipelines, transformations, governance) and Data Science Agent (model training, inference)
MCP connections give agents real context about your actual schemas, datasets, and existing jobs — not just generic code generation
Intelligent routing picks BigQuery for SQL analytics and Spark for Python/ML workloads automatically
Best for prototyping, exploration, and standard transformation patterns — complex orchestration still needs manual refinement
Free to install; you pay standard GCP rates for the underlying services

Falco on Kubernetes: Runtime Security with eBPF

Amaresh Pelleti — Mon, 13 Jul 2026 21:17:36 +0000

Most Kubernetes security tools scan for misconfigurations — pods running as root, missing network policies, RBAC roles that are too permissive. Those checks matter, but they don't tell you what's actually happening at runtime. A container could be perfectly configured and still execute a reverse shell the moment a vulnerability gets exploited.

Falco fills that gap. It runs as a DaemonSet and monitors kernel-level system calls from every container on your nodes using eBPF. When a process does something suspicious — spawns a shell inside a production pod, reads sensitive credential files, opens an outbound connection to an unexpected host — Falco fires an alert in real time.

[IMAGE: articles/images/2026-07-05-falco-kubernetes-runtime-security-featured.png | alt: "falco kubernetes runtime security architecture with eBPF kernel monitoring"]

Falco on Kubernetes: What Runtime Security Actually Catches

The default Falco ruleset covers the threats that show up most in real incident reports:

Shells spawned inside containers — exec into a pod, reverse shell from a web app exploit, interactive session from compromised code
Privilege escalation — a process inside a container attempting to gain root access or modify privileged kernel settings
Sensitive file access — reads from /etc/shadow, /root/.ssh/, or cloud credential files like ~/.aws/credentials
Unexpected outbound traffic — connections to known crypto-mining pools, C2 servers, or external hosts outside your expected egress

Falco doesn't block any of this by default — it alerts on it. The threat detection is real-time because it happens at the kernel system call layer, not by periodically scanning container state.

Installing Falco on Kubernetes with Helm

Add the Falco Helm repository and update:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

Basic installation into its own namespace:

helm install falco falcosecurity/falco \
    --create-namespace \
    --namespace falco

By default, Helm deploys Falco as a DaemonSet — one pod per node — with the driver.kind=auto setting, which selects the best available driver automatically.

For most production clusters, you'll want to add Kubernetes metadata collection and Falcosidekick for alert routing:

helm install falco falcosecurity/falco \
    --create-namespace \
    --namespace falco \
    --set driver.kind=modern_ebpf \
    --set collectors.kubernetes.enabled=true \
    --set falcosidekick.enabled=true

This single command gets you: eBPF-based syscall monitoring, Kubernetes pod and namespace metadata enrichment in alerts, and Falcosidekick ready to route alerts to your notification channels.

eBPF vs Kernel Module: Choosing Your Driver

Falco supports three driver options, and the choice has real operational consequences:

Driver	How it works	Best for
`modern_ebpf`	CO-RE eBPF probe, no kernel headers needed	Most production environments, kernel 5.8+
`kmod`	Kernel module loaded at runtime	Older kernels, bare metal with kernel header access
`auto`	Picks the best available driver	Testing, heterogeneous node environments

For most teams running Kubernetes 1.24+ on standard cloud providers (EKS, GKE, AKS), modern_ebpf is the right choice. The CO-RE (Compile Once, Run Everywhere) approach means the probe adapts to different kernel structures at load time without recompilation — which eliminates the kernel header dependency that makes kmod painful to operate.

To install with explicit modern eBPF:

helm install falco falcosecurity/falco \
    --create-namespace \
    --namespace falco \
    --set driver.kind=modern_ebpf

⚠️ Note: modern_ebpf requires kernel 5.8 or later. For older kernels, use kmod or check the official Falco docs for minimum version requirements by driver type.

Also verify your Kubernetes RBAC policies allow Falco's DaemonSet pods to run with the necessary Linux capabilities — specifically SYS_PTRACE for eBPF-based drivers.

Understanding and Customizing Falco Rules

Falco rules are YAML files. Each rule defines a condition (what to look for in the syscall stream), an output message format (what the alert says), and a priority level. The default ruleset covers common threats out of the box, and you can extend it with custom rules for your environment.

Rules are loaded from /etc/falco/ inside the Falco pod. The main default ruleset lives in falco_rules.yaml. You override rules or add new ones in falco_rules.local.yaml — Falco loads local rules last, so they override defaults.

Common starting points for custom rules:

Restricting which namespaces are allowed to spawn processes outside the expected set
Alerting when credentials files are accessed from specific pod labels
Flagging network connections to unexpected IP ranges from production workloads

For exact condition field syntax and the full list of Falco fields (proc.name, container.image.repository, fd.sport, etc.), see the official Falco documentation. The field reference is comprehensive and the conditions are readable once you know the namespace.

For DevSecOps pipeline integration, Falco rules can be version-controlled and deployed via the same Helm chart upgrade path.

Falco Alert Routing with Falcosidekick

Falcosidekick is the standard companion service for routing Falco alerts. It sits between Falco's JSON event stream and your notification systems, with over 50 built-in integrations.

When you enable Falcosidekick in the Helm install, it deploys alongside Falco and picks up the event stream automatically:

helm upgrade falco falcosecurity/falco \
    --namespace falco \
    --set driver.kind=modern_ebpf \
    --set falcosidekick.enabled=true \
    --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/YOUR/WEBHOOK/URL" \
    --set falcosidekick.config.pagerduty.routingKey="YOUR_ROUTING_KEY"

Falcosidekick supports Slack, PagerDuty, Elasticsearch, Splunk, Loki, Datadog, OpsGenie, and many more. You configure each integration through Helm values or a falcosidekick.yaml config file.

[IMAGE: articles/images/2026-07-05-falco-kubernetes-runtime-security-diagram.png | alt: "falco alert routing flow from kernel layer through rules engine to Falcosidekick integrations"]

For alert volume, Falco's priority levels (CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG) let you route only high-priority alerts to PagerDuty while sending everything else to Elasticsearch for analysis.

This pairs well with existing cloud security monitoring — Falco covers the runtime layer that static config scanners miss.

Frequently Asked Questions

Q: Does Falco work on managed Kubernetes like EKS, GKE, or AKS?
A: Yes. All three managed providers support running Falco as a DaemonSet. On GKE, you'll need Container-Optimized OS nodes with the right kernel version for modern_ebpf. EKS and AKS support it on Amazon Linux 2 and Ubuntu node pools respectively.

Q: Will Falco slow down my Kubernetes workloads?
A: The modern eBPF driver has minimal overhead — typically 1-3% CPU on nodes under normal load. The syscall monitoring happens in the kernel, separate from your container processes. Heavy filtering of low-priority events through priority levels keeps the overhead manageable.

Q: Does Falco block threats or only alert?
A: By default, Falco only alerts. For active response — killing a pod, triggering a network policy change — you pair Falco with a response engine. Falco's Kubernetes Response Engine project, or a custom Falcosidekick webhook handler, can trigger automated remediation.

Q: How do I update Falco rules without redeploying the DaemonSet?
A: Use falcoctl — the Falco artifact manager — to pull updated rules at runtime. This is the recommended approach for production: falcoctl artifact install ruleset:falco-rules without a full Helm upgrade.

Q: Can I run Falco alongside other security tools like Trivy or kube-bench?
A: Yes, and you should. Falco covers runtime behavior. Trivy covers image vulnerabilities. kube-bench covers CIS benchmark compliance. These tools address different attack surfaces and complement each other.

Quick Summary:

Falco monitors kernel system calls via eBPF — it catches runtime threats that config scanners miss
Install with Helm: driver.kind=modern_ebpf is the right choice for kernel 5.8+ production clusters
Enable collectors.kubernetes.enabled=true to get pod/namespace context in every alert
Falcosidekick routes alerts to 50+ integrations — Slack, PagerDuty, Elasticsearch — with a single Helm value
Custom rules go in falco_rules.local.yaml and load last, overriding defaults
Falco alerts but doesn't block by default — pair it with a response engine for automated remediation

Helm 4 Migration Guide: What Breaks and How to Fix It Before EOL

Amaresh Pelleti — Mon, 06 Jul 2026 15:47:40 +0000

Helm 4 shipped in November 2025. Eight months later, most teams are still running Helm 3 in production CI/CD because it works. But Helm 3's final feature release lands September 9, 2026, and security patches stop completely on February 10, 2027.

This helm 4 migration is simpler than it looks. Your charts don't need rewriting — Helm 3 Chart API v2 charts are fully compatible with Helm 4. But the automation around Helm has four real breaking points that fail silently if you don't know where to look.

[IMAGE: articles/images/2026-07-05-helm-4-migration-guide-featured.png | alt: "helm 4 migration flow from Helm 3 to Helm 4 upgrade path"]

Why This Helm 4 Migration Matters Now

The EOL timeline has three stages, and they matter differently based on your situation:

September 9, 2026 — Final Helm 3 feature release (limited to Kubernetes client library updates only after this date)
February 10, 2027 — All security patches stop

If your organization runs regulated workloads with requirements around supported software, February 2027 is your hard deadline. But waiting until then means doing this migration under pressure, after 14 months of Helm 4 fixes shipped without you tracking them.

The better path: upgrade now, before September, so you're on supported software when new Kubernetes releases land and need updated client libraries.

What Actually Broke: The Four Real Changes

1. Post-renderers require plugin registration

In Helm 3, you could pass any executable directly to --post-renderer:

helm install myapp ./chart --post-renderer ./scripts/mutate.sh

Helm 4 drops this. Post-renderers must now be registered as named Helm plugins and referenced by plugin name:

helm install myapp ./chart --post-renderer my-post-renderer

If your pipeline calls --post-renderer ./path/to/script.sh, it fails on Helm 4. The error message doesn't say "plugin required," so this is easy to miss in a quick smoke test.

To wrap an existing script as a plugin, create a plugin.yaml:

name: my-post-renderer
version: "0.1.0"
usage: "Custom post-renderer"
description: "Mutation script for Helm output"
command: "$HELM_PLUGIN_DIR/mutate.sh"

Install it with helm plugin install /path/to/plugin-dir, then update your pipeline to reference the plugin name instead of the script path.

2. Registry login requires domain names only

Helm 3 accepted both forms:

helm registry login https://registry.example.com  # Helm 3: works
helm registry login registry.example.com          # Helm 3: also works

Helm 4 accepts domain names only — no protocol prefix:

helm registry login registry.example.com   # Helm 4: correct
helm registry login https://registry.example.com  # Helm 4: fails

Check every CI/CD step that authenticates to a private OCI registry. The HELM_EXPERIMENTAL_OCI=1 environment variable is also gone — OCI is now stable and enabled by default, and setting that flag causes an error.

3. `--atomic` and `--force` are renamed

Two flags that appear constantly in production pipelines are deprecated in Helm 4:

Old flag	New flag
`--atomic`	`--rollback-on-failure`
`--force`	`--force-replace`

The old flags still work in current Helm 4 releases but emit deprecation warnings. They become hard errors in a future minor version. If your pipeline treats warnings as failures — which many do — you'll hit breakage before that happens.

4. Go SDK import path (tool builders only)

If you've built tooling that embeds Helm as a Go library, update your import from helm.sh/helm/v3 to helm.sh/helm/v4. This only applies if you're writing code that imports Helm packages — not if you're using the CLI.

New Defaults That Will Catch You Off Guard

Server-side apply for new installs

Helm 4 uses server-side apply (SSA) for all new helm install operations. SSA handles field ownership conflicts more cleanly than client-side apply, so this is the right default. But it changes behavior in ways that matter.

For existing releases installed with Helm 3, Helm 4 retains client-side apply on upgrades. So you get SSA on new installs and client-side apply on upgrades of existing releases. To force SSA for an existing release, pass --server-side explicitly:

helm upgrade myapp ./chart --server-side

Test this in staging first. SSA applies field management metadata that can surface ownership conflicts if other tools — ArgoCD, kubectl, Terraform — have also been managing those resources.

kstatus changes what `--wait` checks

Helm 4's --wait flag now uses kstatus for readiness detection instead of just checking pod status. kstatus requires the watch verb on Kubernetes resources. If your Helm service account doesn't have watch, --wait fails immediately after you upgrade the binary.

Before upgrading, check your Kubernetes RBAC configuration and ensure the Helm service account includes:

rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

Without watch, the failure looks like a timeout at first glance, not a permissions error.

How to Install Helm 4

Helm 4 and Helm 3 coexist on the same machine, so you can install Helm 4 and test before switching over.

Via install script:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4
chmod 700 get_helm.sh
./get_helm.sh

macOS via Homebrew:

brew install helm

Debian/Ubuntu:

curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update && sudo apt-get install helm

Fedora/RHEL:

sudo dnf install helm

After installation, run helm version to confirm 4.x, then test your charts against a staging namespace:

helm install test-release ./your-chart --namespace staging --dry-run

Charts from existing Helm 3 deployments work as-is in Helm 4. What you're testing is your pipeline scripts, not the chart files.

Fixing Your CI/CD Scripts for Helm 4

Go through every Helm call in your pipelines. For each one, check these specific patterns:

# Rename --atomic
helm upgrade myapp ./chart --atomic               # OLD — warning now, hard error later
helm upgrade myapp ./chart --rollback-on-failure  # NEW

# Rename --force
helm upgrade myapp ./chart --force                # OLD
helm upgrade myapp ./chart --force-replace        # NEW

# Fix registry login
helm registry login https://my-registry.io        # OLD — fails in Helm 4
helm registry login my-registry.io               # NEW

# Remove the OCI experiment flag entirely
export HELM_EXPERIMENTAL_OCI=1   # Remove this line — setting it causes an error in Helm 4

For post-renderer scripts: wrap each one as a Helm plugin using the plugin.yaml format above. The actual script content doesn't change — only how Helm references it.

For a shift-left security pipeline that validates charts pre-deploy, check whether your static analysis tools (conftest, chart-testing) have released Helm 4 compatible versions.

Helm templates and commands syntax is unchanged in Helm 4 — the template engine, values handling, and chart structure are all the same.

[IMAGE: articles/images/2026-07-05-helm-4-migration-guide-diagram.png | alt: "CI/CD pipeline checklist diagram for upgrading to Helm 4"]

For the official timeline, see the Helm v3 End of Life announcement.

Frequently Asked Questions

Q: Do I need to rewrite my Helm charts for Helm 4?
A: No. Helm 3 Chart API v2 charts work with Helm 4 without changes. The helm 4 migration affects your CI/CD scripts and automation — not the chart files, templates, or values.

Q: Will existing Helm 3 releases break when I upgrade the Helm binary?
A: No. Helm 4 reads existing release history without issues. Upgrades of existing releases stay on client-side apply until you explicitly pass --server-side.

Q: What happens if I don't upgrade before September 9?
A: Helm 3 keeps working — it just won't receive Kubernetes client library updates after September 9. Security patches continue until February 10, 2027. The practical risk is that new Kubernetes API deprecations won't be handled in Helm 3 after that date.

Q: How do I verify whether kstatus will break my --wait?
A: Run kubectl auth can-i watch pods --as=system:serviceaccount:default:helm for your Helm service account. If it returns "no," add watch to the cluster role before migrating.

Q: Does Helm 4 change how classic chart repositories work?
A: No. HTTP chart repos work the same. OCI registry support is now stable and the default — you no longer need HELM_EXPERIMENTAL_OCI=1, and setting it causes an error.

Quick Summary:

Helm 3 final feature release: September 9, 2026. Security patches end February 10, 2027.
Post-renderers must be Helm plugins — executable paths no longer work
helm registry login requires domain names only — drop https://
--atomic → --rollback-on-failure, --force → --force-replace
kstatus for --wait requires the watch RBAC verb — check before migrating
Charts need zero changes — this helm 4 migration is entirely in your CI/CD scripts

PostgreSQL on Kubernetes — Complete Setup Guide with CloudNativePG

Amaresh Pelleti — Tue, 16 Jun 2026 01:13:22 +0000

Originally published on DevToolHub, where I keep this guide updated as CloudNativePG evolves.

Running PostgreSQL in Kubernetes used to be a bad idea. StatefulSets were tricky, persistent volumes were unreliable, and failover meant data loss. Most teams defaulted to managed cloud databases and called it done.

That calculus has changed. CloudNativePG — the CNCF-listed PostgreSQL operator — handles high availability, automated failover, Point-in-Time Recovery, connection pooling, and streaming replication out of the box. In 2026 it's the production-grade way to run PostgreSQL on Kubernetes, and the gap between "self-hosted on K8s" and "managed cloud database" has narrowed significantly.

This guide walks through a complete CloudNativePG setup — from operator install to production-ready cluster.

What the full guide covers

Why CloudNativePG over a plain StatefulSet — what the operator actually does that raw StatefulSets can't
Installing the operator — kubectl and the kubectl-cnpg plugin
Deploying a 3-instance HA cluster — 1 primary + 2 standbys, with PostgreSQL tuning parameters
Connecting your app — read-write vs read-only services, port-forwarding for debugging
Backup and WAL archiving to S3 — ScheduledBackup, retention policies, verifying archiving works
PgBouncer connection pooling — the Pooler resource, transaction vs session mode
RBAC and Network Policies — locking down who can reach the database at the Kubernetes layer
Testing failover — how to simulate a primary failure and what to expect
Point-in-Time Recovery — restoring to an exact timestamp from WAL archives
Common mistakes and best practices — storage sizing, pool mode, pg_hba.conf defaults, synchronous replication

The one thing most guides skip

WAL archiving must be configured before you put data in the database — you can't retroactively enable PITR. Configure backups before your first application write.

So which setup should you use?

CloudNativePG on K8s — right for teams with Kubernetes expertise who want full operational control, PITR, and custom PostgreSQL configuration without paying managed database prices.

Managed PostgreSQL (RDS, Cloud SQL, DigitalOcean Managed Databases) — still wins on operational simplicity. Zero operator to maintain, automatic failover handled for you.

CloudNativePG narrows the gap significantly — but the right call depends on your team's tolerance for database operations.

I keep the full step-by-step guide on DevToolHub, including all YAML manifests and kubectl commands: PostgreSQL on Kubernetes — Complete Setup Guide with CloudNativePG

I write hands-on DevOps and Kubernetes guides at devtoolhub.com. Questions about your setup? Drop a comment.

Ollama Cloud Free vs Pro — Usage Limits, Pricing & What You Actually Get (2026)

Amaresh Pelleti — Thu, 11 Jun 2026 00:39:50 +0000

Ollama Cloud is one of the most searched topics in the local AI space right now — and the number one question is always the same: what do you actually get on the free tier, and is Pro worth paying for?

This guide covers the plan limits, how usage is actually measured (it's not tokens), and when upgrading makes sense. All data is pulled from the official Ollama pricing page.

What Ollama Cloud is

Ollama Cloud is a managed inference service that runs large open-source models on Ollama's datacenter GPUs — no local GPU required. The key advantage: your existing local Ollama setup works identically with cloud models. No code rewrites, no new SDKs. Just point at a cloud model and run:

ollama run gpt-oss:120b-cloud

Same CLI, same OpenAI-compatible API, different hardware.

The three tiers

	Free	Pro	Max
Price	$0	$20/mo ($200/yr)	$100/mo
Cloud usage	Base quota	~50x Free	Highest
Concurrent cloud models	Limited	3 at a time	More <!-- CHECK exact number against your live post -->
Model access	Lighter cloud models	Full catalog	Full catalog + priority

Running models on your own hardware is always unlimited — the plans only govern cloud usage.

How usage is actually measured (most posts get this wrong)

Ollama doesn't cap you at a fixed number of tokens or requests. Usage reflects actual utilization of their cloud infrastructure — primarily GPU time, which depends on model size and request duration. Two things follow from that:

Limits reset on two clocks: session limits reset every 5 hours, weekly limits reset every 7 days.
Heavier models burn quota faster. Models are grouped into usage levels from level 1 (light models like gpt-oss:20b) up to level 4 (extra-heavy models like deepseek-v4-pro).

Practical tip: on the Free tier, stick to level 1 and level 2 models to stretch your quota. Shorter prompts and prompts that share cached context also consume less.

Concurrency and queueing

Requests beyond your plan's concurrency limit are queued and processed when a slot opens. The queue itself has a fixed depth — if it's full, requests are rejected until a slot frees up. This is the main reason production agent workloads end up on Max: it's about sustained concurrent access, not just raw quota.

Privacy

Prompt and response data is never logged or trained on, and Ollama requires zero-data-retention policies from its hosting partners. Worth knowing if you're considering cloud inference for work data.

So which tier should you pick?

Free — genuinely useful for experimenting with large models you can't fit locally. Stay on level 1–2 models.
Pro ($20/mo) — the right call for daily engineering work. Full catalog, 3 concurrent cloud models, enough quota that most individual developers never hit the wall.
Max ($100/mo) — for production agent and RAG workloads that need sustained, concurrent access to the heaviest models.

And if you'd rather own the hardware: a GPU droplet running self-hosted Ollama flips the economics once your usage is steady — I break down that setup separately.

One warning

Ollama has revised its cloud quotas more than once since launch. I keep the original post on DevToolHub updated against the official pricing page every time the limits change — bookmark that one if you want current numbers.

I write hands-on DevOps and self-hosted AI guides at devtoolhub.com. Questions about your specific workload? Drop a comment.

DEV Community: Amaresh Pelleti

Microsoft Defender for Cloud Now Protects AWS RDS

What Changed for Defender for Cloud on AWS RDS

Which Database Engines Are Covered

Prerequisites Before You Enable It

Step-by-Step: Enabling Defender for Cloud on AWS RDS

What Defender Changes in Your RDS Parameter Groups

Required AWS Permissions for Defender for Cloud on RDS

Frequently Asked Questions

GPT-5.6 Explained: Sol, Terra, and Luna Pricing

What Is GPT-5.6

Sol, Terra, and Luna: The Three GPT-5.6 Variants

How Sol Compares to Claude Fable 5

GPT-5.6 Pricing

What Changed From GPT-5.5

Getting Access to GPT-5.6

Frequently Asked Questions

Terraform Helm Provider Migration: v3 Breaking Changes

What the Terraform Helm Provider Migration Changed

Why HashiCorp Migrated to the Plugin Framework

Migrating set, set_list, and set_sensitive Blocks

Migrating the kubernetes and registry Blocks

State Upgrade Errors During the Terraform Helm Provider Migration

Should You Run the Terraform Helm Provider Migration Now

Frequently Asked Questions

Anthropic Academy: Free Claude Courses and Certificates

What Is Anthropic Academy

The Three Learning Tracks Inside Anthropic Academy

For Everyone: No-Code AI Fluency Courses

For Developers: API, MCP, and Claude Code Courses

Cloud Platform Courses: Bedrock and Vertex AI

Anthropic Academy vs. the Coursera AI Fluency Courses

How to Get Started with Anthropic Academy

Frequently Asked Questions

Kubernetes 1.36: What's New and What Breaks

What's New in Kubernetes 1.36

User Namespaces and Fine-Grained Kubelet Authorization Reach Stable

Mutating Admission Policies Replace Simple Webhooks

What's Moving to Beta in Kubernetes 1.36

What Kubernetes 1.36 Deprecates and Removes

Upgrading to Kubernetes 1.36

Frequently Asked Questions

GitHub Copilot AI Credits: How Usage-Based Billing Works

AI Credits Replace Premium Requests

GitHub Copilot AI Credits by Plan

What Consumes AI Credits (and What Stays Unlimited)

How Token-Based Billing Actually Works

Annual Plans Keep the Old Pricing — For Now

Keeping Your Copilot Bill Predictable

Frequently Asked Questions

Google Cloud Data Agent Kit: Build Pipelines from Your IDE Without the Boilerplate

What the Google Cloud Data Agent Kit Actually Does

Installing Google Cloud Data Agent Kit in VS Code and Claude Code

Building a Data Pipeline: What It Looks Like End to End

Connecting to BigQuery, GCS, and Spanner via MCP

When to Use It and When to Write Pipeline Code Yourself

Frequently Asked Questions

Falco on Kubernetes: Runtime Security with eBPF

Falco on Kubernetes: What Runtime Security Actually Catches

Installing Falco on Kubernetes with Helm

eBPF vs Kernel Module: Choosing Your Driver

Understanding and Customizing Falco Rules

Falco Alert Routing with Falcosidekick

Frequently Asked Questions

Helm 4 Migration Guide: What Breaks and How to Fix It Before EOL

Why This Helm 4 Migration Matters Now

What Actually Broke: The Four Real Changes

1. Post-renderers require plugin registration

2. Registry login requires domain names only

3. --atomic and --force are renamed

4. Go SDK import path (tool builders only)

New Defaults That Will Catch You Off Guard

Server-side apply for new installs

kstatus changes what --wait checks

How to Install Helm 4

Fixing Your CI/CD Scripts for Helm 4

Frequently Asked Questions

PostgreSQL on Kubernetes — Complete Setup Guide with CloudNativePG

What the full guide covers

The one thing most guides skip

3. `--atomic` and `--force` are renamed

kstatus changes what `--wait` checks