OpenChoreo just shipped v1.1.3, and it is the release where the project starts taking production security seriously. If you have been watching this CNCF sandbox project from the sidelines, this is the version that makes it worth a closer look — not because it adds flashy new features, but because it closes two security gaps that would make any platform engineer nervous in a production deployment.
So what is OpenChoreo? Think of it as the connective tissue between your developer portal and your Kubernetes clusters. You push code to GitHub or Bitbucket. OpenChoreo catches the webhook, figures out what changed, and triggers builds and deployments across however many clusters you have running. It is the automation layer that sits between “I merged a pull request” and “the new version is live in staging” — without you writing a single line of CI/CD pipeline config.
The pain it eliminates is the one every platform team knows too well: developers waiting on operations to wire up deployment pipelines. With OpenChoreo, the connection between your git provider and your deployment target is declarative and automatic. You define what a component is, where it lives, and where it should deploy. The platform handles the rest.
v1.1.3 matters because it addresses the two things that would keep you up at night if you ran OpenChoreo in production: anyone could forge a webhook and trigger unauthorized builds, and internal components talked to the cluster gateway with zero encryption or authentication. Both of those are now fixed. Let us get into the details.
What Is New
Enforced Webhook Signature Verification Across All Git Providers
Here is the problem that existed before v1.1.3: OpenChoreo’s autobuild webhook endpoint trusted incoming webhooks without verifying they actually came from your git provider. For GitHub, signatures were checked. For Bitbucket? Not so much. The Bitbucket webhook path accepted requests without any signature validation at all. And if a webhook secret was missing or empty for any provider, validation was simply skipped — the equivalent of a bouncer who waves everyone through when the guest list goes missing.
That changes now. Every git provider path authenticates the request before any build is triggered. Bitbucket webhooks are validated with HMAC-SHA256 against the configured secret, matching the same standard GitHub already used. And critically: a missing or empty webhook secret is now treated as invalid. The system fails closed instead of failing open.
There is also a subtle but important addition: provider and repository consistency checking. The webhook processor now requires that the authenticated provider matches the provider hosting the matched component’s repository. A webhook validated for GitHub can no longer trigger builds for components hosted on Bitbucket that happen to share a repository URL. This prevents cross-provider confusion attacks that most people would never think to look for.
# Before v1.1.3: Bitbucket webhooks accepted without signature verification
# Missing webhook secret = validation skipped (fail open)
# After v1.1.3: All providers require HMAC-SHA256 verification
# Missing webhook secret = request rejected (fail closed)
# X-Hub-Signature header now required for Bitbucket webhooksPR #4253 — feat(api): enforce webhook signature verification across all git providers
Mutual TLS for Cluster Gateway Communication
The second security upgrade is arguably the more important one. Before v1.1.3, OpenChoreo’s controller and API server communicated with the cluster gateway without any authentication. No encryption. No identity verification. No mutual trust. If an attacker compromised a single pod in your cluster — or deployed a malicious one — they could impersonate the controller and query resources across different planes (think: different environments, different tenants, different deployment targets).
That is the kind of attack surface that makes security teams reach for the aspirin. It is not theoretical. In a multi-tenant Kubernetes environment, any pod that can reach the cluster gateway endpoint could request resources from any plane the gateway manages.
v1.1.3 adds mutual TLS (mTLS) between the cluster gateway and all internal clients. Both sides now verify each other’s identity before any data changes hands. The controller presents a client certificate. The gateway verifies it. The gateway presents its certificate. The controller verifies it back. No certificate, no communication. No impersonation, no lateral movement.
This is zero-trust networking applied where it matters most: the control plane communication path that connects your internal services to your deployment targets.
PR #4258 — feat: add mTLS to cluster gateway communication from internal components
Configurable Helm Authz Roles
The third change is more operational than security-focused, but it solves a real frustration. Previously, OpenChoreo’s Helm chart rendered authorization roles (AuthzRole and ClusterAuthzRoleBinding) as tracked Helm release resources. That meant every helm upgrade would overwrite or delete any roles an operator had customized after installation. You spend an hour tuning RBAC permissions for your specific identity provider setup, run an upgrade, and watch it all silently disappear.
v1.1.3 moves role seeding into a post-install and post-upgrade Helm hook Job that upserts roles and bindings from values.yaml. Operator changes now survive upgrades. Per-IdP entitlement overrides actually apply instead of being silently dropped by hardcoded template entries. If you have ever screamed at a Helm chart for eating your config, this one is for you.
PR #4217 — fix(helm): bootstrap authz roles via hook job and make them fully configurable
The Bigger Picture
Two of these three changes — webhook verification and mTLS — are fundamental security hardening that any platform targeting production Kubernetes deployments needs. They are not glamorous. They will not trend on Hacker News. But they are the difference between a project that is safe to evaluate in staging and one that is safe to run in production.
The backport nature of these changes is worth noting. The webhook signature verification was originally merged to main (PR #4239) and is now being backported to the release-v1.1 branch. The Helm authz fix backports PR #4178 and PR #4188. This means the v1.1.x line is receiving security and operational improvements that already shipped in the development branch — a sign that the maintainers are actively maintaining the stable release series, not just pushing everything to the next major version.
If you are already running OpenChoreo v1.1.x in any environment, upgrade to v1.1.3 this week. The webhook and mTLS fixes are not optional hardening — they close attack vectors that are trivial to exploit in a network-accessible deployment.
