User guide: Passing credentials (Authorization
header, cookie headers and others)¶
Customize where credentials are supplied in the request by each trusted source of identity.
Authorino capabilities featured in this guide:
- Identity verification & authentication → Auth credentials
- Identity verification & authentication → API key
Authentication tokens can be supplied in the Authorization
header, in a custom header, cookie or query string parameter.
Check out as well the user guide about Authentication with API keys.
For further details about Authorino features in general, check the docs.
Requirements¶
- Kubernetes server with permissions to install cluster-scoped resources (operator, CRDs and RBAC)
If you do not own a Kubernetes server already and just want to try out the steps in this guide, you can create a local containerized cluster by executing the command below. In this case, the main requirement is having Kind installed, with either Docker or Podman.
The next steps walk you through installing Authorino, deploying and configuring a sample service called Talker API to be protected by the authorization service.
Using Kuadrant |
---|
If you are a user of Kuadrant and already have your workload cluster configured and sample service application deployed, as well as your Gateway API network resources applied to route traffic to your service, skip straight to step ❺. At step ❺, instead of creating an For more about using Kuadrant to enforce authorization, check out Kuadrant auth. |
❶ Install the Authorino Operator (cluster admin required)¶
The following command will install the Authorino Operator in the Kubernetes cluster. The operator manages instances of the Authorino authorization service.
curl -sL https://raw.githubusercontent.com/Kuadrant/authorino-operator/main/utils/install.sh | bash -s
❷ Deploy Authorino¶
The following command will request an instance of Authorino as a separate service1 that watches for AuthConfig
resources in the default
namespace2, with TLS disabled3.
kubectl apply -f -<<EOF
apiVersion: operator.authorino.kuadrant.io/v1beta1
kind: Authorino
metadata:
name: authorino
spec:
listener:
tls:
enabled: false
oidcServer:
tls:
enabled: false
EOF
❸ Deploy the Talker API¶
The Talker API is a simple HTTP service that echoes back in the response whatever it gets in the request. We will use it in this guide as the sample service to be protected by Authorino.
kubectl apply -f https://raw.githubusercontent.com/kuadrant/authorino-examples/main/talker-api/talker-api-deploy.yaml
❹ Setup Envoy¶
The following bundle from the Authorino examples deploys the Envoy proxy and configuration to wire up the Talker API behind the reverse-proxy, with external authorization enabled with the Authorino instance.4
kubectl apply -f https://raw.githubusercontent.com/kuadrant/authorino-examples/main/envoy/envoy-notls-deploy.yaml
The command above creates an Ingress
with host name talker-api.127.0.0.1.nip.io
. If you are using a local Kubernetes cluster created with Kind, forward requests from your local port 8000 to the Envoy service running inside the cluster:
❺ Create an AuthConfig
¶
Create an Authorino AuthConfig
custom resource declaring the auth rules to be enforced.
In this example, member
users can authenticate supplying the API key in any of 4 different ways:
- HTTP header Authorization: APIKEY <api-key>
- HTTP header X-API-Key: <api-key>
- Query string parameter api_key=<api-key>
- Cookie Cookie: APIKEY=<api-key>;
admin
API keys are only accepted in the (default) HTTP header Authorization: Bearer <api-key>
.
Kuadrant users –
Remember to create an AuthPolicy instead of an AuthConfig.
For more, see Kuadrant auth.
|
kubectl apply -f -<<EOF
apiVersion: authorino.kuadrant.io/v1beta2
kind: AuthConfig
metadata:
name: talker-api-protection
spec:
hosts:
- talker-api.127.0.0.1.nip.io
authentication:
"members-authorization-header":
apiKey:
selector:
matchLabels:
group: members
credentials:
authorizationHeader:
prefix: APIKEY # instead of the default prefix 'Bearer'
"members-custom-header":
apiKey:
selector:
matchLabels:
group: members
credentials:
customHeader:
name: X-API-Key
"members-query-string-param":
apiKey:
selector:
matchLabels:
group: members
credentials:
queryString:
name: api_key
"members-cookie":
apiKey:
selector:
matchLabels:
group: members
credentials:
cookie:
name: APIKEY
"admins":
apiKey:
selector:
matchLabels:
group: admins
EOF
❻ Create the API keys¶
For a member user:
kubectl apply -f -<<EOF
apiVersion: v1
kind: Secret
metadata:
name: api-key-1
labels:
authorino.kuadrant.io/managed-by: authorino
group: members
stringData:
api_key: ndyBzreUzF4zqDQsqSPMHkRhriEOtcRx
type: Opaque
EOF
For an admin user:
kubectl apply -f -<<EOF
apiVersion: v1
kind: Secret
metadata:
name: api-key-2
labels:
authorino.kuadrant.io/managed-by: authorino
group: admins
stringData:
api_key: 7BNaTmYGItSzXiwQLNHu82+x52p1XHgY
type: Opaque
EOF
❼ Consume the API¶
As member user, passing the API key in the Authorization
header:
curl -H 'Authorization: APIKEY ndyBzreUzF4zqDQsqSPMHkRhriEOtcRx' http://talker-api.127.0.0.1.nip.io:8000/hello
# HTTP/1.1 200 OK
As member user, passing the API key in the custom X-API-Key
header:
curl -H 'X-API-Key: ndyBzreUzF4zqDQsqSPMHkRhriEOtcRx' http://talker-api.127.0.0.1.nip.io:8000/hello
# HTTP/1.1 200 OK
As member user, passing the API key in the query string parameter api_key
:
curl "http://talker-api.127.0.0.1.nip.io:8000/hello?api_key=ndyBzreUzF4zqDQsqSPMHkRhriEOtcRx"
# HTTP/1.1 200 OK
As member user, passing the API key in the APIKEY
cookie header:
curl -H 'Cookie: APIKEY=ndyBzreUzF4zqDQsqSPMHkRhriEOtcRx;foo=bar' http://talker-api.127.0.0.1.nip.io:8000/hello
# HTTP/1.1 200 OK
As admin user:
curl -H 'Authorization: Bearer 7BNaTmYGItSzXiwQLNHu82+x52p1XHgY' http://talker-api.127.0.0.1.nip.io:8000/hello
# HTTP/1.1 200 OK
Missing the API key:
curl http://talker-api.127.0.0.1.nip.io:8000/hello -i
# HTTP/1.1 401 Unauthorized
# www-authenticate: APIKEY realm="members-authorization-header"
# www-authenticate: X-API-Key realm="members-custom-header"
# www-authenticate: api_key realm="members-query-string-param"
# www-authenticate: APIKEY realm="members-cookie"
# www-authenticate: Bearer realm="admins"
# x-ext-auth-reason: {"admins":"credential not found","members-authorization-header":"credential not found","members-cookie":"credential not found","members-custom-header":"credential not found","members-query-string-param":"credential not found"}
Cleanup¶
If you have started a Kubernetes cluster locally with Kind to try this user guide, delete it by running:
Otherwise, delete the resources created in each step:
kubectl delete secret/api-key-1
kubectl delete secret/api-key-2
kubectl delete authconfig/talker-api-protection
kubectl delete -f https://raw.githubusercontent.com/kuadrant/authorino-examples/main/envoy/envoy-notls-deploy.yaml
kubectl delete -f https://raw.githubusercontent.com/kuadrant/authorino-examples/main/talker-api/talker-api-deploy.yaml
kubectl delete authorino/authorino
To uninstall the Authorino Operator and manifests (CRDs, RBAC, etc), run:
kubectl delete -f https://raw.githubusercontent.com/Kuadrant/authorino-operator/main/config/deploy/manifests.yaml
-
In contrast to a dedicated sidecar of the protected service and other architectures. Check out Architecture > Topologies for all options. ↩
-
namespaced
reconciliation mode. See Cluster-wide vs. Namespaced instances. ↩ -
For other variants and deployment options, check out Getting Started, as well as the
Authorino
CRD specification. ↩ -
For details and instructions to setup Envoy manually, see Protect a service > Setup Envoy in the Getting Started page. If you are running your ingress gateway in Kubernetes and wants to avoid setting up and configuring your proxy manually, check out Kuadrant. ↩