Use Kubernetes Data Storage

The Curity Identity Server uses configuration data for most security settings, to support parameterized deployments. For other data, like user accounts, user credentials, session data and token-related information, it depends on one or more data sources.

Curity Identity Server Data Sources

By default, the Curity Identity Server uses a simple in-memory database, which provides convenient options to enable developers to get started quickly. Workloads lose all identity data when they restart, so in-memory storage is only suitable for demo environments. For other environments, update to a durable data source.

The System Admin Guide provides details on the supported data protocols, like JDBC, LDAP, SCIM or DynamoDB Managed Storage. More generally, the Curity Identity Server just uses connection strings to data sources. To prepare for external storage, define a single data source and express its parameters in the configuration.

<data-sources>
    <data-source>
        <id>default-datasource</id>
        <jdbc xmlns="https://curity.se/ns/ext-conf/jdbc">
            <connection-string>#{DB_CONNECTION}</connection-string>
            <driver>#{DB_DRIVER}</driver>
            <password>#{DB_PASSWORD}</password>
            <username>#{DB_USER}</username>
        </jdbc>
    </data-source>
</data-sources>

You should be able to use the same type of data storage for the Curity Identity Server that you already use for APIs, like PostgreSQL, MySQL or Microsft SQL Server. For each provider there is a database initialization script to create the schema in the $IDVSR_HOME/etc folder of the Curity Identity Server or its Docker image. You can deploy the initialization script as a ConfigMap.

The System Admin Guide explains how you can use data sources in a basic way or scale to more advanced deployments, with multiple regions and tenants. Data source deployments can combine the capabilities of the database software, the hosting platform and the storage options that Kubernetes provides.

Select the Type of Storage

A basic durable solution might provision external disk storage from a cloud provider, with RAID-like guarantees and snapshotting capabilities to enable data backup and restore. Once the disk is ready, your database pod can use that storage to persist its data.

• PostgreSQL with Amazon Elastic Block Storage
• Microsoft SQL Server with Azure Disks

To enable external storage, providers implement the Container Storage Interface (CSI). You may need to install a Container Storage Interface (CSI) driver that you grant permissions to use external storage, using a technique like IAM Roles for Service Accounts. The driver provides Kubernetes Storage Classes that you use to request a persistent volume for data storage.

Use Persistent Volumes

To avoid data loss if a pod or node gets replaced or even if you redeploy the entire cluster, use Persistent Volumes. One option is dynamic provisioning where you declare a PersistentVolumeClaim that references a storage class name and size. The CSI driver for the storage class then automatically creates the PersistentVolume object and binds it to the claim, to mount an external volume into the data source pod.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: idsvr-claim
  labels:
    app: postgres
spec:
  storageClassName: ebs-sc
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Test Local Persistent Volumes

If you are new to Kubernetes data storage, you can rehearse durable deployments on a local computer. To simulate external storage in KIND you can create a cluster and share a folder from the host computer to Kubernetes nodes.

cat << EOF > cluster.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: oauth
nodes:
- role: control-plane
- role: worker
  extraMounts:
  - hostPath: ./externalstorage
    containerPath: /var/local-path-provisioner/host
EOF
kind create cluster --name=example --config=cluster.yaml

A KIND cluster uses the local-path-provisioner storage class and assigns it a name of standard. The Helm chart for the Curity product includes an option to use a PersistentVolume to store configuration data, which you can use for testing. Use static provisioning to create a PersistentVolume with the storage location and use storageClassName=standard.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-configuration
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  volumeMode: Filesystem
  hostPath:
    path: /var/local-path-provisioner/host/idsvr-configuration
    type: DirectoryOrCreate
EOF

Then use the following Helm values.yaml file, so that the Helm chart creates a PersistentVolumeClaim. The claim will bind to the PersistentVolume since its StorageClass matches and the PersistentVolume is available.

replicaCount: 2

image:
  repository: curity.azurecr.io/curity/idsvr
  tag: latest

curity:
  adminUiHttp: true
  admin:
    logging:
      level: INFO

  runtime:
    logging:
      level: INFO
    
  config:
    uiEnabled: true
    persistentConfigVolume:
      enabled: true
      storageClass: standard
      accessModes: ReadWriteOnce
      size: 1Gi

Run the Helm chart with the following options, to use the curity namespace referenced in the pv-configuration PersistentVolume.

helm install curity curity/idsvr --values=values.yaml --namespace curity --create-namespace \
    --set curity.config.password=Password1

Next, query deployed resources:

kubectl get storageclass,pv,pvc

You should see the PersistentVolume and PersistentVolumeClaim bound together:

NAME                                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                 STORAGECLASS
persistentvolume/pv-configuration   1Gi        RWO            Retain           Bound    curity/curity-idsvr   standard

NAMESPACE   NAME                                 STATUS   VOLUME             CAPACITY   ACCESS MODES   STORAGECLASS
curity      persistentvolumeclaim/curity-idsvr   Bound    pv-configuration   1Gi        RWO            standard

View configuration data in the ./externalstorage/idsvr-configuration folder on the host computer. If you delete a pod or even redeploy the whole local cluster, the next deployment continues to use the existing configuration data.

Example Database Deployment

The GitHub link at the top of this page provides some Kubernetes example deployments for a local computer. The Curity Identity Server example includes a basic deployment of a PostgreSQL database with a storage class and persistent volume that store files on the local filesystem. The example deployment also shows how to activate the DevOps Dashboard to administer user accounts and other identity data. Finally, the tutorial shows how to connect to the database and query its data, to get to know the schema.

Summary

The Curity Identity Server can run in Kubernetes and connect to many types of new or existing data sources using standard protocols. Deploy data sources so that data saves to PersistentVolumes. You can provide either basic durability or a more advanced deployment for multiple regions or availability zones.