Skip to content

Authservice💣

An implementation of Envoy External Authorization, focused on delivering authN/Z solutions for Istio and Kubernetes.

Overview💣

authservice helps delegate the OIDC Authorization Code Grant Flow to the Istio mesh. authservice is compatible with any standard OIDC Provider as well as other Istio End-user Auth features, including Authentication Policy and RBAC. Together, they allow developers to protect their APIs and web apps without any application code required.

graph LR
  pod("URL") --> authservice
  envoyfilter --> |redirect| pod2("IdP")
  pod2 --> |token| apppods

  subgraph "Authservice"
    subgraph "Any Namespace"
      apppods("Application Pod(s)")
    end

    subgraph "istio-system Namespace"
      envoyfilter{{"Envoy Filter"}}
    end

    subgraph "Authservice Namespace"
      authservice{{"Authservice Service"}} --> envoyfilter
    end

  end

  subgraph "Session Storage (Redis)"
    authservice --> database3[("Authservice DB")]
  end

  subgraph "Logging"
    authservice --> fluent(Fluentbit) --> logging-ek-es-http
    logging-ek-es-http{{Elastic Service<br />logging-ek-es-http}} --> elastic[(Elastic Storage)]
  end

Big Bang Touch Points💣

Licensing💣

Authservice utilizes an Apache-2.0 License. The Iron Bank repo for the hardened authservice image can be found here and the Big Bang repo for the authservice Helm Chart can be found here.

Single Sign On💣

Authservice provides OIDC Single Sign On capabilities for apps that don’t have native support.

Pods just need to have istio-injection, a single label which by default is protect=keycloak applied to the pods, and a corresponding chain to load into authservice.

spec:
  template:
    metadata:
      labels:
        protect: keycloak

If you need to guarantee that authservice protects everything behind istio-ingressgateway, you can label ingressgateway instead of individual applications.

istio:
  ingressGateways:
    public-ingressgateway:
      extraLabels:
        protect: keycloak

This label can be adjusted via following values in the Big Bang chart:

addons:
  authservice:
    values:
      selector:
        key: protect
        value: keycloak

The corresponding chain loaded in to authservice via the values in the Big Bang chart: For more information see the README.md in the Authservice package.

addons:
  authservice:
    chains:
      example:
        callback_uri: ...
        match: ...
        client_id: ...
        client_secret: ...

Storage💣

Authservice can be configured to use a local redis deployment (disabled by default) for distributed state storage. This Redis instance is used cache session data.

addons:
  authservice:
    values:
      redis:
        enabled: true

Authservice can also be configured to communicate with external redis serivces such as Elasticache.

addons:
  authservice:
    values:
      globals:
        redis_server_uri: "tcp://redis-01.7abc2d.0001.usw2.cache.amazonaws.com:6379"

High Availability💣

When setting replicaCount above 1, Authservice will require an HA redis deployment (see above) in order to function.

Authservice also utilizes a horizontal pod autoscaler, which can be configured with min & max replicas and target CPU & memory utilization:

addons:
  authservice:
    values:
      replicaCount: 2
      redis:
        enabled: true
      autoscaling:
        enabled: false
        minReplicas: 1
        maxReplicas: 3
        targetCPUUtilizationPercentage: 80
        targetMemoryUtilizationPercentage: 80

UI💣

There is no UI feature for authservice.

Logging💣

Within Big Bang, logs are captured by fluentbit and shipped to elastic by default.

Health Checks💣

The authservice Dockerfile includes a healthcheck and the authservice Helm Chart includes liveness & readiness probes in its deployment:

livenessProbe:
  tcpSocket:
    port: 10003
readinessProbe:
  tcpSocket:
    port: 10003

Dependent Packages💣

When setting replicaCount above 1, a redis configuration is required.

Last update: 2023-04-21 by Ryan Thompson