Database Cleanup

Suggest Edits

OAuth and OIDC runtime flows persist data into the runtime database, such as the OAuth tokens. Most of the persisted data has expiry. This expired data needs to be cleaned up from the database so that the disk space can be recovered and the table be kept as small as possible for better database performance.

Besides expired data, there are other use cases that trigger data cleanup, for example client or user deletion.

In IBM Security Verify Access, the clean up is done by a scheduled thread that runs every few minutes. IBM Security Verify Access OIDC Provider uses a slightly different approach by providing a janitor binary that can be run to perform the clean up. The recommendation is that the janitor binary is run as a separate container or pod. The benefit of this is that the clean up does not use any of the runtime resources. Because it is a binary, a schedule needs to configured based on time of the day when the load is not high. For certain scenarios you might want to trigger the cleanup straightaway, for example when the user is deleted. The tokens need to be cleaned up as soon as possible.

Cleanup expired data

To cleanup expired data execute:

[demouser@demovm ~]$ docker run --rm --volume {path_to_mount}:/var/isvaop/config/ icr.io/isva/verify-access-oidc-provider:23.12 /app/janitor

This command cleans up expired tokens, unused grants and expired JTI. If the session cache persists data into the database, the expired entries are cleaned up as well. Once the cleanup is complete the container will be removed.

Cleanup client data

To cleanup client01 client data execute:

[demouser@demovm ~]$ docker run --rm --volume {path_to_mount}:/var/isvaop/config/ icr.io/isva/verify-access-oidc-provider:23.12 clientID client01

You can specify more than one client ID. The client IDs must be separated by space. This command cleans up tokens and consent data that is related to the client ID.

Cleanup user data

To cleanup testuser user data execute:

[demouser@demovm ~]$ docker run --rm --volume {path_to_mount}:/var/isvaop/config/ icr.io/isva/verify-access-oidc-provider:23.12 username testuser

You can specify more than one user. The users must be separated by space. This command cleans up tokens and consent data that is related to the user.

Settings related to janitor

In provider.yml, you can specify a janitor configuration stanza as shown. If not specified, it uses the default values as show in the following example.

janitor:
  batch_size: 1000
  max_duration: 0
  check_frequency: 10
  • The batch_size is the maximum records being cleaned up with each iteration.
  • When the max_duration is set to 0, the janitor program runs until all records are cleaned up. Depending on how often you run the janitor, the number of records can be large. The maximum duration needs to be specified in milliseconds.
  • The check_frequency indicates the number of iterations to be run before the janitor check whether the maximum duration is exceeded. If the default value is used, after the janitor runs 10 iterations, which clean up 10,000 records, the janitor checks whether the time taken was exceeded. It then runs the next 10 iterations before it checks the time that was taken again.

Cleanup data automatically

Use a task scheduler like cron to run janitor automatically.

Docker and Docker Compose

Use crontab to create a janitor Cron Job on a Linux® system, which hosts the IBM Security Verify Access OIDC Provider container.

Prerequisites

Deployment

Create the Cron Job

📘

Note

To configure the schedule, see cron syntax.

Use the following command to edit the crontab file:

[demouser@demovm ~]$ crontab -e

Press i to switch to Insert mode, and insert a newline 0 0 * * * docker run --rm --volume {path_to_mount}:/var/isvaop/config/ icr.io/isva/verify-access-oidc-provider:23.12 /app/janitor.

📘

Note

Replace ${path_to_mount} with the actual mount path.

This command runs janitor daily at 00:00. To executes janitor hourly, change 0 0 * * * to 0 * * * *.
See https://en.wikipedia.org/wiki/Cron for cron syntax.

Press Esc to exit Insert mode, type :wq to save and exit.

Use the following command to verify that the crontab file is updated.

[demouser@demovm ~]$ crontab -l

Check the Cron Job results

The Cron Job logs can be found in /var/log/cron.

Remove the Cron Job

When the Cron Job is no longer needed, remove it from the crontab file.

[demouser@demovm ~]$ crontab -e

Go the line 0 0 * * * docker run --rm --volume ${path_to_mount}:/var/isvaop/config/ icr.io/isva/verify-access-oidc-provider:23.12 /app/janitor, type dd to delete the line, and type :wq to
save and exit.

Use the following command to verify that the Cron Job is removed.

[demouser@demovm ~]$ crontab -l

Kubernetes

Use CronJob to run janitor automatically on Kubernetes.

For more information about Kubernetes CronJob, see https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/.

Kubernetes creates new Pods to run CronJob. The IBM Security Verify Access OIDC Provider janitor CronJob Pods require
ConfigMaps and a secret to access janitor and database configurations. The ConfigMaps and secret are created
by Deploy IBM Security Verify Access OIDC Provider on Kubernetes.

Prerequisites

Deployment

Create the CronJob

To deploy an IBM Security Verify Access OIDC Provider janitor CronJob in Kubernetes, a deployment descriptor must
first be created.
The following deployment YAML file (isvaop-cron.yaml) is a sample, which references the ConfigMaps and secret that are
created by Deploy IBM Security Verify Access OIDC Provider on Kubernetes.

Use the following isvaop-cron.yml to deploy the CronJob.

📘

Note

The initContainer that is defined in this CronJob unpacks the configuration to fit the structure that is expected by
ISVAOP janitor.

To configure the schedule, see cron syntax.

## 
## The janitor cron job for the isvaop service.  
##
apiVersion: batch/v1
kind: CronJob
metadata:
  name: isvaop-cron
spec:
  # Run the janitor daily at 00:00
  # To run the janitor hourly, set schedule to "0 * * * *"
  # See https://en.wikipedia.org/wiki/Cron for cron syntax.
  schedule: "0 0 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          # The name of the service account which has the required
          # capabilities enabled for the ISVAOP container.
          serviceAccountName: isvaop
          # We use multiple volumes to store the configuration data.
          volumes:
            - name: isvaop-enckey
              secret:
                secretName: isvaop-secrets
                items:
                  - key: private.pem
                    path: private.pem
            - name: isvaop-staged-config
              configMap:
                name: isvaop-config
            - name: isvaop-config
              emptyDir: { }

          initContainers:
            - name: create-bootstrap-dir
              image: registry.access.redhat.com/ubi8/ubi-minimal:latest
              # Mount our volumes to the expected configuration directory
              volumeMounts:
                - name: isvaop-staged-config
                  mountPath: /var/isvaop/staged
                - name: isvaop-enckey
                  mountPath: /var/isvaop/secrets
                - name: isvaop-config
                  mountPath: /var/isvaop/config
              command:
                - "bash"
                - "-c"
                - |
                  microdnf update \
                    && microdnf install --nodocs unzip \
                    && microdnf clean all

                  mkdir -p /var/isvaop/config/secrets
                  echo "Copying base configuration" && cp -RLv /var/isvaop/staged/* /var/isvaop/config/
                  echo "Copying secrets configuration" && cp -RLv /var/isvaop/secrets/* /var/isvaop/config/secrets/

                  pushd /var/isvaop/config
                  echo "Contents of /var/isvaop/config: " && ls -al ./
                  echo "Unpacking keystores"
                  # Unzip keystores if provided
                  mkdir -p ./keystore
                  [ -f "./keystore.zip" ] && \
                      rm -rf ./keystore/* && \
                      unzip ./keystore.zip -d ./keystore
                  echo "PROVIDER configuration" && cat ./provider.yml
                  popd
          containers:
            - name: isvaop-cron
              # The fully qualified name of the ISVAOP image.
              image: icr.io/isva/verify-access-oidc-provider:23.12

              # Mount our volumes to the expected configuration directory
              volumeMounts:
                - name: isvaop-config
                  mountPath: /var/isvaop/config
              command:
                - /bin/sh
                - -c
                - /app/janitor
          restartPolicy: OnFailure

The Kubernetes CronJob can then be created by using the following command.

[demouser@demovm ~]$ kubectl apply -f isvaop-cron.yml

Check the CronJob Status

After you create the CronJob, get its status by using the following command.

[demouser@demovm ~]$ kubectl get cronjob isvaop-cron

Remove the Cron Job

When the CronJob is no longer needed, delete it by using the following command.

[demouser@demovm ~]$ kubectl delete cronjob isvaop-cron

Red Hat® OpenShift®

Use Cron Jobs to run janitor automatically on Red Hat® OpenShift®.

To understand Red Hat® OpenShift® Cron Jobs,
see Red Hat® OpenShift® Cron Jobs.

Red Hat® OpenShift® creates new Pods to run CronJob. The IBM Security Verify Access OIDC Provider janitor CronJob Pods
require ConfigMaps and a secret to access janitor and database configurations. The ConfigMaps and secret are created
by Deploy IBM Security Verify Access OIDC Provider on Red Hat® OpenShift®.

Prerequisites

Deployment

Create the Cron Job

To deploy an IBM Security Verify Access OIDC Provider janitor CronJob in Red Hat® OpenShift®, a deployment descriptor
must first be created.
The following deployment YAML file (isvaop-cron.yaml) is a sample, which references the ConfigMaps and secret that are
created by Deploy IBM Security Verify Access OIDC Provider on Red Hat® OpenShift®.

Use the following isvaop-cron.yml to deploy the Cron Job.

📘

Note

The initContainer defined in this CronJob unpacks the configuration to fit the structure that is expected by ISVAOP
janitor.

To configure the schedule, see cron syntax.

## 
## The janitor cron job of the isvaop service.  
##
apiVersion: batch/v1
kind: CronJob
metadata:
  name: isvaop-cron
spec:
  # Run the janitor daily at 00:00
  # To run the janitor hourly, set schedule to "0 * * * *"
  # See https://en.wikipedia.org/wiki/Cron for cron syntax.
  schedule: "0 0 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          # The name of the service account which has the required
          # capabilities enabled for the ISVAOP container.
          serviceAccountName: isvaop
          # We use multiple volumes to store the configuration data.
          volumes:
            - name: isvaop-enckey
              secret:
                secretName: isvaop-secrets
                items:
                  - key: private.pem
                    path: private.pem
            - name: isvaop-staged-config
              configMap:
                name: isvaop-config
            - name: isvaop-config
              emptyDir: { }

          initContainers:
            - name: create-bootstrap-dir
              image: registry.access.redhat.com/ubi8/ubi-minimal:latest
              # Mount our volumes to the expected configuration directory
              volumeMounts:
                - name: isvaop-staged-config
                  mountPath: /var/isvaop/staged
                - name: isvaop-enckey
                  mountPath: /var/isvaop/secrets
                - name: isvaop-config
                  mountPath: /var/isvaop/config
              command:
                - "bash"
                - "-c"
                - |
                  microdnf update \
                    && microdnf install --nodocs unzip \
                    && microdnf clean all

                  mkdir -p /var/isvaop/config/secrets
                  echo "Copying base configuration" && cp -RLv /var/isvaop/staged/* /var/isvaop/config/
                  echo "Copying secrets configuration" && cp -RLv /var/isvaop/secrets/* /var/isvaop/config/secrets/

                  pushd /var/isvaop/config
                  echo "Contents of /var/isvaop/config: " && ls -al ./
                  echo "Unpacking keystores"
                  # Unzip keystores if provided
                  mkdir -p ./keystore
                  [ -f "./keystore.zip" ] && \
                      rm -rf ./keystore/* && \
                      unzip ./keystore.zip -d ./keystore
                  echo "PROVIDER configuration" && cat ./provider.yml
                  popd
          containers:
            - name: isvaop-cron
              # The fully qualified name of the ISVAOP image.
              image: icr.io/isva/verify-access-oidc-provider:23.12

              # Mount our volumes to the expected configuration directory
              volumeMounts:
                - name: isvaop-config
                  mountPath: /var/isvaop/config
              command:
                - /bin/sh
                - -c
                - /app/janitor
          restartPolicy: OnFailure

The Red Hat® OpenShift® Cron Job can then be created by using the following command.

[demouser@demovm ~]$ oc apply -f isvaop-cron.yml

Check the CronJob Status

After you create the Cron Job, get its status using the following command.

[demouser@demovm ~]$ oc get cronjob/isvaop-cron

Remove the Cron Job

When the CronJob is no longer needed, delete it by using the following command.

[demouser@demovm ~]$ oc delete cronjob/isvaop-cron

Updated 6 months ago