Centralized Application Authorization with Kyverno and Istio

Centralized Application Authorization with Kyverno and Istio Why is Kubernetes Authorization so Complex What are the Challenges with OPA Sidecar Authorization in Kubernetes? Why Choose Centralized Kyverno for Sidecarless Authorization? Advantages: How Does Centralized JWT Authorization with Kyverno and Istio Work? Key Technologies for Kyverno-Istio Authorization Prerequisites Environment Setup Kubernetes cluster options: Step-by-Step Instructions Step 1: Create Local Kubernetes Cluster Step 2: Deploy Keycloak Identity Provider Step 3: Install Certificate Management Step 4: Install Kyverno Authorization Server Step 5: Install Istio Service Mesh Step 7: Configure Authorization Policies Step 8: Test Authorization Step 9: Advanced Policy Patterns Step 10: Production Hardening The Future of Kubernetes Authorization is Centralized Next Steps and Resources Central Authorization for Kyverno and Istiopng Securing Kubernetes API access is complex. After a user is authenticated (verifying who they are), an application’s authorization workflow determines what specific actions and data that user is permitted to access by checking their credentials against a set of predefined access rules. This process typically involves a resource server validating an access token provided by the application before granting access to a protected resource. Standard solutions across industries require sidecars, are costly, and do not scale well. This post describes a more straightforward solution: a centralized Kyverno Authorization Server that uses the new Kyverno CEL-based ValidatingPolicy with Istio service mesh. This solution eliminates sidecars, enhances policy consistency, and enables fine-grained, JWT-based authorization for all traffic. The architecture reduces resources, offers instant policy updates, and centralizes audit trails, transforming authorization into a streamlined, centrally managed capability that cuts costs, ensures compliance, and simplifies operations. When using Istio OPA-based authorization in Kubernetes, it typically follows this pattern: The Kyverno Authorization Server with Istio provides a superior, centralized alternative that directly addresses the challenges of sidecar-based authorization. Sidecarless: Authorization decisions happen at the Envoy proxy level via external auth Performance : CEL expression highly optimized for performance, critical for latency-sensitive applications whereas Rego can be less performant due to its power and expressiveness, better for non-latency-critical use cases Centralized policies: Kyverno ValidatingPolicy CRDs applied once, enforced everywhere Immediate updates: Policy changes take effect instantly—no pod restarts Consistent enforcement: Single source of truth for all authorization decisions Native Kubernetes: Policies are CRDs managed with kubectl and GitOps workflows Request Interception: When a request arrives at the Istio ingress gateway or sidecar proxy, Istio’s AuthorizationPolicy resource (with action: CUSTOM) intercepts it. External Authorization Call: The Envoy proxy makes a gRPC call to the Kyverno Authorization Server, passing request attributes (headers, path, method, etc. ). Policy Evaluation: Kyverno evaluates the request against ValidatingPolicy CRDs, which can: Extract and validate JWT tokens from the Authorization header Verify token signatures using JWKS endpoints Check token expiry and custom claims Match requests by service, namespace, path, method, and headers Return allow/deny decisions with custom status codes Extract and validate JWT tokens from the Authorization header Verify token signatures using JWKS endpoints Check token expiry and custom claims Match requests by service, namespace, path, method, and headers Return allow/deny decisions with custom status codes Decision Enforcement: The proxy allows or denies the request based on Kyverno’s decision, without the application ever seeing unauthorized requests.