Using the IVIA autoconf module to update a configuration

You have a configuration you need to make some updates to... 
you need to renew certificates ...
an external service integration changed ...
you need a new junction, authentication policy ...
and you do not want to set up your IAM deployment from scratch ... again ...

The IBM Verify Identity Access (IVIA) autoconf module can be used to automate configuration using API requests to the management interface. 

This can be useful for administrators trying to run updates to a deployment in a fast and consistent way; or it can be used to automate entire deployment configurations (disaster recovery, migrations, dev-ops workflows)

This article will document how the autoconf module can be used to update an existing snapshot; permitting an admin to verify/modify changes, before generating a new snapshot to publish to runtime containers.

I will also cover simple ways the autoconf module can be integrated with existing devops tools, such as Ansible; and strategies for automating updates as part of dev-ops tool workflows.

The ibmvia autoconf module is also capable of managing appliance deployments as well, where configuration is simply deployed without having to be published/rolled-out to the runtime containers.

What this article covers

This blog post aims to document a simple process for applying an incremental change to an ivia-config container deployment.

It should help administrators who manage IVIA deployments apply updates quickly and repeatably.

This is often required in response to: external integration changes; certificates and/or API keys for external services expiring.

Being able to apply these updates using automation can be a very useful tool in a devops management workflow.

What this demo does:

• Start a ivia-config container with an existing snapshot
  • you can also choose to start from an unconfigured state
• Apply an incremental change using the ibmvia-autoconf module
• [Optional] Publish the updated snapshot to a snapshot manager (verify-access-operator)
• [Advanced] Automating the process end-to-end

If you do not have an IVIA deployment and just want to try the module out; you can follow the upload path and ignore steps which require/use a previous configuration state.

There are additional hints for activating the ivia-config container with a trial license throughout the article.

When the module has completed, an administrator can connect to the management interface to verify the changes are correct, before rolling out the updated configuration to the runtime containers.

In a stable workflow, the rollout of snapshots to the downstream runtime containers can also be automated using the verify-identity-access-operator.

To get started

This demo will use the ivia-config container to run the autoconf module. So all you need is a connection to a Kubernetes Cluster!

• Verify you can talk to a kubernetes cluster with kubectl.
• Locate the snapshot you need to update + the info you need to update it with: X509 certificates; new API keys; etc.
  • see above if you do not have a snapshot

You can also try and install the autoconf module in any python runtime:

# Install the kubernetes optional extra for secret management
pip install ibmvia_autoconf[kubernetes]
# Install the hashicorp vault optional extra for secret management
pip install ibmvia_autoconf[vault]

This module has already been installed on the configuration container, so you can use the same pod to update your configuration snapshot and publish it to your snapshot manager.

However it is usually a good idea to attempt to fetch the latest version of the tool (or air-gap install the .whl from the python package index PyPI).

For this example we are updating an expired X509 certificate used to verify connections to the Db2 High-Volume Database (HVDB), so the only thing we need is the new certificate!

You can extend the minimal provided config with any of the options defined in the ibmvia-autoconf docs.

Kubernetes Deployment: ivia-config container

To get started you will need to define how/where your config container will run.

For this demo I will be using a deployment where the management interface is only accessible from within the cluster; and I will only be running the configuration container for as long as it takes to apply my updates and upload a new snapshot to my management service (PVC or Operator).

I will also be building on a previous snapshot/state. Therefore I will need to define the snapshot I am starting with the snapshot I will end up with (you don't want to over-write your existing config!); as well as a method to apply the snapshot, either during pod bootstrap, or once the management interface has started.

Note: If you do not have an existing snapshot you can just omit the steps used to fetch and apply the snapshot

If you are starting from unconfigured you should use the PVC example to setup the ivia-config container, and skip the steps that require a previous snapshot

Choose a method to apply your snapshot

You will need to decide how you are going to apply your previous configuration state (snapshot). 

There are two ways this can be done: by mounting the snapshot when the container first starts (bootstraps); or uploading a snapshot via the management interface.

Bootstrapping from a snapshot is a more simple dev-ops process, but it can be tricky to mount the snapshot correctly before the container starts. 

And it can also be tricky to change the name of the snapshot; so you accidentally end up overwriting a snapshot in your manager with an untested change set.

Uploading the snapshot via API requests requires the appliance to **already be** at the same module activation level as the snapshot being applied ... which can be confusing.

Choose the correct approach for your env; or define your entire deployment in YAML and start from scratch every time!

Bootstrap from a snapshot

We will use an initContainer in a Kubernetes Deployment spec to fetch the snapshot and set up the shared directory for the configuration container.

We will then use the verify-identity-access-operator to publish the snapshot to the runtime containers once the autoconf module has run.

First we will need a Kubernetes Secret with the snapshot properties + snapshot management service properties:

kubectl create secret generic ivia-snapshot-secret \
    --from-literal=source_id=published \
    --from-literal=sink_id=updated-26-07-29

kubectl create secret generic verify-access-operator \
    --from-literal=user=apikey \
    --from-literal=rw.pwd=PaeQyol7gHTNoSl4cnpYe5iMK2QODyF7y48Y \
    --from-literal=url=https://verify-access-operator-controller-manager-snapshot-service.verify-access-operator-system.svc.cluster.local:7443 \
    --from-file=/tmp/tls.cert

Note: you can get the connection properties for the operator from the verify-access-operator secret from the namespace that the operator is installed in; eg openshift-operators

Now we are going to define how we will apply a previous state (snapshot) and update the configuration we require.

At a minimum; you will need to define the Kubernetes Deployment for the ivia-config container, and the source of your new/required files.

This might be a ConfigMap with just the X509 certificate; or you might need a PersistentVolumeClaim with the snapshot + license files, etc.

Use the following for autoconf YAML sample (config.yaml):

mgmt_base_url: !secret default/ivia-secrets:mgmt-url
mgmt_user: !secret default/ivia-secrets:mgmt-user
mgmt_pwd: !secret default/ivia-secrets:mgmt-pwd
container:
  ssl_certificates:
  - name: "lmi_trust_store"
    signer_certificates:
    - file: !cfgmapfile default/ivia-autoconf-vol:db2-ssl.pem
      label: db2-ssl-pem
      replace: true
  - name: "rt_profile_keys"
    signer_certificates:
    - file: !cfgmapfile default/ivia-autoconf-vol:db2-ssl.pem
      label: db2-ssl-pem
      replace: true

You can download this config file from Github.

The ivia-config deployment we created requires us to have the following Secret defined and ConfigMap:

# Update with your administrator account as appropriate
kubectl create secret generic ivia-secrets \
    --from-literal=mgmt-url=https://localhost:9443 \
    --from-literal=mgmt-user=admin \
    --from-literal=mgmt-pwd=AdminPassw0rd \
    --from-literal=source_id=published \
    --from-literal=sink_id=updated-26-07-29
# X509 is the cert you are updating; config.yaml is the above YAML code fragment
kubectl create configmap ivia-autoconf-vol --from-file=db2-ssl.pem --from-file=config.yaml

The following spec.template.spec.initContainers[0] definition retrieves a source snapshot from the operator installed in the cluster. 

When the autoconf module is done applying the configuration you defined; the config container will upload the new snapshot to the operator with the id we provided as the sink.

You will have to modify the Kubernetes Deployment you previously defined with the following fetch-snapshot container in the initContainers list:

      initContainers:
      - name: fetch-snapshot
        . . .
        command:
        - "bash"
        - "-c"
        - >-
          mkdir -p /var/shared/snapshots; 
          curl -v --cacert /tmp/verify-access-operator.crt 
               -o "/var/shared/snapshots/ivia_11.0.3.0_${SINK_SNAPSHOT_ID}.snapshot"
               -u "${OPERATOR_USER}:${OPERATOR_PWD}" 
               "${OPERATOR_URL}/snapshots/ivia_11.0.3.0_${SOURCE_SNAPSHOT_ID}.snapshot"

You can find a complete example Deployment yaml here.

This init container simply fetches the snapshot from the operator and rename it to new name; preserving the starting configuration state (if you need to make additional changes or roll back).

After this has been defined in your ivia-config.yaml you can create the Kubernetes Deployment and wait for the initContainer to complete and the ivia-config container to start the management interface:

kubectl create -f ivia-config.yaml

Once the management interface is running you can proceed to running the autoconf module!

Upload a snapshot to the LMI

Applying a previous snapshot to a config container is a little more tricky once it has bootstrapped ... you need to get the config container into the same "activation" as the snapshot (you cannot apply a snapshot with the base/aac/fed licenses applied if you have not activated these modules).

The additional trick/trap for this demo is the Advanced Access Control and Federation licensed modules require the HVDB service to be defined before the modules can be activated.

Therefore, at a minimum you will need to provide module licenses for the required IVIA features (in this case from Kubernetes secrets); the database connection details; and some information to connect with the management (ivia-config) container.

Note: This is the same configuration you should define if you are starting from an unconfigured state, just remove the snapshot property

mgmt_base_url: !secret default/ivia-secrets:mgmt-url
mgmt_user: !secret default/ivia-secrets:mgmt-user
mgmt_pwd: !secret default/ivia-secrets:mgmt-pwd
container:
  activation: #Add as required; or use the trial option
    webseal: !secret default/ivia-secrets:base-module
    federation: !secret default/ivia-secrets:fed-module
  ssl_certificates:
  - name: "lmi_trust_store"
    signer_certificates:
    - file: db2-ssl.pem
      label: db2-ssl-pem
      replace: true
  - name: "rt_profile_keys"
    signer_certificates:
    - file: db2-ssl.pem
      label: db2-ssl-pem
      replace: true
  cluster:
    runtime_database:
      host: "ivia-db2"
      port: 50001
      type: "db2"
      user: "ivia-dba"
      password: !secret default/ivia-secrets:db2-passwd
      ssl: True
      db_name: "ivia-hvdb"
  snapshot: ivia_11.0.3.0_published.snapshot

The SNAPSHOT_ID being applied is called published; which is the default name if you do not set the SNAPSHOT_ID property.

This can be changed after the snapshot is generated by your snapshot manager: the file must have the naming convention ivia_<release version>_<snapshot id>.snapshot, eg ivia_11.0.3.0_published.snapshot.

The above configuration assumes you have the following Secret defined:

# Update with your administrator account as appropriate
kubectl create secret generic ivia-secrets \
    --from-literal=mgmt-url=https://localhost:9443 \
    --from-literal=mgmt-user=admin \
    --from-literal=mgmt-pwd=AdminPassw0rd \
    --from-literal=base-module=ACTIVATION_CODE \
    --from-literal=fed-module=ACTIVATION_CODE \
    --from-literal=db2-passwd=DbAPassw0rd

Now we can define the ivia-config.yaml Deployment.

We will need to create a PersistentVolumeClaim which is large enough to hold your current configuration snapshot (probably < 100MB) and the X509 certificate we are updating.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ivia-autoconf-vol
spec:
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 100Mi } }

You can find an example ivia-config Deployment using a persistent volume here. 

Note: The minimum size for a snapshot is ~10Mb, which is typically larger than the file size limit of a ConfigMap object, which is why a PVC is used.

Create the deployment and wait for the cluster to provision the PVC and start the management interface of the ivia-config container. 

You can connect to the management interface with thekubectl port-forward Kubernetes utility; or Kubernetes Ingress, if supported by your cluster.

kubectl create -f ivia-config.yaml

And then copy the snapshot and X509 cert to the mount point in the running ivia-config container.

# This uses a sub-shell to dynamically fetch the generated name for the pod; which is typically something like iviaconfig-abcd1234ABCD
IVIA_CONFIG_POD=$(kubectl get pod -l app=iviaconfig -o jsonpath='{.items[0].metadata.name}')
kubectl cp ivia_11.0.3.0_published.snapshot $IVIA_CONFIG_POD:/autoconf/ivia_11.0.3.0_published.snapshot
kubectl cp db2-ssl.pem $IVIA_CONFIG_POD:/autoconf/db2-ssl.pem

Once these files have been copied across to the ivia-config container and the management interface is responding; you can start running the autoconf module!

Note: If you are not using the IVIA operator or snapshot management service; you will need to "save" the snapshot once the module has run. You can copy it to the PVC or your local machine, etc.

Managing an appliance deployment

To use the autoconf module with an appliance (Virtual Machine) based deployment; change the top level container property to appliance.

This example also uses the trial license activation option instead of module activation keys; and environment variables instead of Kubernetes secrets

mgmt_base_url: !environment MGMT_URL
mgmt_user: !environment MGMT_USER
mgmt_pwd: !environment MTMT_PWD
appliance:
  activation: # use the trial option
    trial_license: "/home/User/Downloads/ISAM-Trial-IBM.cer"
  ssl_certificates:
  - name: "lmi_trust_store"
    signer_certificates:
    - file: "/home/User/Downloads/db2-ssl.pem"
      label: db2-ssl-pem
      replace: true
  - name: "rt_profile_keys"
    signer_certificates:
    - file: "/home/User/Downloads/db2-ssl.pem"
      label: db2-ssl-pem
      replace: true
  cluster:
    runtime_database:
      host: "ivia-db2"
      port: 50001
      type: "db2"
      user: "ivia-dba"
      password: !environment DB2_PWD
      ssl: True
      db_name: "ivia-hvdb"

Run the autoconf module

**Make sure your service account has permission to read secrets**

The default service account typically has permission to read secrets in its own namespace. Container runtimes like OpenShift may enforce a more restrictive RBAC.

The autoconf module is able to retrieve secrets from its own cluster. This makes it simple to version control configuration without committing (and exposing) secrets!

You can use kubectl exec to get a shell running on the ivia-config container; from here, we will be able to run the autoconf module with the files we have already mounted!

Note: you can also use this shell to verify that your configuration files are present and readable

kubectl exec -it $(kubectl get pod -l app=iviaconfig -o jsonpath='{.items[0].metadata.name}') -- sh
# Now running on the ivia-config pod
export IVIA_CONFIG_YAML=/autoconf/config.yaml
python -m ibmvia_autoconf

If you encounter problems or need more details on what the module actually did; you can increase the verbosity of the logging.

**This will log sensitive information from your deployment**

export IVIA_CONFIGURATOR_LOG_LEVEL=DEBUG

When the module has run, it will generate a summary of any errors it encountered applying the configuration:

2026-07-24 05:56:35,062 - INFO - Reading configuration file
2026-07-24 05:56:35,062 - INFO - Trying to read file from env var IVIA_CONFIG_YAML [/ivia_config/mmfa_config.yaml]
  . . .
2026-07-24 05:56:35,566 - INFO - LMI returning login page
2026-07-24 05:56:35,568 - INFO - LMI responding, begin configuration
  . . .
2026-07-24 06:16:29,116 - INFO - Idle for 15s to allow orchestration to recover and Verify Identity Access components to initialize.

✓ No API failures recorded during execution.

[ADVANCED] When to publish snapshots

If you attempt to use this module for more complicated configuration updates you have probably experienced the problem of having to deploy/publish a configuration before a subsequent step can be performed.

Examples of this include: setting up a Federated Identity source with the runtime; connecting a service before the X509 certificate has been imported to the SSL database; even activating the Federation or AAC modules requires the HVDB to be configured.

The autoconf module attempts to address this problem by running configuration steps in a sequence which respects these configuration dependencies, however this makes the module run much more slowly (the publish step takes quite a long time to stabilize the runtime containers).

If you want to attempt to optimize your devops process, it is possible to refine your configuration yaml to avoid these publication steps, but it does make management more difficult.

The incremental_snapshot property is used to control when snapshots are published.

However this requires that all of the certificate management is manual (eg: you cannot import the self-signed certificate generated for the runtime container).

It also means that you are unable to use some of the reverse proxy configuration helpers to automatically set up federations ... which can be done manually, but is complicated.

Administrators can implement their own dev-ops process; and incrementally build on a configuration with a pipeline of changes that get stacked upon the previous stage.

The base layer defines the PKI + system settings; then a development/test configuration is applied and verified (with application specific integration testing); finally a production snapshot is pushed out to runtime containers which can be connected to external traffic.

Verify the configuration was applied

If you made it to this point hopefully your snapshot manager now has a new snapshot listed; and this new snapshot contains the updated X509 certificate for the HVDB service.

You can now push out the updated snapshot to an isolated environment for further testing; before publishing it to production containers.

You can also create a new deployment in a isolated environment to sandbox testing. 

For this example; verify that the runtime container is able to contact/verify the connection to the HVDB from the pod's logs.

Automate the process

Once you have verified that the change produced by the autoconf module, tools such as Ansible can be: used to repeat the process on a schedule (update a certificate every 90 days); or it can be scaled to run the same update on multiple hosts/deployments.

As previously mentioned, the ibm-verify-identity-access-operator provides the ability to automate the rollout of snapshot to runtime containers. This is used the bootstrap example to automatically publish a new snapshot to the operator with a different name.

This allows for simple management of snapshots and the rollout of updates. This article documents the two ways snapshots are typically managed: by service like the operator (or snapshot-manager); or manually in a (persistent) volume.

Using services to automate the rollout of updates is very efficient; but it does reduce the opportunity for admins to verify that updates are valid before pushing them to runtime containers.

Every IVIA deployment is different so it is up to you to find the best balance between efficiency and reliability.