Skip to main content
Mapagam

Implementing Authorization Policies

1. Creating Authorization Policies

Field Description Example
metadata.name Name of the authorization policy allow-read-access
metadata.namespace Namespace where policy is applied frontend
spec.action Action to take when policy is matched ALLOW or DENY
spec.rules List of rules to evaluate Array of rule objects

Example: Basic Authorization Policy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-read-access
  namespace: frontend
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend-sa"]
    to:
    - operation:
        methods: ["GET"]
Note: The action field determines whether the policy allows or denies access. Rules are evaluated in order, and the first matching rule determines the outcome.

2. Configuring Source-Based Authorization

Property Description Example
source.principal Principal (identity) of the requesting service "cluster.local/ns/default/sa/client"
source.namespace Namespace where the requesting service resides "default"
source.serviceAccount Service account name of the requesting service "client"

Example: Source-Based Authorization Policy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: source-authz
  namespace: default
spec:
  rules:
  - from:
    - source:
        principals: 
          - "cluster.local/ns/default/sa/client"
Note: The principals field uses the identity format defined by the service mesh's authentication system, typically including namespace and service account name.

3. Implementing Operation-Based Rules

Rule Type Description Example
operation Defines the operation to which the rule applies GET /api/users/{id}
method HTTP method to match (GET, POST, PUT, DELETE) POST
path Path pattern to match (supports wildcards) /api/users/*

Example: Operation-Based Rule Configuration

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: user-read-policy
spec:
  rules:
  - to:
    - operation:
        methods: ["GET"]
        paths: ["/api/users/*"]

Example: Complex Operation Rule

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: admin-write-policy
spec:
  rules:
  - to:
    - operation:
        methods: ["POST", "PUT", "DELETE"]
        paths: ["/api/admin/*"]
Note: Operation-based rules can be combined with other rule types to create more granular access control policies.

4. Setting Condition Expressions

Condition expressions in service mesh authorization policies define the criteria under which a request is allowed or denied. These conditions can be based on various attributes of the request, such as source and destination identities, headers, IP addresses, and more.

Property Description Example
source.namespace Namespace of the source service. "istio-system"
source.principal Identity of the source service, often a JWT subject. "cluster.local/ns/frontend/sa/frontend-sa"
destination.ip IP address of the destination service. "10.0.0.1"
destination.port Port on which the destination service is listening. 8080
request.headers HTTP headers from the request. "x-forwarded-for": "192.168.1.1"
request.path Path of the HTTP request. "/api/v1/users"

Example: Basic Condition Expression

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: example-policy
  namespace: istio-system
spec:
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend-sa"]
    to:
    - operation:
        paths: ["/api/v1/users"]
        methods: ["GET"]

Example: Complex Condition with Multiple Attributes

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: complex-policy
  namespace: istio-system
spec:
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend-sa"]
        namespaces: ["frontend"]
    to:
    - operation:
        paths: ["/api/v1/users"]
        methods: ["GET", "POST"]
    when:
    - key: request.headers["x-forwarded-for"]
      value: ["192.168.1.1"]
Note: The when field allows for complex condition expressions using the key and value fields to match specific request attributes.
Warning: Misconfiguring condition expressions can lead to unintended access control. Always test policies in a non-production environment.

5. Implementing Custom Claims Authorization

Property Description Example
claims Custom claims to be validated in the authorization policy "claims": { "email": "user@example.com" }
required Boolean indicating whether the claim is required for access "required": true
value Expected value for the claim "value": "admin"

Example: Custom Claims in Authorization Policy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: custom-claims-policy
spec:
  rules:
  - from:
    - source:
        principals: [ "user@example.com" ]
    when:
    - key: "email"
      values: [ "user@example.com" ]
    - key: "role"
      values: [ "admin" ]
Note: Custom claims must be present in the JWT token used for authentication.
Warning: Ensure that the custom claims are properly validated to prevent unauthorized access.

6. Configuring When Conditions

Condition Description Example
request.headers Matches based on HTTP headers in the request 
{
  "request": {
    "headers": {
      "Authorization": "Bearer token123"
    }
  }
}
request.path Matches based on the request path 
{
  "request": {
    "path": "/api/users"
  }
}
request.method Matches based on the HTTP method used 
{
  "request": {
    "method": "POST"
  }
}
source.ip Matches based on the source IP address of the request 
{
  "source": {
    "ip": "192.168.1.100"
  }
}
destination.port Matches based on the destination port of the request 
{
  "destination": {
    "port": 8080
  }
}

Example: Using When Conditions in Authorization Policy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: example-policy
spec:
  rules:
  - when:
    - key: request.headers[Authorization]
      values: [Bearer token123]
    - key: request.path
      values: [/api/users]
    - key: source.ip
      values: [192.168.1.100]
    - key: destination.port
      values: [8080]

7. Managing Authorization Precedence

Policy Scope Precedence Level Notes
global all 1 (highest) Applies to all services in mesh
namespace namespace 2 Applies to services in specific namespace
service service 3 Applies to specific service instance
workload workload 4 Applies to specific workload type
request request 5 (lowest) Applies to specific request attributes

Example: Policy Precedence Configuration

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: global-policy
  namespace: istio-system
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/svc-account"]
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: namespace-policy
  namespace: default
spec:
  action: DENY
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/prod-account"]
Note: Precedence is determined by the order of policy application, with global policies taking precedence over namespace and service-level policies.

8. Implementing Audit Mode

Example: Enabling Audit Mode in Istio

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: audit-policy
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istiod
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/audit-sa"]
    when:
    - key: request.headers["x-forwarded-for"]
      values: ["10.0.0.0/8"]
    - key: request.headers["x-forwarded-proto"]
      values: ["https"]
    action: AUDIT
Field Description Values Notes
action Specifies the action to take for the request AUDIT Logs the request but allows it to proceed
from.source.principals Identifies the client principal for audit logging cluster.local/ns/<namespace>/sa/<service-account> Must be a valid service account in the cluster
when.key Condition key to evaluate for audit logging request.headers["x-forwarded-for"] Can be any header or attribute
Note: Audit mode does not block traffic, it only logs the request for compliance or monitoring purposes.
Warning: Ensure that audit logs are securely stored and rotated to prevent log flooding.

Audit Mode Configuration Summary

  • Use AUDIT action to log requests without blocking
  • Define principals to identify the auditing service account
  • Apply conditions using when clauses to scope audit logging
  • Ensure logs are handled securely and rotated regularly

9. Configuring Dry Run Mode

Dry run mode allows you to test authorization policies without enforcing them, enabling validation and debugging before applying changes in production.

Configuration Option Description Values Notes
policy.dryRun Enables or disables dry run mode for a policy true / false When enabled, policy decisions are logged but not enforced
policy.dryRun.logLevel Log level for dry run policy decisions info, warn, error Defaults to info

Example: Dry Run Policy Configuration

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: dry-run-policy
spec:
  selector:
    matchLabels:
      app: backend
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/service-account"]
  policy:
    dryRun: true
    dryRun.logLevel: warn
Note: Dry run mode is useful for validating policy changes in a staging environment before applying them to production.

10. Troubleshooting Authorization Issues

Issue Possible Cause Solution
Access Denied (403) Missing or incorrect permissions Check RBAC rules and ensure user/role has required access
Authentication Failure Invalid token or expired session Validate JWT token or re-authenticate user
Policy Not Applied Incorrect policy scope or namespace Verify policy is applied to correct service or namespace
Unexpected Denials Conflicting policies or misconfigured rules Review all authorization policies for overlaps or contradictions

Example: Debugging Policy Application

istioctl proxy-config cluster <pod-name> -n <namespace>
kubectl describe authorizationpolicy <policy-name> -n <namespace>
Note: Use istioctl to inspect proxy configuration and verify that authorization policies are correctly loaded.
Warning: Misconfigured policies can lead to unintended access or denial of legitimate requests.

Common Troubleshooting Steps

  • Check logs for authorization errors
  • Validate policy syntax and scope
  • Ensure service accounts have proper permissions
  • Review network policies and mTLS settings

11. Implementing Fine-Grained Authorization

Policy Type Description Example Notes
Request Authentication Verifies the identity of the requester using tokens or certificates. 
{
  "request": {
    "auth": {
      "principal": "user@example.com"
    }
  }
}
 Used in conjunction with JWT or mTLS
Resource-Based Access Control (RBAC) Defines access based on resource attributes like namespace, service name, or labels. 
{
  "resource": {
    "namespace": "production",
    "service": "api-v1"
  }
}
 Enables granular control over specific services or resources
Attribute-Based Access Control (ABAC) Uses attributes such as user roles, time of day, or client IP to make access decisions. 
{
  "attributes": {
    "userRole": "admin",
    "time": "09:00-17:00"
  }
}
 Supports dynamic and context-aware policies

Example: RBAC Policy for Service Access

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get", "list"]

Example: ABAC Policy with Time-Based Access

{
  "policy": {
    "name": "time-bound-access",
    "conditions": [
      {
        "attribute": "timeOfDay",
        "operator": "between",
        "values": ["09:00", "17:00"]
      }
    ],
    "actions": ["read", "write"]
  }
}
Note: Fine-grained policies can be enforced at the service mesh level using tools like Istio's AuthorizationPolicy or Linkerd's RBAC. These policies can be combined with other security mechanisms like mTLS and JWT validation.

12. Managing Authorization Policy Updates

Field Description Values Notes
metadata.name Unique identifier for the policy authz-policy Must be unique within the namespace
spec.rules Authorization rules to apply [{from: [{source: {principal: "cluster.local/ns/default/sa/client"}}], to: [{operation: {methods: ["GET"]}}]}] Array of rule objects
spec.selector Target workload to apply policy to {matchLabels: {app: "backend"}} Used to select workloads by labels

Example: Update Authorization Policy

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: authz-policy
  namespace: default
spec:
  selector:
    matchLabels:
      app: backend
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/client"]
    to:
    - operation:
        methods: ["GET", "POST"]
Note: Changes to authorization policies are propagated asynchronously across the service mesh. Ensure all proxies have received the update before testing.

Was this article helpful?

Related Cheat Sheets