Merge pull request #25 from IBM-Security/v23.03

Updates for v23.03 (icr.io)

.github/workflows/build.yml

@@ -2,13 +2,12 @@
 # Copyright contributors to the IBM Security Verify Access Operator project
 
 # This workflow will be triggered whenever a push occurs (e.g. when a pull 
-# request is merged).  The action will build and publish the verify access 
-# operator.  The docker images will be published to docker hub for release
-# builds, and a private artifactory repository for other builds.  A release
-# build is created whenever a new tag is created.  The name of the tag should
-# be of the format v<year>.<month>.<fix> (with no leading 0's), for example:
-# v21.7.0.  The tag is also used as the tag for the generated docker image, 
-# without the leading 'v'.
+# request is merged).  The action will build and publish the verify access
+# operator.  The docker images will be published to IBM Cloud Container 
+# Registry.  A release build is created whenever a new tag is created.  The 
+# name of the tag should be of the format v<year>.<month>.<fix> (with no 
+# leading 0's), for example: v21.7.0.  The tag is also used as the tag for 
+# the generated docker image, without the leading 'v'.
 
 name: verify-access-operator-publish
 
@@ -81,38 +80,26 @@ jobs:
           mkdir -p ${HOME}/.local/bin
           mv operator-sdk_${OS}_${ARCH} ${HOME}/.local/bin/operator-sdk
 
-      # Perform a docker login to docker hub.
-      - name: Login to Docker Hub
-        if: startsWith(github.ref, 'refs/tags/')
-        uses: docker/login-action@v1
-        with:
-          username: ${{ secrets.DOCKERHUB_USER    }}
-          password: ${{ secrets.DOCKERHUB_API_KEY }}
-
-      # Perform a docker login to artifactory.
-      - name: Login to Artifactory
-        if: (!startsWith(github.ref, 'refs/tags/'))
-        uses: docker/login-action@v1
+      # Perform a docker login to IBM Cloud Container Registry (icr.io)
+      - name: Login to IBM Cloud Container Registry
+        uses: docker/login-action@v2
         with:
-          registry: ${{ secrets.ARTIFACTORY_SERVER  }}
-          username: ${{ secrets.ARTIFACTORY_USER    }}
-          password: ${{ secrets.ARTIFACTORY_API_KEY }}
+          registry: icr.io
+          username: ${{ secrets.ICR_USER    }}
+          password: ${{ secrets.ICR_API_KEY }}
 
       # Perform the build.
       - name: Perform the build.
-        env: 
-          ARTIFACTORY_SERVER: ${{ secrets.ARTIFACTORY_SERVER }}
         run: |
+          export IMAGE_TAG_BASE=icr.io/isva/verify-access-operator
           cd src
 
           case $GITHUB_REF in 
             refs/tags/v*)
-              export IMAGE_TAG_BASE=docker.io/ibmcom/verify-access-operator
               export VERSION=`echo $GITHUB_REF | sed "s|refs/tags/v||g"`
               export DO_PUSH=1
               ;;
             *)
-              export IMAGE_TAG_BASE=docker.io/${ARTIFACTORY_SERVER}/verify-access-operator
               export VERSION=0.0.0
 
               if [ $GITHUB_REF = "refs/heads/master" ] ; then

README.md

@@ -21,13 +21,13 @@
 
 In a world of highly fragmented access management environments, [IBM Security Verify Access](https://www.ibm.com/au-en/products/verify-access) helps you simplify your users' access while more securely adopting web, mobile and cloud technologies. This solution helps you strike a balance between usability and security through the use of risk-based access, single sign-on, integrated access management control, identity federation and its mobile multi-factor authentication capability, IBM Verify. Take back control of your access management with IBM Security Verify Access.
 
-For a detailed description of IBM Security Verify Access refer to the [Offical documentation](https://www.ibm.com/docs/en/sva).
+For a detailed description of IBM Security Verify Access refer to the [Official documentation](https://www.ibm.com/docs/en/sva).
 
 The IBM Security Verify Access operator provides lifecycle management of the lightweight containers which are used to protect an environment, namely:
 
-* [Web Reverse Proxy](https://hub.docker.com/r/ibmcom/verify-access-wrp)
-* [Runtime](https://hub.docker.com/r/ibmcom/verify-access-runtime)
-* [Distributed Session Cache](https://hub.docker.com/r/ibmcom/verify-access-dsc)
+* [Web Reverse Proxy](https://www.ibm.com/docs/en/sva/latest?topic=support-docker-image-verify-access-web-reverse-proxy)
+* [Runtime](https://www.ibm.com/docs/en/sva/latest?topic=support-docker-image-verify-access-runtime)
+* [Distributed Session Cache](https://www.ibm.com/docs/en/sva/latest?topic=support-docker-image-verify-access-distributed-session-cache)
 
 The operator will manage the deployment of these lightweight IBM Security Verify Access worker containers, and also control the rolling restart of these containers when a configuration snapshot is updated, as depicted in the following figure.
 
@@ -39,7 +39,7 @@ Some points to note about the figure:
 * When an administrator publishes a new configuration snapshot using the configuration container, the LMI can automatically send the snapshot to the operator controller.  The publishing of the snapshot can also potentially be a manual step.
 * When a new configuration snapshot is uploaded the operator controller will perform a rolling restart on all deployments which it has created.  
 * The worker containers will pull the configuration snapshot from the operator controller during bootstrapping.
-* The Kubernetes Secret holds authentication information used to control access to the snapshot.  It will be automatically created when the controller is first deployed, and will be populated with random credentials.  
+* The Kubernetes Secret holds authentication information used to control access to the snapshot.  It will be automatically created when the controller is first deployed, and will be populated with random credentials.  
 
 
 
@@ -73,7 +73,7 @@ To install the IBM Security Verify Access operator from OperatorHub.io:
 kubectl get csv -n operators
 
 NAME                              DISPLAY                               VERSION   REPLACES   PHASE
-verify-access-operator.v21.10.0   IBM Security Verify Access Operator   21.10.0              Succeeded
+verify-access-operator.v23.03.0   IBM Security Verify Access Operator   23.03.0              Succeeded
 ``` 
 
 At this point the Operator Lifecycle Manager has been installed into the Kubernetes cluster, the IBM Security Verify Access operator has been deployed and a subscription has been created that will monitor for any updates to the operator on OperatorHub.io. The IBM Security Verify Access operator is now operational and any subsequent custom resources of the kind "IBMSecurityVerifyAccess" will result in the operator being invoked to create the deployment.
@@ -92,7 +92,7 @@ To see a list of available releases refer to the releases page in GitHub: [https
 The following command can be used to deploy the operator directly from the definition published to GitHub:
 
 ```shell
-kubectl create -f https://github.com/IBM-Security/verify-access-operator/releases/download/v21.10.0/bundle.yaml
+kubectl create -f https://github.com/IBM-Security/verify-access-operator/releases/download/v23.03.0/bundle.yaml
 ```
 After executing this command the operator will be deployed to a newly created namespace: `verify-access-operator-system`.  The following command can be used to validate that the operator has been deployed correctly.  The available field should be set to "1". Note that this may take a few minutes.
 
@@ -148,7 +148,7 @@ The following sections describe the various methods which can be used to access
 The GET method can be used to retrieve a specific snapshot.   An example curl command which can be used to retrieve a snapshot is as follows:
 
 ```shell
-curl -k -u $USER:$RO_PWD -O $URL/snapshots/isva_10.0.2.0_published.snapshot
+curl -k -u $USER:$RO_PWD -O $URL/snapshots/isva_10.0.5.0_published.snapshot
 ```
 
 #### POST
@@ -166,25 +166,25 @@ The service names used in the `modified` query string argument is as follows:
 An example curl command which can be used to upload a new snapshot is as follows:
 
 ```shell
-curl -k -u $USER:$RW_PWD -F 'file=@/var/shared/snapshots/isva_10.0.2.0_published.snapshot' $URL/snapshots/isva_10.0.2.0_published.snapshot?modified=wrp:default,runtime
+curl -k -u $USER:$RW_PWD -F 'file=@/var/shared/snapshots/isva_10.0.5.0_published.snapshot' $URL/snapshots/isva_10.0.5.0_published.snapshot?modified=wrp:default,runtime
 ```
 
 #### DELETE
 
 The DELETE method can be used to delete a specific snapshot.  An example curl command which can be used to delete a snapshot is as follows:
 
 ```shell
-curl -k -u $USER:$RW_PWD -X DELETE $URL/snapshots/isva_10.0.2.0_published.snapshot
+curl -k -u $USER:$RW_PWD -X DELETE $URL/snapshots/isva_10.0.5.0_published.snapshot
 ```
 
 ### Partitioning the Cluster
 It is important to be able to partition the environment so that the same Kubernetes cluster can be used for test/development/production/etc.  To this end a snapshot identifier can be specified when deploying a new worker container - this is an optional part of the custom resource definition of the operator.  
 
 The name of the snapshot which is used by the container is then constructed from the snapshot identifier, as: `isva_<version>_<snapshot-id>.snapshot`
-
-The operator will be able to store multiple snapshots, and on a snapshot update will only perform a rolling restart on those deployments which are using the updated snapshot.
+
+The operator will be able to store multiple snapshots, and on a snapshot update will only perform a rolling restart on those deployments which are using the updated snapshot.
 
-The configuration container can also be configured to use a snapshot with a specific ID by setting the `SNAPSHOT_ID` environment variable.
+The configuration container can also be configured to use a snapshot with a specific ID by setting the `SNAPSHOT_ID` environment variable.
 
 
 ### Deploying a Container
@@ -203,7 +203,7 @@ metadata:
 
 spec:
   # The name of the image which will be used in the deployment.
-  image: "ibmcom/verify-access-wrp:10.0.2.0"
+  image: "icr.io/isva/verify-access-wrp:10.0.5.0"
 
   # The number of pods which will be started for the deployment.
   replicas: 1

ReleaseProcess.md

@@ -4,7 +4,7 @@ This document contains the release process which should be followed when generat
 
 ## Version Number
 
-The version number should be of the format: `v<year>.<month>.0`, for example: `v21.10.0`.
+The version number should be of the format: `v<year>.<month>.0`, for example: `v23.03.0`.
 
 
 # Generating a GitHub Release
@@ -15,8 +15,8 @@ The fields for the release should be:
 
 |Field|Description
 |-----|----------- 
-|Tag | The version number, e.g. `v21.10.0`
-|Release title | The version number, e.g. `v21.10.0`
+|Tag | The version number, e.g. `v23.03.0`
+|Release title | The version number, e.g. `v23.03.0`
 |Release description | The resources associated with the \<version\-number> IBM Security Verify Access operator release.
 
 After the release has been created the GitHub actions workflow ([https://github.com/IBM-Security/verify-access-operator/actions/workflows/build.yml](https://github.com/IBM-Security/verify-access-operator/actions/workflows/build.yml)) will be executed to generate the build.  This build process will include:

build/Dockerfile

@@ -21,7 +21,7 @@ VOLUME ["/build"]
 LABEL maintainer="[email protected]" \
     vendor="IBM" \
     product="IBM Security Verify Access" \
-    documentation="https://www.ibm.com/docs/en/sva/10.0.2?topic=web-webseal-overview" \
+    documentation="https://www.ibm.com/docs/en/sva/latest?topic=web-webseal-overview" \
     product_information="https://www.ibm.com/au-en/products/verify-access" \
     copyright="Copyright contributors to the IBM Security Verify Access Operator project"
 

build/operator_build.py

@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python3
 
 """
 Copyright contributors to the IBM Security Verify Access Operator project

src/Makefile

@@ -32,8 +32,8 @@ BUNDLE_METADATA_OPTS ?= $(BUNDLE_CHANNELS) $(BUNDLE_DEFAULT_CHANNEL)
 # This variable is used to construct full image tags for bundle and catalog images.
 #
 # For example, running 'make bundle-build bundle-push catalog-build catalog-push' will build and push both
-# ibmcom/verify-access-operator-bundle:$VERSION and ibmcom/verify-access-operator-catalog:$VERSION.
-IMAGE_TAG_BASE ?= docker.io/ibmcom/verify-access-operator
+# icr.io/isva/verify-access-operator:$VERSION and icr.io/isva/verify-access-operator-catalog:$VERSION.
+IMAGE_TAG_BASE ?= icr.io/isva/verify-access-operator
 
 # BUNDLE_IMG defines the image:tag used for the bundle.
 # You can use it as an arg. (E.g make bundle-build BUNDLE_IMG=<some-registry>/<project-name-bundle>:<tag>)

src/config/manifests/bases/ibm-security-verify-access-operator.clusterserviceversion.yaml

@@ -8,7 +8,7 @@ metadata:
     capabilities: Seamless Upgrades
     categories: Security
     certified: "false"
-    containerImage: docker.io/ibmcom/verify-access-operator:0000.0000.0000
+    containerImage: icr.io/isva/verify-access-operator:0000.0000.0000
     createdAt: --date--
     description: The IBM Security Verify Access Operator manages the lifecycle of IBM Security Verify Access worker containers.
     repository: https://github.com/IBM-Security/verify-access-operator
@@ -28,9 +28,9 @@ spec:
     In a world of highly fragmented access management environments, [IBM Security Verify Access](https://www.ibm.com/au-en/products/verify-access) helps you simplify your users' access while more securely adopting web, mobile and cloud technologies. This solution helps you strike a balance between usability and security through the use of risk-based access, single sign-on, integrated access management control, identity federation and its mobile multi-factor authentication capability, IBM Verify. Take back control of your access management with IBM Security Verify Access.
 
     The IBM Security Verify Access operator provides lifecycle management of the lightweight containers which are used to protect an environment, namely:
-    * [Web Reverse Proxy](https://hub.docker.com/r/ibmcom/verify-access-wrp)
-    * [Runtime](https://hub.docker.com/r/ibmcom/verify-access-runtime)
-    * [Distributed Session Cache](https://hub.docker.com/r/ibmcom/verify-access-dsc)
+    * [Web Reverse Proxy](https://www.ibm.com/docs/en/sva/latest?topic=support-docker-image-verify-access-web-reverse-proxy)
+    * [Runtime](https://www.ibm.com/docs/en/sva/latest?topic=support-docker-image-verify-access-runtime)
+    * [Distributed Session Cache](https://www.ibm.com/docs/en/sva/latest?topic=support-docker-image-verify-access-distributed-session-cache)
 
     The operator will manage the deployment of these lightweight IBM Security Verify Access worker containers, and also control the rolling restart of these containers when a configuration snapshot is updated.
 

src/config/samples/ibm_v1_ibmsecurityverifyaccess.yaml

@@ -9,7 +9,7 @@ metadata:
 
 spec:
   # The name of the image which will be used in the deployment.
-  image: "ibmcom/verify-access-wrp:10.0.2.0"
+  image: "icr.io/isva/verify-access-wrp:10.0.5.0"
 
   # The number of pods which will be started for the deployment.
   # replicas: 1