feat: allow/deny access policies from Ingress annotations#277
Open
twiechert wants to merge 1 commit intoSTRRL:masterfrom
Open
feat: allow/deny access policies from Ingress annotations#277twiechert wants to merge 1 commit intoSTRRL:masterfrom
twiechert wants to merge 1 commit intoSTRRL:masterfrom
Conversation
Add support for managing Cloudflare Access Applications directly from Kubernetes Ingress annotations, co-locating access policy with the services it protects. New annotations: - cloudflare-access-allowed-group: comma-separated Access Group IDs that are allowed access (creates an allow policy) - cloudflare-access-denied-group: comma-separated Access Group IDs that are denied access (creates a higher-precedence deny policy) When allowed-group is set, the controller creates a self-hosted Access Application for the hostname with deterministic naming (ctic:<tunnel>:<host>) for ownership tracking. Applications are reconciled on each sync: created, updated, or deleted to match the desired state. This keeps the controller IdP-agnostic — groups encapsulate the OIDC/email/mTLS logic and are referenced by ID.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #277 +/- ##
==========================================
- Coverage 47.08% 42.39% -4.69%
==========================================
Files 11 12 +1
Lines 703 901 +198
==========================================
+ Hits 331 382 +51
- Misses 349 494 +145
- Partials 23 25 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Manages Cloudflare Access Applications and their allow/deny policies from Ingress annotations:
Groups are referenced by name, resolved to IDs at reconcile time. The annotation is IdP-agnostic — whether groups are backed by Zitadel OIDC claims, Google Workspace groups, or anything else doesn't matter. Ownership tracked via
ctic:<tunnel>:<hostname>naming convention (same pattern as_ctic_managedDNS records).Motivation
With an OIDC provider and Cloudflare Tunnel in place, you can already gate access per service — but the per-hostname Access Applications and policies still need to be managed separately (Terraform, dashboard, API). Adding or removing a service means updating both the Ingress and the access config in another system. This moves it into the Ingress annotation so it stays in one place.
You could also handle authorization natively in the IdP by registering each service as a separate OIDC application with its own role grants — but that means maintaining every service twice: once as an Ingress and again in the IdP.