An implementation of Envoy External Authorization, focused on delivering authN/Z solutions for Istio and Kubernetes.
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
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.
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: keycloakIf 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: keycloakThis label can be adjusted via following values in the Big Bang chart:
addons:
authservice:
values:
selector:
key: protect
value: keycloakThe 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: ...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: trueAuthservice can also be configured to communicate with external redis serivces such as Elasticache.
addons:
authservice:
values:
global:
redis_server_uri: "tcp://redis-01.7abc2d.0001.usw2.cache.amazonaws.com:6379"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: 80There is no UI feature for authservice.
Within Big Bang, logs are captured by fluentbit and shipped to elastic by default.
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: 10003When setting replicaCount above 1, a redis configuration is required.