Protecting APIs Deployed Behind Istio Service Mesh

To delegate access control enforcement to your Istio Authorizer, you need to define it as an external authorization provider for your Istio Service Mesh.

With Istio Authorizer installed and attached to Istio Service Mesh as an external authorization provider, you can:

Deploy a sample HTTP service using the following command:

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
spec:
  selector:
    app: httpbin
  ports:
  - port: 80
    name: http
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
  labels:
    app: httpbin
  annotations:
    services.k8s.cloudentity.com/spec-url: "http://httpbin.org/spec.json"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      serviceAccountName: httpbin
      containers:
      - name: httpbin
        image: "kennethreitz/httpbin"
        ports:
        - containerPort: 80
          name: http
EOF            

There are two ways to connect Istio API groups to SecureAuth services: starting from the gateway to be connected or starting from the service that you want to connect.

Once SecureAuth has discovered the APIs deployed behind your Istio gateway, you can protect those APIs with an SecureAuth policy.

To test your deployed and protected service, change the variables and execute the command:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/sleep/sleep.yaml
export SLEEP_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec -it $SLEEP_POD -c sleep curl {YOUR_SERVICE_URL}/{ENDPOINT}            

Example:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/sleep/sleep.yaml
export SLEEP_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec -it $SLEEP_POD -c sleep curl http://httpbin:80/deny               

Verify that the request is blocked or passing in accordance with your applied policy.

gRPC is an open source Remote Procedure Call (RPC) framework that allows you to efficiently connect services to data centers while maintaining a high performance results. gRPC uses protocol buffers as both its Interface Definition Language (IDL) and as its underlying message interchange format.

It makes it easier to create a distributed applications and services system with gRPC, as your client applications can directly call methods on the server application that resides on a different machine as they were local objects. Most of the RPCs, including gRPC, are based on the solution to define a service and to specify the methods that can be called remotely with their parameters and return types. On the server side (in this case, SecureAuth, the server implements those interfaces and runs a gRPC server that handles the requests coming from client applications.

Deploy a sample grpc service using the following command:

kubectl apply -f https://raw.githubusercontent.com/cloudentity/acp-on-k8s/master/examples/fortune-teller/deployment.yaml            

There are two ways to connect Istio API groups to SecureAuth services: starting from the gateway to be connected or starting from the service that you want to connect.

To test your deployed and protected service, change the variables and execute the command:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/sleep/sleep.yaml
export SLEEP_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec -it $SLEEP_POD -c sleep curl {YOUR_SERVICE_URL}/{ENDPOINT}            

Example:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/sleep/sleep.yaml
export SLEEP_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec -it $SLEEP_POD -c sleep curl http://httpbin:80/deny               

# acp
acp:
    reload_interval: 1m0s # reload interval
    reload_timeout: 30s # reload configuration timeout
    issuer_url: https://localhost:8443/sample/system # issuer url
    client_id: bqesdrc4m4co2s81mpu0 # client id
    client_secret: LH6mAb6PNljvjYMIF-A5RP2bElA5a5bnQah8sG0fsLA # client secret
    tenant_id: "" # tenant id
    server_id: "" # server id
# http client
http_client:
    timeout: 10s # http client timeout
    retry_wait_min: 0s # minimum time to wait between retries
    retry_wait_max: 0s # maximum time to wait between retries
    retry_max: 0 # maximum number of retries
    root_ca: "" # root ca that this client should trust (defaults to system root ca)
    insecure_skip_verify: false # disable cert verification
    disable_follow_redirects: false # disable follow redirects
    disable_retry: true # disable retry
# metrics
metrics:
    enabled: false # enable metrics endpoint
    port: 9000 # metrics endpoint port
# analytics
analytics:
    enabled: true # when enabled, events are sent to audit log
    # event format
    event_format:
        include_policy_output: false # when enabled, policy evaluation output is sent to audit log
    # sampling
    sampling:
        probability: 1 # Probability of an event to be published (0.0-1.0)
        batch_inverval: 1s # Max duration to wait for a batch to publish
        batch_limit: 100 # Max number of events in a batch
        limit: 5 # Max number of batches per second to be published
        timeout: 5s # Timeout for a single batch to send
        workers: 8 # Number of sending workers
# cache
cache:
    ttl: 10s # ttl
    max_size: 100 # max size
# logging config
logging:
    level: info # log level severity
# token echange config
token_exchange:
    enabled: false # enable token exchange
    # cache
    cache:
        ttl: 1m0s # ttl
        max_size: 1000 # max size
    # inject config (supported only for istio authorizer)
    inject:
        mode: "" # Defines what token should be sent to the target service when token is exchanged
        # headers config
        headers:
            exchanged_token: "" # Defines the name of the header that contains an exchanged token.
            original_token: "" # Defines the name of the header that contains an original token.
            strip_bearer: false # Allows to strip the bearer prefix in headers
# enforcement config
enforcement:
    allow_unknown: false # allow requests with no matching rule
# discovery config
discovery:
    enabled: true # when true, API discovery is enabled
    timeout: 10s # discovery process timeout
    interval: 30s # how often discovery is performed
    disable_proxy: false # disable proxy in discovery
    open_api_endpoint: "" # if your service is self-hosting an OpenAPI endpoint, you need to provide the path to this endpoint to enable Istio authorizer to call this endpoint and automatically discover your APIs
    # discover services in a given namespaces
    namespaces:
        - default
    grpc_reflection_calls: false # allow grpc reflection calls
# http server
http_server:
    port: 9002 # http port
    dangerous_disable_tls: true # diables TLS
    # certificate configuration
    certificate:
        password: "" # key passphrase
        cert_path: "" # path to the certificate PEM file
        key_path: "" # path to the key PEM file
        cert: "" # base64 encoded cert PEM
        key: "" # base64 encoded key PEM
        generated_key_type: "" # type for generated key if cert and key are not provided (rsa or ecda)
    client_auth_type: 0 # client auth type
# grpc server
grpc_server:
    port: 9001 # gRPC port
# target service config
target_service:
    # inject config
    inject:
        # headers config
        headers:
            custom_data_prefix: x-output- # custom data header name prefix used to propage global variables defined in a policy
            auth_ctx: x-auth-ctx # header name containing base64 encoded authentication context json object
trust_domain: cluster.local
kubeconfig: "" # absolute path to the kubeconfig file            

Install Istio Authorizer using its Helm Chart and adjust its configuration to your needs. You do not need to manually create your authorizer in SecureAuth's UI as you had already imported the authorizer in the previous step of this guide.

To learn how to import API groups and services and to know what are the possible scenarios that differ between your authorizer configuration for service discovery, get familiar with the API groups and services section of the Declarative configuration import for SecureAuth article.

For Istio Authorizer, API group identifier and service identifiers are Base64 URL encoded SPIFFE IDs which are built being based on the service account of the protected pod. To avoid using long and unreadable API groups identifiers, SecureAuth supports Base64 encoding of SPIFFE IDs.

You can define your API group identifier using the encSpiffeID function as shown below:

gateway_api_groups:
  - id: "{{ encSpiffeID \"spiffe://{domain}/ns/{namespace}/sa/{service_account}\" }}"            

You can define your service identifier using the encServiceID function as shown below:

services:
  - id: "{{ encServiceID \"spiffe://{domain}/ns/{namespace}/sa/{service_account}\" }}"            

Example:

$ curl -v http://httpbin.default:80/get
...
< HTTP/1.1 403 Forbidden
RBAC: access denied            

If your calls to protected APIs always result with the RBAC: access denied response, verify your Istio configuration for Istio authorization policies and Istio configuration (configmap). Such response may be a result of Istio changing the authorization policy from, for example, ALLOW or CUSTOM to DENY:

│ 2022-10-07T13:49:40.972592Z    error    authorization    Processed authorization policy: failed to parse CUSTOM action, will generate a deny all config: available providers are [] but found "acp-authorizer"  │            

In case of the SecureAuth Istio Authorizer, such situation may happen if you duplicate the extensionProviders configuration in your Istio configmap when adding the acp-authorizer extension provider.

Incorrect Configmap Example:

apiVersion: v1
data:
  mesh: |-
    extensionProviders:
    - name: "acp-authorizer"
      envoyExtAuthzGrpc:
        service: "istio-authorizer.acp-istio-authorizer.svc.cluster.local"
        port: 9001
    accessLogFile: /dev/stdout
    defaultConfig:
      discoveryAddress: istiod.istio-system.svc:15012
      proxyMetadata: {}
      tracing:
        zipkin:
          address: zipkin.istio-system:9411
    enablePrometheusMerge: true
    extensionProviders:
    - envoyOtelAls:
        port: 4317
        service: opentelemetry-collector.istio-system.svc.cluster.local
      name: otel    
[...]            

In the example above, notice how the extensionProviders entry is added twice to the Istio configuration. Because of this, Istio treats your configuration for the acp-authorizer as invalid and switches the following Istio authorization policy for the SecureAuth Istio Authorizer from the CUSTOM action to the DENY_ALL action:

Spec:
  Action: CUSTOM
  Provider:
    Name: acp-authorizer
  Rules:
Events: <none>            

Correct Configmap Example:

apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
    defaultConfig:
      discoveryAddress: istiod.istio-system.svc:15012
      proxyMetadata: {}
      tracing:
        zipkin:
          address: zipkin.istio-system:9411
    enablePrometheusMerge: true
    extensionProviders:
    - envoyOtelAls:
        port: 4317
        service: opentelemetry-collector.istio-system.svc.cluster.local
      name: otel
    - name: "acp-authorizer"
      envoyExtAuthzGrpc:
        service: "istio-authorizer.acp-istio-authorizer.svc.cluster.local"
        port: 9001    
[...]