Hello All, Can someone please help me with this query: How this flag "authenti . . .

Kubernetes-Slack Discussions
#1

Jahnavi:
Hello All, Can someone please help me with this query:

How this flag “authentication-token-webhook-cache-ttl” actually working in API server. Does whenever request is hit to wehbook service for authentication by API server, if the token response was cached in API server. In that case does the same token request reaches to webhook service again even though response was cached in API server side.

#2

Mohamed Ayman:
Hello @Jahnavi,
• --authentication-token-webhook-cache-ttl how long to cache authentication decisions. Defaults to two minutes.
The configuration file uses the https://unofficial-kubernetes.readthedocs.io/en/latest/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/|kubeconfig file format. Within the file “users” refers to the API server webhook and “clusters” refers to the remote service. An example would be:

# clusters refers to the remote service.
clusters:
  - name: name-of-remote-authn-service
    cluster:
      certificate-authority: /path/to/ca.pem         # CA for verifying the remote service.
      server: <https://authn.example.com/authenticate> # URL of remote service to query. Must use 'https'.

# users refers to the API server's webhook configuration.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
      client-key: /path/to/key.pem          # key matching the cert

# kubeconfig files require a context. Provide one for the API server.
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authn-service
    user: name-of-api-sever
  name: webhook

When a client attempts to authenticate with the API server using a bearer token as discussed https://unofficial-kubernetes.readthedocs.io/en/latest/admin/authentication/#putting-a-bearer-token-in-a-request|above, the authentication webhook queries the remote service with a review object containing the token. Kubernetes will not challenge a request that lacks such a header.
Note that webhook API objects are subject to the same <https://unofficial-kubernetes.readthedocs.io/en/latest/docs/api/|versioning compatibility rules> as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for beta objects and check the “apiVersion” field of the request to ensure correct deserialization. Additionally, the API server must enable the <http://authentication.k8s.io/v1beta1|authentication.k8s.io/v1beta1> API extensions group (--runtime-config=<http://authentication.k8s.io/v1beta1=true|authentication.k8s.io/v1beta1=true>).
The request body will be of the following format:

{
  "apiVersion": "<http://authentication.k8s.io/v1beta1|authentication.k8s.io/v1beta1>",
  "kind": "TokenReview",
  "spec": {
    "token": "(BEARERTOKEN)"
  }
}

The remote service is expected to fill the TokenAccessReviewStatus field of the request to indicate the success of the login. The response body’s “spec” field is ignored and may be omitted. A successful validation of the bearer token would return:

{
  "apiVersion": "<http://authentication.k8s.io/v1beta1|authentication.k8s.io/v1beta1>",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
      "username": "<mailto:[email protected]|[email protected]>",
      "uid": "42",
      "groups": [
        "developers",
        "qa"
      ],
      "extra": {
        "extrafield1": [
          "extravalue1",
          "extravalue2"
        ]
      }
    }
  }
}

An unsuccessful request would return:

{
  "apiVersion": "<http://authentication.k8s.io/v1beta1|authentication.k8s.io/v1beta1>",
  "kind": "TokenReview",
  "status": {
    "authenticated": false
  }
}

HTTP status codes can be used to supply additional error context.

#3

Mohamed Ayman:
Check this useful documentation for more details https://unofficial-kubernetes.readthedocs.io/en/latest/admin/authentication/

#4

Jahnavi:
Hello @Mohamed Ayman, thanks for the reply. I understood the token review process, can you please confirm if the same token reaches at API server multiple times in that case does the token review does everytime or because of this cache the response will be back to client without going to webhook service.