Hi, we will work on updating the instructions. There are a few major glaring issues when deploying without prior knowledge. The config container is not to be managed by the operator, use a normal config container yaml, The Secrets will need to be copied from the operator in the operators namespace to the namespace you have deployed ISVA (most likely default). There are 4 secrets needed. ro_pwd, rw_pwd, url, user. These will need defined in the config yaml like below under Containers. If not your config container will never be able to publish to the operator/manager. Once you put all this together, its pretty awesome.
In this example I have renamed to snap-op-{secret} (probably not the best naming convention)
- name: CONFIG_SERVICE_URL
valueFrom:
secretKeyRef:
key: url
name: snap-op-url
optional: false
- name: CONFIG_SERVICE_USER_NAME
valueFrom:
secretKeyRef:
key: user
name: snap-op-usr
optional: false
- name: CONFIG_SERVICE_USER_PWD
valueFrom:
secretKeyRef:
key: rw.pwd
name: snap-op-rw-pwd
optional: false
The DSC and RT container yaml will be similar to the WRP yaml. I will provide a sample of both. You will also run into the default DSC naming issue in the yaml. I will define this in the sample yaml also. Please update/edit as suited. Also note the reverse proxy name is defined for the WRP container. Mine happens to be rp1.
#RUNTIME
apiVersion: ibm.com/v1
kind: IBMSecurityVerifyAccess
metadata:
name: isvaruntime
spec:
image: "icr.io/isva/verify-access-runtime:10.0.5.0"
replicas: 1
autoRestart: true
snapshotId: published
language: "en_US.utf8"
container:
env:
- name: TEST_ENV
value: TEST_ENV_VALUE
# DSC
apiVersion: ibm.com/v1
kind: IBMSecurityVerifyAccess
metadata:
name: isvadsc
spec:
image: "icr.io/isva/verify-access-dsc:10.0.5.0"
replicas: 1
autoRestart: true
snapshotId: published
# this is the instance of DSC legacy default = "1"
instance: "1"
language: "en_US.utf8"
container:
env:
- name: TEST_ENV
value: TEST_ENV_VALUE
# WRP
apiVersion: ibm.com/v1
kind: IBMSecurityVerifyAccess
metadata:
name: isvawrprp1
spec:
image: "icr.io/isva/verify-access-wrp:10.0.5.0"
replicas: 2
autoRestart: true
snapshotId: published
instance: rp1
language: "en_US.utf8"
env:
- name: TEST_ENV
value: TEST_ENV_VALUE
Hopefully this helps! I learned this all during a build :)
------------------------------
Robert Graham
Cloud Security Consultant
IAM Modernization
IBM Expert Labs
US
------------------------------
Original Message:
Sent: Mon April 10, 2023 08:52 PM
From: Chandan Reddy Bokka
Subject: Verify Access lightweight Operator
Hello,
I'm tring to get a head start on the verify access operator to experiment on a kubernetes clusture and intrested in working with the light weight container from 10.0.4.0. I've been trying to follow the instructions on the git hub page mentioned below:
There is a file to create the isva-wrp.yaml worker container, however, i'm can't find config sample files for other worker container i.e., dsc and runtime. I'm also not able to find a file to configuration container.
can any one provide pointers on how to get started with all these to tie them up so that i get the full picture. I understand that there are links from these page to the documentation, but sample config file for staters would be very helpful.
GitHub - IBM-Security/verify-access-operator
| GitHub | remove preview |
 | | GitHub - IBM-Security/verify-access-operator | | In a world of highly fragmented access management environments, IBM Security 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. | | View this on GitHub > |
|
|
------------------------------
Chandan Reddy Bokka
------------------------------