Install Kube Token Refresher

As discussed in Connecting the Service Catalog to a Service Broker, issued tokens might only be valid for a short period of time. For this purpose we developed the kube-token-refresher, which periodically fetches a new bearer token and writes it to a secret for the Service Catalog.

You will need access to an OIDC provider, valid credentials to request a Bearer Token, and permission to get, update, and create secrets.

The Kube Token Refresher only manages a single secret. If you need multiple brokers with different short lived bearer tokens, you will need to deploy the token refresher multiple times.

Kubernetes RBAC

To allow the Kube Token Refresher to manage the secret, we need to create a Service Account and a corresponding Role. Apply the following in the same namespace the Kube Token Refresher will be deployed to.

With this RBAC configuration the token refresher must run in the namespace of the secret which it refreshes. 
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube-token-refresher

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kube-token-refresher
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kube-token-refresher
subjects:
- kind: ServiceAccount
  name: kube-token-refresher

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kube-token-refresher
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - update

OIDC Credentials

Next you will need to get a client_id and client_secret to request a access_token. Create these on your authentication server or contact authorized personnel.

Then write them to a secret in the namespace the Kube Token Refresher will be deployed.

---
apiVersion: v1
stringData:
  id: <client_id>
  secret: <client_secret>
kind: Secret
metadata:
  name: kube-token-refresher
type: Opaque

Standalone Deployment

Finally we will deploy the Token Refresher. In this section we will deploy it as a standalone deployment.

Apply the following:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: kube-token-refresher
  name: token-refresher
spec:
  replicas: 1
  selector:
    matchLabels:
      app: token-refresher
  template:
    metadata:
      labels:
        app: token-refresher
    spec:
      containers:
      - name: refresher
        env:
        - name: KTR_SECRET_NAME
          value: "bearer-creds"
        - name: KTR_SECRET_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: KTR_INTERVAL
          value: 500
        - name: KTR_OIDC_TOKENURL
          value: <token-url>
        - name: KTR_OIDC_CLIENTID
          valueFrom:
            secretKeyRef:
              name: kube-token-refresher
              key: id
        - name: KTR_OIDC_CLIENTSECRET
          valueFrom:
            secretKeyRef:
              name: kube-token-refresher
              key: secret
        image: quay.io/vshn/kube-token-refresher:latest
        imagePullPolicy: Always
        resources:
          limits:
            cpu: 100m
            memory: 30Mi
          requests:
            cpu: 100m
            memory: 10Mi
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      serviceAccountName: kube-token-refresher

There are a few things that can be configured.

  • KTR_SECRET_NAME: The name of the secret that will be updated. This is the same secret referenced as a bearer-secret when registering the service catalog

  • KTR_SECRET_NAMESPACE: The namespace this secrets is in. This example assumes it to be in the same namespace as the deployment.

  • KTR_INTERVAL: In what interval (in seconds) to fetch a new token. This depends on your authentication server. Expect some delays and request a new token early enough.

  • KTR_OIDC_TOKENURL: The URL to fetch the token from. See Bearer Token authentication for more details on what this is.

  • KTR_OIDC_CLIENTID and KTR_OIDC_CLIENTSECRET: The credentials we created earlier.