Deploy using GitOps

Initial Deployment

This section guides you through the initial deployment of IBM Verify Identity Access using the GitOps approach. The process involves creating required secrets, retrieving the Helm chart, customizing configuration values, creating the auto-configuration file, and deploying to your Kubernetes cluster.

To set up deployment:

1. Create the required secrets necessary for the Helm chart, before deployment. Identify the secrets required based on your selected configuration options.
   Secrets required by the Helm chart

   Secret	Required	Default Secret Keys	Description	Used By
   Administrator Password	Always	cfgsvc	Password for administrative access to the configuration service. This is the primary credential used to manage the Verify Identity Access deployment.	Configuration service for admin authentication and management operations
   PKCS12 Keystore Passwords	Only ifcertificates.enabled=true	config_pkcs12_passwordruntime_pkcs12_passwordwrp_pkcs12_password	Passwords are used to protect the PKCS12 keystores generated by cert-manager. Separate passwords must be provided for the configuration, runtime, and WRP components. These passwords must be defined before cert-manager can generate certificates.	cert-manager when creating keystore.p12 files in certificate secrets

   Additional secrets required by ibmvia-autoconf

   The ibmvia-autoconf configuration file can reference additional secrets, depending on your deployment:

   • Runtime admin passwords
   • Activation codes such as WebSEAL and Runtime
   • Database passwords
   • LDAP passwords
   • Any other application-specific credentials

   Note: These secrets are referenced in the ibmvia-autoconf.yaml file using the !secret syntax. These are not directly required by the Helm chart itself.

   Example: Creating the Password Secret

   If you are using cert-manager for creating the password secret, the certificates must be enabled (certificates.enabled=true):

   kubectl create secret generic ivia-passwords \
     --namespace ivia-production \
     --from-literal=cfgsvc=<admin-password> \
     --from-literal=config_pkcs12_password=<config-keystore-password> \
     --from-literal=runtime_pkcs12_password=<runtime-keystore-password> \
     --from-literal=wrp_pkcs12_password=<wrp-keystore-password>

   If you are not using the cert-manager, the certificates must be disabled (certificates.enabled=false):

   kubectl create secret generic ivia-passwords \
     --namespace ivia-production \
     --from-literal=cfgsvc=<admin-password>

   Note: Additional secrets referenced by the ibmvia-autoconf.yaml file should be created separately based on your specific configuration requirements.

2. Retrieve the template values file by pulling the helm chart and extracting the default values file:

   # Pull the chart
   helm pull oci://icr.io/ivia/ivia-autoconf-helm --version <VERSION>
   
   # Extract the chart
   tar -xzf ivia-autoconf-helm-<VERSION>.tgz
   
   # Copy the values file to your GitOps repository
   cp ivia-autoconf-helm/values.yaml my-deployment/values.yaml

   Alternatively, you can also retrieve just the values file:

   helm show values oci://icr.io/ivia/ivia-autoconf-helm --version <VERSION> > values.yaml

3. Configure the values file by editing values.yaml to align with the required environment:

   # Example customizations
   global:
     namespace: "ivia-production"
   
   certificates:
     enabled: true
     issuer:
       create: true
       name: "letsencrypt-prod"
       kind: ClusterIssuer
   
   adminPassword:
     secretName: "ivia-passwords"
     secretKey: "cfgsvc"
   
   wrp:
     replicaCount: 2
     service:
       type: LoadBalancer
     ingress:
       enabled: true
       className: "nginx"
       hosts:
         - host: ivia.example.com
           paths:
             - path: /
               pathType: Prefix
       tls:
         - secretName: ivia-tls
           hosts:
             - ivia.example.com
   
   runtime:
     enabled: true
     replicaCount: 2

4. Create an ibmvia-autoconf.yaml file with your Verify Identity Access configuration:

   version: 1
   
   container:
     activation:
       webseal: !secret ivia-passwords:webseal_activation
       runtime: !secret ivia-passwords:runtime_activation
   
   webseal:
     runtime:
       policy_server: "ldap"
       user_registry: "local"
       clean_ldap: true
       domain: "Default"
       admin_user: "sec_master"
       admin_password: !secret ivia-passwords:runtime_admin
       admin_cert_lifetime: 1460
       ssl_compliance: "fips"
     
     reverse_proxy:
       - name: "default"
         host: "ivia.example.com"
         http:
           enabled: "no"
         https:
           enabled: "yes"
           port: "9443"
         domain: "Default"
   
   runtime:
     database:
       type: "postgresql"
       host: "postgresql.database.svc.cluster.local"
       port: 5432
       name: "isva"
       user: "postgres"
       password: !secret ivia-passwords:postgresql
       ssl:
         enabled: true
         certificate: !secret ivia-postgresql-certificate-secret:ca.crt

5. Deploy the helm chart using your configuration:

   helm install ivia-production oci://icr.io/ivia/ivia-autoconf-helm \
     --namespace ivia-production \
     --version <VERSION> \
     --values values.yaml \
     --set-file autoconf.content=ibmvia-autoconf.yaml

   To verify the deployment, execute the following command:

   # Check Helm release status
   helm status ivia-production -n ivia-production
   
   # Watch pods starting
   kubectl get pods -n ivia-production -w
   
   # Check configuration service logs
   kubectl logs -n ivia-production -l app=ivia-config -f
   
   # Check WRP logs
   kubectl logs -n ivia-production -l app=ivia-wrp -f

Upgrading your deployment

The helm chart is designed to support zero-downtime upgrades. When configuration updates are applied, new pods are created with the updated settings while existing pods continue to serve traffic. Once the new pods are fully configured and healthy, Kubernetes gradually shifts traffic to them and terminate the old pods. This ensures continuous service availability throughout the upgrade process.

Configuration updates

To update your Verify Identity Access deployment, modify the configuration files in Git and deploy again:

1. Update the configuration file:

   # Edit values.yaml or ibmvia-autoconf.yaml
   vim ibmvia-autoconf.yaml

2. Apply the updates:

   helm upgrade ivia-production oci://icr.io/ivia/ivia-autoconf-helm \
     --namespace ivia-production \
     --version <VERSION> \
     --values values.yaml \
     --set-file autoconf.content=ibmvia-autoconf.yaml

Forcing pod restarts

When external dependencies, such as secret values, database passwords, certificates change, you must increment the version number in ibmvia-autoconf.yaml to force a pod restart:

# Before
version: 1

# After updating a secret value
version: 2

Forcing pod restart is necessary for the following reasons:

• ConfigMap Checksum Calculation: The checksum is derived from the contents of the ibmvia-autoconf.yaml file.
• Version Impact: Updating the version number modifies the checksum.
• Change Detection: Kubernetes detects the updated checksum and triggers a pod restart.
• Configuration Update: Newly started pods pick up and apply the updated secret values.

For example, execute the following command:

# 1. Update a secret value
kubectl create secret generic ivia-passwords \
  --namespace ivia-production \
  --from-literal=postgresql=<NEW_PASSWORD> \
  --dry-run=client -o yaml | kubectl apply -f -

# 2. Increment version in ibmvia-autoconf.yaml
sed -i 's/version: 1/version: 2/' ibmvia-autoconf.yaml

# 3. Deploy the update
helm upgrade ivia-production oci://icr.io/ivia/ivia-autoconf-helm \
  --namespace ivia-production \
  --values values.yaml \
  --set-file autoconf.content=ibmvia-autoconf.yaml

Zero-downtime upgrades

The helm chart is designed for zero-downtime upgrades:

1. New Pods Created: Helm deploys new pods with the updated configuration.
2. Configuration Applied: The new pods execute the auto-configuration process during startup.
3. Health Checks Passed: Pods must pass readiness probes before they can receive traffic.
4. Traffic Shifted: Kubernetes gradually shifts traffic to the new pods.
5. Old Pods Terminated: Once the new pods are fully healthy, the old pods are safely terminated.

To monitor the upgrade:

# Watch the rolling update
kubectl rollout status deployment/ivia-wrp -n ivia-production

# View pod transitions
kubectl get pods -n ivia-production -w

# Check events
kubectl get events -n ivia-production --sort-by='.lastTimestamp'