authservice-fips

Fips

Infra

Stig

Updated 4 days ago

Authservice-FIPS Overview

Secure your stack with a hardened Authservice-FIPS image freshly-built by Minimus. Minimus images always include the most up-to-date package version for all packages and dependencies contained in the image.

Authservice is an Envoy external authorization service implementation that works with Istio mesh to handle OIDC login flows, session management, and fine‑grained authN/authZ decisions.

FIPS 140-3 Certification

This image is FIPS-validated to ensure its cryptographic operations meet the Federal Information Processing Standards (FIPS) required for secure government and regulated environments. Its core cryptographic modules are validated under the NIST Cryptographic Module Validation Program (CMVP) and comply with the FIPS 140-3 standard.

To verify that the FIPS 140-3 provider is configured and active, follow the instructions in the FIPS compliance tab.

Try It Out

Authservice runs as an Envoy external authorization service in an Istio mesh. The steps below deploy the Minimus Authservice-FIPS image into a Kubernetes cluster with Istio and configure it to handle OIDC authentication for your workloads.

Prerequisites

A running Kubernetes cluster (v1.21 or higher is recommended) with Istio installed
kubectl installed and configured
An OIDC provider (e.g. Keycloak, Auth0, Google) with a client ID and secret

Step 1: Create the Namespace

Create a namespace for the Authservice deployment:

kubectl create ns authservice

Step 2: Create the Authservice Configuration

Create a Secret for your OIDC client credentials, and a ConfigMap with the Authservice configuration. Replace the placeholder values with your OIDC provider details:

kubectl -n authservice create secret generic client-secret \
    --from-literal=client-secret="YOUR_OIDC_CLIENT_SECRET"

Save the following as authservice-config.yaml:

kind: ConfigMap
apiVersion: v1
metadata:
  name: authservice-config
  namespace: authservice
data:
  config.json: |
    {
      "listen_address": "0.0.0.0",
      "listen_port": "10003",
      "log_level": "debug",
      "allow_unmatched_requests": false,
      "chains": [
        {
          "name": "oidc",
          "filters": [
            {
              "oidc": {
                "configuration_uri": "https://YOUR_OIDC_PROVIDER/.well-known/openid-configuration",
                "callback_uri": "https://YOUR_APP_URL/callback",
                "client_id": "YOUR_CLIENT_ID",
                "client_secret_ref": {
                  "namespace": "authservice",
                  "name": "client-secret"
                },
                "scopes": ["openid", "profile", "email"],
                "id_token": {
                  "preamble": "Bearer",
                  "header": "authorization"
                },
                "access_token": {
                  "header": "x-access-token"
                }
              }
            }
          ]
        }
      ]
    }

Apply the ConfigMap:

kubectl apply -f authservice-config.yaml

Step 3: Deploy Authservice

Save the following as authservice.yaml. The Role + RoleBinding are required because Authservice uses a controller-runtime informer to watch the Secret referenced by client_secret_ref; without them, the OIDC token exchange at the callback step will fail.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: authservice
  namespace: authservice
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: authservice-secrets
  namespace: authservice
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: authservice-secrets
  namespace: authservice
subjects:
  - kind: ServiceAccount
    name: authservice
    namespace: authservice
roleRef:
  kind: Role
  name: authservice-secrets
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Service
metadata:
  name: authservice
  namespace: authservice
spec:
  ports:
    - port: 10003
      targetPort: 10003
      name: grpc-authservice
      protocol: TCP
    - port: 10004
      targetPort: 10004
      name: grpc-health
      protocol: TCP
  selector:
    app: authservice
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: authservice
  namespace: authservice
spec:
  replicas: 1
  selector:
    matchLabels:
      app: authservice
  template:
    metadata:
      labels:
        app: authservice
    spec:
      serviceAccountName: authservice
      containers:
        - name: authservice
          image: reg.mini.dev/authservice-fips
          imagePullPolicy: Always
          ports:
            - name: authz
              containerPort: 10003
              protocol: TCP
            - name: health
              containerPort: 10004
              protocol: TCP
          volumeMounts:
            - name: config
              mountPath: /etc/authservice
          livenessProbe:
            initialDelaySeconds: 1
            periodSeconds: 5
            tcpSocket:
              port: 10003
          readinessProbe:
            initialDelaySeconds: 5
            periodSeconds: 5
            httpGet:
              port: 10004
              path: /healthz
      volumes:
        - name: config
          configMap:
            name: authservice-config

Apply and verify the deployment:

kubectl apply -f authservice.yaml
kubectl -n authservice get pods

You should see the Authservice pod in Running state.

Step 4: Register Authservice as an Istio Extension Provider

Add Authservice as an extensionProvider in your Istio mesh configuration. Edit the istio ConfigMap in the istio-system namespace and add the following under extensionProviders:

extensionProviders:
  - name: authservice
    envoyExtAuthzGrpc:
      service: authservice.authservice.svc.cluster.local
      port: 10003

Then create an AuthorizationPolicy in the namespace of the workload you want to protect:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ext-authz
  namespace: YOUR-APP-NAMESPACE
spec:
  action: CUSTOM
  provider:
    name: authservice
  rules:
    - to:
        - operation:
            paths: ["/*"]

Step 5: Verify

Confirm the Minimus image is running:

kubectl -n authservice get pods -o jsonpath='{.items[*].spec.containers[?(@.name=="authservice")].image}'

Access your protected application. Unauthenticated requests should now be redirected to your OIDC provider's login page. After authentication, Authservice injects the ID token and access token into request headers so your application receives them transparently.

Step 6: Clean Up

Remove the Authservice deployment and namespace:

kubectl delete ns authservice

Technical Considerations

The Authservice-FIPS image provided by Minimus is a slim, security-hardened alternative to the public image from Docker Hub. The images are largely interchangeable, with a few differences as noted below.

Authservice-FIPS built by Minimus:

Runs as non-root by default for a security-first approach that protects against privilege escalation attacks.
Drill down on the version specification tab to see the default user, listening ports, entrypoint, volumes, environment variables, etc.

The Payoff

A hardened, minimal image that will remain more secure for the long run and accrue vulnerabilities at a slower rate.

See the risk reduction dashboard for a detailed CVE comparison over the past 30 days.
Review the compliance report to see the default hardening and security configurations for the image.

Terms & Info

Trademark

This catalog is published by Minimus. All product names, logos, and marks, other than those belonging to Minimus, shown are owned by their respective rights holders and appear here only to identify the open source software each image contains. Minimus claims no ownership of those marks and implies no affiliation with, endorsement by, certification by, or sponsorship by any rights holder.

Disclaimer

Images are provided "as-is" without warranty of any kind. "Hardened" refers to the security configuration applied at the time of build and does not constitute a guarantee of ongoing security or absence of vulnerabilities. The free tier is provided without support, SLA, or guaranteed patching timelines. Security updates may be applied to paid subscriptions before or instead of free tier images. By pulling or using any image you agree to our Terms of Use.