Kubernetes support

Edit online

Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications.

It provides features such as:

  • Self-healing
  • Horizontal scaling
  • Service discover and load balancing
  • Secret and configuration management

Further information on Kubernetes can be found on the official Kubernetes website: https://kubernetes.io/.

Repository

The Verify Identity Access image is available from the IBM Cloud Container Registry repository: 'icr.io/isva/verify-access', 'icr.io/ivia/ivia-runtime','icr.io/ivia/ivia-wrp', and 'icr.io/ivia/ivia-dsc'.

Secrets

Never store sensitive information like passwords, directly in the yaml deployment descriptors. Instead, store them within a Kubernetes secret and then reference the secret in the yaml deployment descriptors. Instructions on how to use Kubernetes secrets can be found in the official Kubernetes documentation https://kubernetes.io/docs/concepts/configuration/secret/.

In the examples that are provided, a ‘secret’ is used to store the Verify Identity Access administration password. The following example is a command to create the ‘secret’. Ensure that the kubectl context is set to the correct environment before this command is run. 
kubectl create secret generic isva-passwords --type=string --from-literal=cfgsvc=Passw0rd

Service Accounts

Service accounts can be used to provide an identity for processes that run in a Pod. Information on the usage of service accounts can be found in the official Kubernetes documentation: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/.

In the examples that are provided, the deployment descriptors use the ‘isva’ service account. The kubectl utility can be used to create the ‘isva’ service account. Ensure that the kubectl context is set to the correct environment before this command is run. 
kubectl create serviceaccount isva

Readiness, Liveness, and Startup Probes

Kubernetes uses liveness probes to help determine whether a container became unresponsive. If a container does become unresponsive, Kubernetes automatically attempts to restart the container to help rectify the problem.

Kubernetes uses readiness probes to determine whether a container is ready to serve traffic. A pod with containers that report that they are not ready, does not receive traffic through Kubernetes Services.

Kubernetes uses startup probes to deal with applications that might require an extra startup time on their first initialization. The startup probe waits for a container to signal that it fully started before the readiness and liveness probes are commenced.
Note: The startup probe was introduced in Kubernetes v1.16 and is not available before v1.16.

The Verify Identity Access images provide a shell script that can be used to respond to liveness, readiness, and startup probes: /sbin/health_check.sh. If the livenessProbe command line option is provided to the script, it reports on the liveness of the container. If the startupProbe command line option is provided to the script it reports on the startup status of the containerOtherwise, it reports on the readiness of the container. For a liveness probe, the container first checks to see whether it is still starting or reloading. If it is starting or reloading, it returns a healthy result. After the container is ready, both the liveness' and 'readiness probes return the network connectivity state of the service that is hosted by the container.

For more information about liveness, readiness, and startup probes,see the official Kubernetes documentation.

Deployment

The following section illustrates how to deploy Verify Identity Access containers into a Kubernetes environment.

Configuration Container

Instructions on how to create the Verify Identity Access configuration container are provided in the following steps:

  1. Ensure that the kubectl context is set to the correct environment. The mechanism to do this setting differs based on the Kubernetes environment in use.
  2. Create a configuration file that is named config-container.yaml. This configuration file defines a configuration container that can be used to configure your environment. 
    # 
# The deployment description of the Verify Identity Access configuration container.  This
# container is used to manage the configuration of the Verify Identity Access
# environment.
#

apiVersion: v1
kind: Pod

metadata:
  name: ivia-config
  labels:
    app: ivia-config

spec:
  # The name of the service account which has the required
  # capabilities enabled for the ivia container.
  serviceAccountName: isva

  # We use a volume to store the configuration snapshot for the 
  # environment.
  volumes:
  - name: ivia-config
    emptyDir: {}

  containers:
  - name: ivia-config

    # Set the security requirements to a reasonable level.
    securityContext:
      runAsNonRoot: true
      seccompProfile:
        type: RuntimeDefault
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL

    # The fully qualified name of the verify-access image.
    image: icr.io/ivia/ivia-config:11.0.2.0

    # The port on which the container will be listening.
    ports:
    - containerPort: 9443

    # Environment definition.  The administrator password is
    # contained within a Kubernetes secret.
    env:
    - name: ADMIN_PWD
      valueFrom:
        secretKeyRef:
          name: ivia-passwords
          key:  cfgsvc

    # The liveness, readiness and startup probes are used by
    # Kubernetes to monitor the health of the container.  Our 
    # health is governed by the health_check.sh script which is
    # provided by the container.
    livenessProbe:
      exec:
        command:
        - /sbin/health_check.sh 
        - livenessProbe
      initialDelaySeconds: 5
      periodSeconds: 10

    readinessProbe:
      exec:
        command:
        - /sbin/health_check.sh
      initialDelaySeconds: 5
      periodSeconds: 10 

    startupProbe:
      exec:
        command:
        - /sbin/health_check.sh
        - startupProbe
      initialDelaySeconds: 30
      periodSeconds: 10
      failureThreshold: 30 

    # The '/var/shared' directory contains the configuration
    #  snapshots and should be persistent.  We use a volume for
    # this directory.
    volumeMounts:
      - mountPath: /var/shared
        name: ivia-config

---

# 
# The service description of the Verify Identity Access configuration service.  The
# service is only accessible from within the Kubernetes cluster.
#

apiVersion: v1
kind: Service

metadata:
  name: ivia-config

spec:
  ports:
    - port: 9443
      name: ivia-config

  selector:
    app: ivia-config

  type: ClusterIP
  3. Create the container: 
    kubectl create –f config-container.yaml
  4. You can monitor the bootstrapping of the container by using the 'logs' command: 
    kubectl logs -f `kubectl get -o json pods -l app=isva-config | jq -r .items[0].metadata.name`
  5. Start the Kubernetes proxy so that you are able to access the web management console of the configuration container. An alternative approach is to create a Kubernetes service that directly exposes the LMI port of the configuration container. 
    kubectl port-forward `kubectl get -o json pods -l app=isva-config | jq -r .items[0].metadata.name` 9443
  6. Access the proxied web administration console (https:/127.0.0.1:9443) authenticating as the 'admin' user, with a password of 'Passw0rd' (as defined in the ivia-passwords secret). Proceed through the first-steps and then configure your environment.
  7. Using the web administration console, publish the configuration of the environment.

Web Reverse Proxy Container

The following steps illustrate how to create a Web Reverse Proxy container for the 'default' instance:

  1. Ensure that the kubectl context is set to the correct environment. The mechanism to do this setting differs, based on the Kubernetes environment that is being used.
  2. Create a configuration file that is named wrp-container.yaml. This configuration file defines a WebSEAL container that can be used to secure access to your web applications: 
    # 
# The deployment description of the Verify Identity Access Web Reverse Proxy
# container.  
#

apiVersion: apps/v1
kind: Deployment

metadata:
  name: ivia-wrp
  labels:
    app: ivia-wrp

spec:
  selector:
    matchLabels:
      app: ivia-wrp

  replicas: 1

  template: 
    metadata:
      labels:
        app: ivia-wrp

    spec:
      containers:
        - name: ivia-wrp

          # The fully qualified name of the image.
          image: icr.io/ivia/ivia-wrp:11.0.2.0

          # The port on which the container will be listening.
          ports:
            - containerPort: 9443

          # Environment definition for the 'default' Web reverse
          # proxy instance.  The administrator password is contained
          # within a Kubernetes secret.
          env:
            - name: INSTANCE
              value: default            
            - name: CONFIG_SERVICE_URL
              value: https://ivia-config:9443/shared_volume
            - name: CONFIG_SERVICE_USER_NAME
              value: admin
            - name: CONFIG_SERVICE_USER_PWD
              valueFrom:
                secretKeyRef:
                  name: ivia-passwords
                  key:  cfgsvc

          # The liveness, readiness and startup probes are used by
          # Kubernetes to monitor the health of the container.  Our 
          # health is governed by the health_check.sh script which
          # is provided by the container.
          livenessProbe:
            exec:
              command:
              - /sbin/health_check.sh 
              - livenessProbe
            timeoutSeconds: 3

          readinessProbe:
            exec:
              command:
              - /sbin/health_check.sh
            timeoutSeconds: 3

          startupProbe:
            exec:
              command:
              - /sbin/health_check.sh
              - startupProbe
            initialDelaySeconds: 5
            failureThreshold: 30
            timeoutSeconds: 20
  3. Create the container: 
    kubectl create –f wrp-container.yaml
  4. You can monitor the bootstrapping of the container by using the 'logs' command: 
    kubectl logs -f `kubectl get -o json pods -l app=isva-wrp | jq -r .items[0].metadata.name`
  5. Create a configuration file that is named wrp-service.yaml. This configuration file defines a WebSEAL service that can be used to access WebSEAL. The type of service that is defined is different based on whether the 'load balancer' service type is supported in the environment.
    The following definition can be used if the 'load balancer' service type is not supported in your environment: 
    # 
# The service description of the Verify Identity Access Web Reverse Proxy
# service.  This is the entry point into the environment and can be
# accessed over port 30443 from outside of the Kubernetes cluster.
#

apiVersion: v1
kind: Service

metadata:
  name: ivia-wrp

spec:
  ports:
    - port: 9443
      name: ivia-wrp
      protocol: TCP
      nodePort: 30443

  selector:
    app: ivia-wrp

  type: NodePort

    The following definition can be used it the 'load balancer' service type is supported in your environment:

    
# LoadBalancer service definition....
apiVersion: v1
kind: Service
metadata:
  name: isva-wrp
spec:
  type: LoadBalancer
  ports:
    - port: 443
    - targetPort: 9443
  selector:
    app: isva-wrp
  6. Create the service: 
    kubectl create –f wrp-service.yaml
    1. If a 'LoadBalancer' service was defined, determine the external IP address of the service, and then use your browser to access WebSEAL (port 443). 
      kubectl get service isva-wrp --watch
    2. If a 'NodePort' service was defined, determine the IP address of the Kubernetes cluster, and then use your browser to access the Web Reverse Proxy (port 30443). In a 'minikube' environment the IP address of the cluster can be obtained with the following command: 
      minikube ip

      In an IBM cloud environment, the IP address of the cluster can be obtained with the following command:

      bluemix cs workers mycluster --json | jq -r .[0].publicIP

Runtime Container

The Verify Identity Access Runtime Container (called ivia-runtime or Verify Identity Access Liberty Runtime) provides the advanced authentication, context-based access, and federation services. The ivia-runtime container retrieves a snapshot from the configuration container in the same manner as the Web Reverse Proxy Container. Because the Web Reverse Proxy container always acts as a point of contact for the runtime service, no need to listen externally on a NodePort exists. Instead, it exposes only its HTTPS interface on the cluster network with the ivia-runtime service.

The following steps illustrate how to create a runtime container:

  1. Ensure that the kubectl context is set to the correct environment. The mechanism to do this setting differs, based on the Kubernetes environment that is being used.
  2. Create a configuration file that is named runtime-container.yaml. This configuration file defines a runtime container that can be used to secure access to your web applications: 
    # 
# The deployment description of the Verify Identity Access runtime profile container. 
# This container provides the Federation and Advanced Access Control
# capabilities of Verify Identity Access.
#

apiVersion: apps/v1
kind: Deployment

metadata:
  name: ivia-runtime
  labels:
    app: ivia-runtime

spec:
  selector:
    matchLabels:
      app: ivia-runtime

  replicas: 1

  template: 
    metadata:
      labels:
        app: ivia-runtime

    spec:
      containers:
        - name: ivia-runtime

          # The fully qualified name of the verify-access image.
          image: icr.io/ivia/ivia-runtime:11.0.2.0

          # The port on which the container will be listening.
          ports:
            - containerPort: 9443

          # Environment definition.  The administrator password is
          # contained within a Kubernetes secret.
          env:
            - name: CONFIG_SERVICE_URL
              value: https://isva-config:9443/shared_volume
            - name: CONFIG_SERVICE_USER_NAME
              value: admin
            - name: CONFIG_SERVICE_USER_PWD
              valueFrom:
                secretKeyRef:
                  name: isva-passwords
                  key:  cfgsvc

          # The liveness, readiness and startup probes are used by
          # Kubernetes to monitor the health of the container.  Our 
          # health is governed by the health_check.sh script which is
          # provided by the container.
          livenessProbe:
            exec:
              command:
              - /sbin/health_check.sh 
              - livenessProbe
            timeoutSeconds: 3

          readinessProbe:
            exec:
              command:
              - /sbin/health_check.sh
            timeoutSeconds: 3

          startupProbe:
            exec:
              command:
              - /sbin/health_check.sh
              - startupProbe
            initialDelaySeconds: 5
            failureThreshold: 30
            timeoutSeconds: 20

---

# 
# The service description of the isva runtime profile service.  The 
# service is only accessible from within the Kubernetes cluster.
#

apiVersion: v1
kind: Service

metadata:
  name: ivia-runtime

spec:
  ports:
    - port: 443
      targetPort: 9443
      name: ivia-runtime
  selector:
    app: ivia-runtime

  type: ClusterIP
  3. Create the container: 
    kubectl create –f runtime-container.yaml
  4. You can monitor the bootstrapping of the container by using the 'logs' command: 
    kubectl logs -f `kubectl get -o json pods -l app=ivia-runtime | jq -r .items[0].metadata.name`

Distributed Session Cache

The Verify Identity Access Distributed Session Cache Container (called ivia-dsc) can be used by the Web Reverse Proxy and Runtime to share sessions between multiple containers. The ivia-dsc container also retrieves a snapshot from the configuration container in the same manner as the Web Reverse Proxy Container. Besides the technical function of the container, the difference is that this container has no need to listen externally on a NodePort. Instead, it exposes only its HTTPS and replication interfaces on the cluster network with the ivia-dsc service.

The following steps illustrate how to create a DSC container:
  1. Ensure that the kubectl context is set to the correct environment. The mechanism to do this setting differs, based on the Kubernetes environment that is being used.
  2. Create a configuration file that is named dsc-container.yaml. This configuration file defines a DSC container that can be used to share sessions: 
    # 
# The deployment description of the Verify Identity Access distributed session 
# cache container.  
#

apiVersion: apps/v1
kind: Deployment

metadata:
  name: ivia-dsc
  labels:
    app: ivia-dsc

spec:
  selector:
    matchLabels:
      app: ivia-dsc

  template:
    metadata:
      labels:
        app: ivia-dsc

    spec:
      containers:
        - name: ivia-dsc

          # The fully qualified name of the verify-access image.
          image: icr.io/ivia/ivia-dsc:11.0.2.0

          # The ports on which the container will be listening.  Port
          # 443 provides the main DSC service, and port 444 provides
          # the replication service which is used when replicating 
          # session data between DSC instances.
          ports:
            - containerPort: 443
            - containerPort: 444

          # Environment definition.  The administrator password is
          # contained within a Kubernetes secret.
          env:
            - name: INSTANCE
              value: '1'
            - name: CONFIG_SERVICE_URL
              value: https://ivia-config:9443/shared_volume
            - name: CONFIG_SERVICE_USER_NAME
              value: admin
            - name: CONFIG_SERVICE_USER_PWD
              valueFrom:
                secretKeyRef:
                  name: ivia-passwords
                  key: cfgsvc

          # The liveness, readiness and startup probes are used by
          # Kubernetes to monitor the health of the container.  Our 
          # health is governed by the health_check.sh script which is
          # provided by the container.
          livenessProbe:
            exec:
              command:
              - /sbin/health_check.sh 
              - livenessProbe
            timeoutSeconds: 3

          readinessProbe:
            exec:
              command:
              - /sbin/health_check.sh
            timeoutSeconds: 3

          startupProbe:
            exec:
              command:
              - /sbin/health_check.sh
              - startupProbe
            initialDelaySeconds: 5
            failureThreshold: 30
            timeoutSeconds: 20

---

# 
# The service description of the verify-access distributed session
# cache service.  The service is only accessible from within the
# Kubernetes cluster.
#

apiVersion: v1
kind: Service

metadata:
  name: ivia-dsc

spec:
  ports:
    - port: 443
      name: ivia-dsc
    - port: 444
      name: ivia-dsc-replica
  selector:
    app: ivia-dsc

  type: ClusterIP
  3. Create the container: 
    kubectl create –f dsc-container.yaml
  4. The 'dscadmin' command can be used to directly administer the distributed session cache: 
    kubectl exec -it `kubectl get -o json pods -l app=ivia-dsc | jq -r .items[0].metadata.name` dscadmin
  5. You can monitor the bootstrapping of the container by using the 'logs' command: 
    kubectl logs -f `kubectl get -o json pods -l app=isva-dsc | jq -r .items[0].metadata.name`

Kubernetes Environments

The following Kubernetes environments are validated by using the Verify Identity Access image:

Minikube

Minikube is a tool that runs Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day. For more information, see the Minikube website. https://kubernetes.io/docs/getting-started-guides/minikube/

To set the context for the kubectl utility, use the following command.

kubectl config use-context minikube
IBM Cloud

The IBM cloud container service provides advanced capabilities for building cloud-native apps, adding DevOps to existing apps, and relieving the pain around security, scale, and infrastructure management. Further information can be obtained from the IBM Cloud website: https://www.ibm.com/cloud/container-service

To set the context for the kubectl utility, use the IBM Cloud CLI to obtain the kubectl configuration file.

bx cs cluster-config <cluster-name>
Microsoft Azure Container Registry

Azure Container Service (AKS) manages your hosted Kubernetes environment, making it quick and easy to deploy and manage containerized applications without container orchestration expertise. It also eliminates the burden of ongoing operations and maintenance by provisioning, upgrading, and scaling resources on demand, without taking your applications offline. Further information can be obtained from the Microsoft Azure AKS website: https://docs.microsoft.com/en-us/azure/aks/

To set the context for the kubectl utility, use the Microsoft Azure CLI:

az aks get-credentials --resource-group <group-name> --name <cluster-name>
Google Cloud Platform

Google Cloud Platform lets you build and host applications and websites, store data, and analyze data on Google's scalable infrastructure. Further information can be obtained from the Google Cloud website: https://cloud.google.com/kubernetes-engine/

To set the context for the kubectl utility, use the Google Cloud CLI:

gcloud container clusters get-credentials <cluster-name>
Red Hat OpenShift
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment. For more information, see https://www.openshift.com/.
To set the context for the kubectl utility, use the Red Hat OpenShift CLI. 
oc login

The oc binary is the preferred mechanism for accessing the OpenShift CLI and can be used interchangeably with the kubectl utility.