How To
Summary
In environments that are air-gapped, installing IBM Cloud Pak® for Security might require that the installation media be on a portable storage device. The official documentation is mostly correct but not always clear; in this document there are some additional notes.
Objective
- Create a SAN certificate that is trusted
- Create a docker (Podman) registry
- Set environment variables and download CASE files
- Mirror the Red Hat OpenShift Container Platform images to flat files
- Prune the Red Hat Operator Catalog
- Mirror the Red Hat Operator Catalog subset to flat files
- Mirror the CP4S images to flat files
- Mirror images from the mirroring device in the air gapped environment
- Install CP4S in an air gapped environment
- Upgrade CP4S in an air gapped environment
- Uninstall CP4S in an air gapped environment
Environment
This document is verified on a vSphere environment.
Steps
- Company policies allow the use of removable storage device that is scanned and verified by the customers IT organization.
- Company policies allow a connection to a removable storage device from a laptop.
One of the prerequisites of an air-gapped deployment is a trusted SAN certificate.
Sample openssl.cnf file
Here is the example openssl configuration file, which is used in this entire article. Do not use the complete /etc/pki/tls/openssl.cnf. Instead you need to create your own custom SSL configuration file with required parameters only.
[ ca ]
default_ca = CA_default # The default ca section
[ CA_default ]
dir = /root/tls # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/certs # default place for new certs.
certificate = $dir/certs/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem # The private key
x509_extensions = v3_ca # The extensions to add to the cert
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
# crlnumber must also be commented out to leave a V1 CRL.
crl_extensions = crl_ext
default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = sha256 # use SHA-256 by default
preserve = no # keep passed DN ordering
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = optional
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 2048
default_md = sha256
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extensions to add to the self signed cert
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = IN
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Karnataka
localityName = Locality Name (eg, city)
localityName_default = Bengaluru
0.organizationName = Organization Name (eg, company)
0.organizationName_default = GoLinuxCloud
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = Admin
commonName = Common Name (eg, your name or your server\'s hostname)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = critical,CA:true
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
authorityKeyIdentifier=keyid:always
Generate RootCA certificate
## create a directory structure for storing the rootca certificates
mkdir -p /root/tls/{private,certs}
## navigate inside your tls path
cd /root/tls
## generate rootca private key
openssl genrsa -out private/cakey.pem 4096
## generate rootCA certificate
openssl req -new -x509 -days 3650 -config openssl.cnf -key private/cakey.pem -out certs/cacert.pem
## Verify the rootCA certificate content and X.509 extensions
openssl x509 -noout -text -in certs/cacert.pem
Generate CSR for SAN Certificate
To generate CSR for SAN, you need distinguished_name and req_extensions.
The values for individual distinguished_name parameters in this configuration file are added to avoid user prompt.
# cat server_cert.cnf
[req]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[req_distinguished_name]
C = IN
ST = Karnataka
L = Bengaluru
O = ExampleCo
OU = R&D
CN = ban21.example.com
[req_ext]
subjectAltName = @alt_names
[alt_names]
IP.1 = 10.10.10.13
IP.2 = 10.10.10.14
IP.3 = 10.10.10.17
DNS.1 = centos8-2.example.com
DNS.2 = centos8-3.example.com
Create a server key.
openssl genrsa -out server.key
Next, you need to use openssl to generate our Certificate Signing Request for SAN certificate.
openssl req -new -key server.key -out server.csr -config server_cert.cnf
Since you used prompt=no and also provided the CSR information, there is no output for this command, but the CSR is generated. Do not use prompt=yes; it does not work.
Optional: Verify Subject Alternative Name value in CSR
Next, verify the content of your Certificate Signing Request (CSR) to make sure it contains Subject Alternative Name section under "Requested Extensions".
# openssl req -noout -text -in server.csr | grep -A 1 "Subject Alternative Name"
X509v3 Subject Alternative Name:
IP Address:10.10.10.13, IP Address:10.10.10.14, IP Address:10.10.10.17, DNS:centos8-2.example.com, DNS:centos8-3.example.com
The CSR contains all the provided IP address and DNS values.
Optional: Try to generate SAN certificate
Next, use this CSR to try to generate the SAN certificate:
# openssl x509 -req -days 365 -in server.csr -CA /root/tls/certs/cacert.pem -CAkey /root/tls/private/cakey.pem -CAcreateserial -out server.crt
Signature ok
subject=C = IN, ST = Karnataka, L = Bengaluru, O = ExampleCo, OU = R&D, CN = ban21.example.com
Getting CA Private Key
Missing SAN Extensions in the certificate
Once the certificate is generated, verify whether the SAN fields are retained inside the certificate:
# openssl x509 -text -noout -in server.crt | grep -A 1 "Subject Alternative Name"
You get an empty output. The SAN Extensions are missing from the certificate.
It is expected behavior according to the official documentation from openssl.
Extensions in certificates are not transferred to certificate requests and vice versa. That means that the extensions, which you added in the CSR, were not transferred by default to the certificate. These extensions must be added to the certificate explicitly with X509 extensions.
Generate SAN Certificates with X509 extensions
You need to use the -extensions argument with the name of the extension to be used from the configuration file. You defined your SAN fields under req_ext extension so you need to use the same extensions and regenerate the certificate:
# openssl x509 -req -days 365 -in server.csr -CA /root/tls/certs/cacert.pem -CAkey /root/tls/private/cakey.pem -CAcreateserial -out server.crt -extensions req_ext -extfile server_cert.cnf
Signature ok
subject=C = IN, ST = Karnataka, L = Bengaluru, O = ExampleCo, OU = R&D, CN = ban21.example.com
Getting CA Private Key
Optional: Reverify the SAN Extensions in the certificate
Now, reverify the SAN extension in the certificate:
# openssl x509 -text -noout -in server.crt | grep -A 1 "Subject Alternative Name"
X509v3 Subject Alternative Name:
IP Address:10.10.10.13, IP Address:10.10.10.14, IP Address:10.10.10.17, DNS:centos8-2.example.com, DNS:centos8-3.example.com
So this time the certificates are properly generated with the SAN fields.
See also https://www.golinuxcloud.com/openssl-subject-alternative-name/
After you have the SAN certificate, you can copy it to /var/lib/registry/certs
Trusting the self-signed CA certificate
To enable system-wide trust for the private Docker registry, create the symlink:
ln -s /root/tls/certs/cacert.pem /etc/pki/ca-trust/source/anchors/
update-ca-trust
curl -v https://localhost:5000
2. Create a docker (Podman) registry
docker run --privileged -d \
--restart=always \
--name registry \
-v /var/lib/registry/certs:/certs:Z \
-v /var/lib/registry:/var/lib/registry:Z \
-e REGISTRY_HTTP_ADDR=0.0.0.0:5000 \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/var/lib/registry/certs/server.crt \
-e REGISTRY_HTTP_TLS_KEY=/var/lib/registry/certs/server.key \
-p 5000:5000 \
registry:2
docker ps
docker logs <CONTAINER-ID>
podman login <registry>
Alternatively see https://www.redhat.com/sysadmin/simple-container-registry
Before mirroring your images, set the environment variables on your mirroring device, and connect to the internet so that you can download the corresponding CASE files.
About this task
Tip: Save a copy of your environment variable values to a file by using a text editor. You can use that file as a reference to copy and paste from while you complete your air-gapped environment installation tasks.
Procedure
- Disconnect your mirroring device from your local air-gapped network.
- Become root.
- Mount the removable storage device on your mirroring device.
- Set the $IBMPAK_HOME environment variable to the mount point of your removable storage device.
export IBMPAK_HOME=<mount_point> - Connect your mirroring device to the internet.
- Copy the installer files for the CLI tools to the removable storage device.
- Create the following environment variables with the installer image name and the image inventory on your mirroring device.
export CASE_NAME=ibm-cp-security && export CASE_VERSION=1.0.28 -
Download the IBM Cloud Pak for Security installer and image inventory to your mirroring device.
oc ibm-pak get $CASE_NAME --version $CASE_VERSION --disable-top-level-images-modeThe CASE is saved to the $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION directory and the log file is saved to $IBMPAK_HOME/.ibm-pak/logs/oc-ibm_pak.log.
Tip: If you want the installation process to be repeatable across environments, you can reuse the same saved CASE instead of downloading the CASE files again.
For your convenience, you can create a file of all variables used:
[root@rhel8 ~]# cat /store/cp4s.var
export IBMPAK_HOME=/store
export CASE_NAME=ibm-cp-security
export CASE_VERSION=1.0.28
export V2_DIR=$IBMPAK_HOME/v2
export TARGET_REGISTRY=<registry_server>:5000
export REGISTRY_AUTH_FILE=$IBMPAK_HOME/.ibm-pak/auth.json
podman login cp.icr.io -u cp -p '<ibm entitlement key>'
podman login $TARGET_REGISTRY -u airgap -p '<password>'
export CP4S_NAMESPACE=cp4s
and for the Red Hat OpenShift mirror:
[root@rhel8 ~]# cat /store/ocp.var
OCP_RELEASE=4.10.32
LOCAL_REGISTRY=’<registry_server>:5000’
LOCAL_REPOSITORY=ocp4/openshift410
PRODUCT_REPO='openshift-release-dev'
LOCAL_SECRET_JSON='/store/pullsecret.json'
RELEASE_NAME='ocp-release'
ARCHITECTURE='x86_64'
REMOVABLE_MEDIA_PATH=/store
As the SQLite-based index image is deprecated, create a File-based catalog for the serverless operator following the steps from the link provided. When the SQLite-based method is used, it might be noticed that some images are missing from the ImageContentSourcePolicy.
Reference: https://docs.openshift.com/container-platform/4.10/operators/admin/olm-managing-custom-catalogs.html
Make sure you are using oc client version 4.10.x.
Create the directory structure for the file-based catalog.
mkdir -p ~/rh-operators/serverless-operator-index
Change to the rh-operators directory and create the Dockerfile that can build a catalog image.
cd ~/rh-operators
vi serverless-operator-index.Dockerfile
Here is the serverless-operator-index.Dockerfile:
# The base image is expected to contain
# /bin/opm (with a serve subcommand) and /bin/grpc_health_probe
FROM registry.redhat.io/openshift4/ose-operator-registry:v4.10
# Configure the entrypoint and command
ENTRYPOINT ["/bin/opm"]
CMD ["serve", "/configs"]
# Copy declarative config root into image at /configs
ADD serverless-operator-index /configs
# Set DC-specific label for the location of the DC root directory
# in the image
LABEL operators.operatorframework.io.index.configs.v1=/configs
Then, initialize the catalog with the package definition.
opm init serverless-operator --output yaml > serverless-operator-index/index.yaml
Edit the file serverless-operator-index/index.yaml that gets generated and set the defaultChannel to stable.
Next, you need to add the serverless bundle to the catalog.
To determine which bundle you need to add, pull-down the information about available bundles from the Red Hat registry registry.redhat.io/redhat/redhat-operator-index:v4.10
opm alpha list bundles registry.redhat.io/redhat/redhat-operator-index:v4.10 > rh-registry-bundles.txt
Review the rh-registry-bundles.txt and look for the information for the serverless operator. You can see multiple lines for different version of the serverless operator.
There are normally 7 fields returned by the list bundles command, which are PACKAGE, CHANNEL, BUNDLE, REPLACES, SKIPS, SKIP RANGE, IMAGE. Some fields might be empty, but the most relevant are the PACKAGE, CHANNEL, BUNDLE, and IMAGE field.
It is recommended to use the latest version of the operator that is available, and currently the version is v1.24.0.
serverless-operator stable serverless-operator.v1.24.0 serverless-operator.v1.23.0 >=1.23.0 <1.24.0 registry.redhat.io/openshift-serverless-1/serverless-operator-bundle@sha256:0422f8843fc62c2b72e01ffefd33db912a1ad3d70ac297882d3663c9b7299f10
Now with the information from the rh-registry-bundle.txt adds the bundle to the catalog by using the information from the IMAGE field.
opm render registry.redhat.io/openshift-serverless-1/serverless-operator-bundle@sha256:0422f8843fc62c2b72e01ffefd33db912a1ad3d70ac297882d3663c9b7299f10 --output=yaml >> serverless-operator-index/index.yaml
Next, add a channel entry to the bundle by editing the file serverless-operator-index/index.yaml
vi serverless-operator-index/index.yaml
The information from the rh-registry-bundles.txt file is used to create the channel entry.
---
schema: olm.channel
package: serverless-operator
name: stable
entries:
- name: serverless-operator.v1.24.0
Now validate the file-based catalog and make sure the command return an error code of 0.
opm validate serverless-operator-index
echo $?
Build the catalog image and tag it with the information for the local registry.
podman build . -f serverless-operator-index.Dockerfile -t $LOCAL_REGISTRY/olm/serverless-operator:v1.24.0
Then, push the catalog image to the local registry.
Log in to the local registry.
podman login $LOCAL_REGISTRY
Then, use the push command to push the catalog image to the local registry.
podman push $LOCAL_REGISTRY/olm/serverless-operator:v1.24.0
Alternatively, if you need to transfer the image to another offline host you can push the image to a docker-archive file.
podman push $LOCAL_REGISTRY/olm/serverless-operator:v1.24.0 docker-archive://$IBMPAK_HOME/serverless-operator.tar
You can then use the Podman load command to import the image on the offline host and push it to the registry of the offline host.
cat serverless-operator.tar | podman load
To mirror the image contents of the serverless operator catalog and upload it to the local registry, run the following command:
oc adm catalog mirror $LOCAL_REGISTRY/olm/serverless-operator:v1.24.0 $LOCAL_REGISTRY/olm
Create a CatalogSource for the Red Hat OpenShift cluster to use the catalog image from the local registry adapting this example:
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: oh-registry-serverless-operator-index
namespace: openshift-marketplace
spec:
image: $LOCAL_REGISTRY/olm/serverless-operator:v1.24.0
sourceType: grpc
secrets:
- "catalog-registry-secret"
displayName: oh-registry serverless Catalog
publisher: OH
updateStrategy:
registryPoll:
interval: 30m
As in the example yaml file, the registry needs authentication to access the contents.
Therefore, you need to create a secret, which contains the authentication credentials for the local registry.
You can create this from a JSON file, which displays the following information.
{
"auths": {
"$LOCAL_REGISTRY": {
"auth": "<base 64 encoded authentication credentials>",
"email": "<email address>"
}
}
}
Then, create the secret in the Red Hat OpenShift cluster in the namespace openshift-marketplace by using the command.
oc create secret generic catalog-registry-secret -n openshift-marketplace --from-file=.dockerconfigjson=pull-secret-registry.json --type=kubernetes.io/dockerconfigjson
Then, create the new CatalogSource for your local registry.
oc apply -f catalogSource.yaml
You can verify that the new CatalogSource is present by checking the running pods of the openshift-marketplace namespace.
oc get pods -n openshift-marketplace
The Red Hat OpenShift documentation is correct: Mirroring images for a disconnected installation - Disconnected installation mirroring | Installing | OpenShift Container Platform 4.10, here is how it was done.
Use the file-based method, create a pruned catalog.
The mirror command creates flat files and creates a v2/ directory in your current directory.
oc adm catalog mirror $LOCAL_REGISTRY/olm/serverless-operator:v1.24.0 file:///local/index -a ${HOME}/.docker/config.json --index-filter-by-os='linux/amd64'
Make sure that you are using the appropriate version of oc; it was attempted with version 4.8.32 and it did not work (no database file found in /tmp/033374685, then with version 4.10.28 it worked.
Without the pruned index image, the complete catalog would be mirrored. With the pruned index image, in this case with only 1 operator, the space used was around 39 GiB.
Then on the secure side to upload local images to a registry, run:
cd $IBMPAK_HOME
oc adm catalog mirror file://local/index/olm/serverless-operator:v1.24.0 $LOCAL_REGISTRY/olm
To create the manifests, run the oc adm catalog mirror command again. Use the newly mirrored index image as the source and the same mirror registry namespace used in the previous step as the target.
The flag is required for this step so that the command does not copy all of the mirrored content again.--manifests-only
oc adm catalog mirror $LOCAL_REGISTRY/olm/serverless-operator:v1.24.0 $LOCAL_REGISTRY/olm --manifests-only
This step is required because the image mappings in the imageContentSourcePolicy.yaml file generated during the previous step must be updated from local paths to valid mirror locations. Failure to do so causes errors when you create the ImageContentSourcePolicy object in a later step.
After you mirror the catalog, you can continue with the remainder of your cluster installation. After your cluster installation is successfully finished, you must specify the manifests directory from this procedure to create the ImageContentSourcePolicy and CatalogSource objects. These objects are required to enable installation of Operators from OperatorHub.
Generated manifests
After mirroring Operator catalog content to your mirror registry, a manifests directory is generated in your current directory.
The manifests directory name takes the following pattern:
manifests-redhat-operator-index-<random_number>
The manifests directory name is referenced in subsequent procedures
The manifests directory contains the following files, some of which might require further modification:
- The catalogSource.yaml file is a basic definition for a CatalogSource object that is prepopulated with your index image tag and other relevant metadata. This file can be used as is or modified to add the catalog source to your cluster. If you mirrored the content to local files, you must modify your catalogSource.yaml file to remove any forward slash (/) characters from the metadata.name field. Otherwise, when you attempt to create the object, it fails with an "invalid resource name" error.
- The imageContentSourcePolicy.yaml file defines an ImageContentSourcePolicy object that can configure nodes to translate between the image references stored in Operator manifests and the mirrored registry. To check whether all images for the
serverless-operator-bundleare present in your imageContentSourcePolicy.yaml, you can run:opm render registry.redhat.io/openshift-serverless-1/serverless-operator-bundle@sha256:0422f8843fc62c2b72e01ffefd33db912a1ad3d70ac297882d3663c9b7299f10 --output=yaml - The mapping.txt file contains all of the source images and where to map them in the target registry. This file is compatible with the
oc image mirrorcommand and can be used to further customize the mirroring configuration.
If you used the --manifests-only flag during the mirroring process and want to further trim the subset of packages to mirror, see the steps in the Mirroring a package manifest format catalog image procedure of the Red Hat OpenShift Container Platform 4.7 documentation. Look for the section about modifying your mapping.txt file and use the file with the oc image mirror command.
After you mirror the catalog, you can continue with the remainder of your cluster installation. After your cluster installation successfully finishes, you must specify the manifests directory from this procedure to create the ImageContentSourcePolicy and CatalogSource objects. These objects are required to populate and enable installation of Operators from OperatorHub.
Populating OperatorHub from mirrored Operator catalogs
If you mirrored Operator catalogs for use with disconnected clusters, you can populate OperatorHub with the Operators from your mirrored catalogs. You can use the generated manifests from the mirroring process to create the required ImageContentSourcePolicy and CatalogSource objects.
Creating the ImageContentSourcePolicy object
After mirroring Operator catalog content to your mirror registry, create the required ImageContentSourcePolicy (ICSP) object. The ICSP object configures nodes to translate between the image references stored in Operator manifests and the mirrored registry.
Procedure
- On a host with access to the disconnected cluster, create the ICSP by running the following command to specify the yaml file in your manifests directory:
oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yamlwhere <path/to/manifests/dir> is the path to the manifests directory for your mirrored content.
You now can create a CatalogSource object to reference your mirrored index image and Operator content.
After the Image Content Source Policy is updated, all the nodes (master, infra, and workers) in the cluster must be updated and rebooted. This process is automatically handled through the Machine Config Pool operator and take up to 30 minutes although the exact elapsed time might vary based on the number of nodes in your Red Hat OpenShift cluster.
Adding a catalog source to a cluster
Adding a catalog source to a Red Hat OpenShift Container Platform cluster enables the discovery and installation of Operators for users. Cluster administrators can create a CatalogSource object that references an index image. OperatorHub uses catalog sources to populate the user interface.
Prerequisites
- An index image built and pushed to a registry.
Procedure
oc adm catalog mirror command to mirror your catalog to a target registry, you can use the generated yaml file in your manifests directory as a starting point.- Modify the following to your specifications and save it as a yaml file:
apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-operator-catalog namespace: openshift-marketplace spec: sourceType: grpc image: <registry>/<namespace>/redhat-operator-index:v4.10 displayName: My Operator Catalog publisher: <publisher_name> updateStrategy: registryPoll: interval: 30mname: If you mirrored content to local files before you uploaded it to a registry, remove any forward slash (/) characters from themetadata.namefield to avoid an "invalid resource name" error when you create the object.
namespace: If you want the catalog source to be available globally to users in all namespaces, specify theopenshift-marketplacenamespace. Otherwise, you can specify a different namespace for the catalog to be scoped and available only for that namespace.
image: Specify your index image.
publisher: Specify your name or an organization name publishing the catalog. - Use the file to create the CatalogSourceobject:
oc apply -f catalogSource.yamloc get pods -n openshift-marketplaceExample outputNAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26hoc get catalogsource -n openshift-marketplaceExample outputNAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5soc get packagemanifest -n openshift-marketplaceExample outputNAME CATALOG AGE serverless-Operator My Operator Catalog 93s
You now can install the Operators from the OperatorHub page on your Red Hat OpenShift Container Platform web console.
Mirroring images takes the image from the internet to your mirroring device, then effectively copies that image on to your air-gapped environment. After you mirror your images, you can configure your cluster and complete the air-gapped installation.
In these steps, your mirroring device is connected to the internet and disconnected from your air-gapped environment.
Procedure
Set the $TARGET_REGISTRY environment variable to the IP address or FQDN and the port for your target registry. The target registry is the registry where your images are mirrored to and accessed by the Red Hat OpenShift Container Platform cluster.
export TARGET_REGISTRY=<target_registry>
Verify access to the target registry.
podman login $TARGET_REGISTRY
Generate the mirror manifests to use when you mirror the images to the target registry.
oc ibm-pak generate mirror-manifests $CASE_NAME file://cp4s_images --version $CASE_VERSION --final-registry $TARGET_REGISTRY
The following files are generated in the $IBMPAK_HOME/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION directory
- images-mapping-to-filesystem.txt
- images-mapping-from-filesystem.txt
- image-content-source-policy.yaml
These files are used when you mirror the images to your target registry.
ls -la $IBMPAK_HOME/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION
Tip: If you want to view the list of images to be mirrored, type the following command:
oc ibm-pak describe $CASE_NAME --version $CASE_VERSION --list-mirror-images | less
Store the authentication credentials for the IBM Entitled Registry, cp.icr.io.
- If you are using Podman, store authentication credentials for cp.icr.io by typing the following commands:
export REGISTRY_AUTH_FILE=$IBMPAK_HOME/.ibm-pak/auth.json podman login cp.icr.io -u cp -
If you are using Docker, store authentication credentials for cp.icr.io by typing the following commands.
export REGISTRY_AUTH_FILE=$IBMPAK_HOME/.docker/config.json docker login cp.icr.io -u cp
The password is your IBM Entitled Registry key.
The command stores and caches the registry credentials in the location that is specified for the $REGISTRY_AUTH_FILE environment variable.
Store the authentication credentials for your TARGET_REGISTRY
export REGISTRY_AUTH_FILE=$IBMPAK_HOME/.ibm-pak/auth.json
podman login $TARGET_REGISTRY
or if using Docker
export REGISTRY_AUTH_FILE=$IBMPAK_HOME/.docker/config.json
docker login $TARGET_REGISTRY
Set $IBMPAK_HOME to your current directory
cd $IBMPAK_HOME
Mirror images to your local file system
oc image mirror \
-f $IBMPAK_HOME/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping-to-filesystem.txt \
--filter-by-os '.*' \
-a $REGISTRY_AUTH_FILE \
--insecure \
--skip-multiple-scopes \
--max-per-registry=1
The images are mirrored to a directory called v2/cp4s_images in the current directory. If you run into errors like error parsing HTTP 429 response body: unexpected end of JSON input: "", repeat the oc image mirror command until the whole process completed without errors. The existing images in the local image registry will not be downloaded again. Error HTTP 429 means too many requests to the registry server. The whole process takes about 90 minutes, depending on network speed.
Optionally, copy the following files and directories from your local file system to your storage device.
- The v2 directory that was generated in the previous step.
- The
$IBMPAK_HOME/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSIONdirectory.
Important: When you copy these files to your portable storage device, ensure that you use the same path on the portable storage device.
Notes
- You also might want to copy this document, the pull-secrets, the CLI installers, and a RHEL iso to the storage device as well as the SHA256 values for the installers and the iso. If required, the storage device can be scanned by the customer’s IT department. The Red Hat OpenShift documentation, see https://docs.openshift.com/container-platform/4.10/installing/installing_vsphere/installing-restricted-networks-vsphere.html, can be downloaded and saved as a pdf onto this storage device as well. If your pdf contains only blank pages, try a different browser. You can download the CLI installers with yum download. For example, the command
downloads the podman-xxx.rpm to the current directory.yum download podman - Download Red Hat OpenShift CLI 4.10 or later from https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/. The file to download is called openshift-client-<platform>-<version>.tar.gz.
- To download the latest release version from the public GitHub repo on Linux®, type the following command
curl -L https://github.com/IBM/ibm-pak-plugin/releases/latest/download/oc-ibm_pak-linux-amd64.tar.gz -o oc-ibm_pak-plugin.tar.gz - To save the Podman registry engine into a tar file, type the following command:
podman save -o registry.tar registry:2 - Save the rhcos.ova file onto the storage device as well. You have to import it into the vSphere server.
In these steps, the mirroring device is disconnected from the internet and connected to the air-gapped environment.
- Disconnect your mirroring device from the internet.
- Check whether the CLI tools are installed on the mirroring device in the air-gapped environment.
- WSL (if Windows)
- Docker CLI or Podman CLI
- Red Hat OpenShift CLI
- IBM Catalog Management plug-in for Red Hat OpenShift CLI
- Mount the removable storage device to the mirroring device in the air-gapped environment.
- Install the CLI tools.
tar -xvf openshift-client-linux-4.10.32.tar.gz cp oc /usr/local/sbin/oc tar -xvf oc-ibm_pak-plugin.tar.gz cp oc-ibm_pak /usr/local/sbin/ - Create the SAN certificate
openssl genrsa -out private/cakey.pem 4096 openssl req -new -x509 -days 3650 -config openssl.cnf -key private/cakey.pem -out certs/cacert.pem openssl genrsa -out server.key openssl req -new -key server.key -out server.csr -config server_cert.cnf openssl x509 -req -days 365 -in server.csr -CA /root/tls/certs/cacert.pem -CAkey /root/tls/private/cakey.pem -CAcreateserial -out server.crt -extensions req_ext -extfile server_cert.cnf - Trust the SAN certificate
ln -s /etc/pki/tls/certs/server.crt /etc/pki/ca-trust/source/anchors update-ca-trust - Copy the trusted SAN certificate
cp /root/tls/server.* /var/lib/registry/certs/ - Load the Podman registry image with the following command:
cat /store/registry.tar | podman load - Tag the Podman registry image with the following commands:
podman images podman tag <IMAGE ID> registry:air - Run the Podman registry with the following command:
docker run –privileged -d \ --restart=always \ --name registry \ -v /var/lib/registry/certs:/certs:Z \ -v /var/lib/registry:/var/lib/registry:Z \ -e REGISTRY_HTTP_ADDR=0.0.0.0:5000 \ -e REGISTRY_HTTP_TLS_CERTIFICATE=/var/lib/registry/certs/server.crt \ -e REGISTRY_HTTP_TLS_KEY=/var/lib/registry/certs/server.key \ -p 5000:5000 \ registry:air - Verify that you can log in to the registry.
- Verify that Red Hat OpenShift is installed on the cluster. If needed, follow the Red Hat OpenShift documentation to install it, see https://docs.openshift.com/container-platform/4.10/installing/installing_vsphere/installing-restricted-networks-vsphere.html.
- Here are the variables you might want to use:
OCP_RELEASE=4.10.32 LOCAL_REGISTRY='rhel8.ocp4.airgap:5000' LOCAL_REPOSITORY=ocp4/openshift410 PRODUCT_REPO='openshift-release-dev' LOCAL_SECRET_JSON='/store/pullsecret.json' RELEASE_NAME='ocp-release' ARCHITECTURE='x86_64' REMOVABLE_MEDIA_PATH=/store - To mirror the Red Hat OpenShift flat files to the local registry, you can use:
oc image mirror -a ${LOCAL_SECRET_JSON} \ --from-dir=${REMOVABLE_MEDIA_PATH}/mirror \ "file://openshift/release:${OCP_RELEASE}*" \ ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} - To create the installation program that is based on the content that you mirrored, extract it and pin it to the release:
oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install –from="${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}" - If you run into errors like "emergency.target" it means the ignition failed. Check your ignition settings and reboot the node.
- After you start the worker nodes, approve the certificate signing requests.
oc get csr -A -o name | xargs oc adm certificate approve - Set the environment variable IBMPAK_HOME to the mount point of the storage device.
export IBMPAK_HOME=<mount_point> - Set the $TARGET_REGISTRY environment variable to the IP address or FQDN and the port for your target registry. The target registry is the registry where your images are mirrored to and accessed by the Red Hat OpenShift Container Platform cluster.
export TARGET_REGISTRY=<target_registry> - Create the following environment variables with the installer image name and the image inventory on your mirroring device by typing the following command. <path_to_V2> is the path to the V2 directory generated in step 4 of Mirroring images from the internet to your mirroring device.
export CASE_NAME=ibm-cp-security export CASE_VERSION=1.0.28 export V2_DIR=<path_to_V2> - Store the authentication credentials for your target registry.
- If you are using Podman, store authentication credentials for your target registry.
export REGISTRY_AUTH_FILE=$IBMPAK_HOME/.ibm-pak/auth.json podman login $TARGET_REGISTRY - If you are using Docker, store authentication credentials for your target registry.
export REGISTRY_AUTH_FILE=$IBMPAK_HOME/.docker/config.json docker login $TARGET_REGISTRY - The command stores and caches the registry credentials in the location that is specified for the $REGISTRY_AUTH_FILE environment variable.
- If you are using Podman, store authentication credentials for your target registry.
- If your target registry is on a different host than in the insecure environment, you need to edit the file images-mapping from-filesystem.txt in the $IBMPAK_HOME/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/ directory
sed -i “s/<old_registry/new_registry>/g” images-mapping-from-filesystem.txt - Check whether you have enough space in your root directory for the registry.
df -h -
If you run out of disk space in your root volume, you need to add more space.
vgextend lvextend xfs-growfs - Mirror images from your mirroring device to the target registry.
oc image mirror \ -f $IBMPAK_HOME/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/images-mapping-from-filesystem.txt \ --from-dir=$IBMPAK_HOME \ --filter-by-os '.*' \ -a $REGISTRY_AUTH_FILE \ --insecure \ --skip-multiple-scopes \ --max-per-registry=1 - Log in to the Red Hat OpenShift Container Platform cluster as a cluster administrator.
oc login <openshift_URL> --username=<cluster_admin_user> --password=<cluster_admin_password>If you are getting errors complaining about a self-signed certificate, you can log in to the UI, and then grab the command line token session login. - Update the global image pull secret for your Red Hat OpenShift Container Platform cluster and add the credentials for your target registry.
oc registry login --registry="$TARGET_REGISTRY" --auth-basic="<username>:<password>" --to=<pull_secret_location>- Retrieve the existing global pull secret by typing the following command, where <pull_secret_location> is the location of the file where you want to store the global pull secret configuration.
oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' > <pull_secret_location> - Add the new pull secret to the global pull secret file by typing the following command, where <username> and <password> are the username and password for your target registry.
- Update the global pull secret in the cluster
oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> - Verify the status of the nodes
oc get MachineConfigPool -w
- Retrieve the existing global pull secret by typing the following command, where <pull_secret_location> is the location of the file where you want to store the global pull secret configuration.
- After the global pull secret is updated, the configuration of your nodes is updated sequentially.
Important: Wait until all MachineConfigPools are updated before you proceed to the next step. - Edit the ImageContentSourcePolicy resource
vim $IBMPAK_HOME/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/image-content-source-policy.yaml - Check whether the correct mirror registry is there, if not:
:%s/<old_registry>/<new_registry>/g - Create the ImageContentSourcePolicy resource.
oc apply -f $IBMPAK_HOME/.ibm-pak/data/mirror/$CASE_NAME/$CASE_VERSION/image-content-source-policy.yaml - Verify that the ImageContentSourcePolicy resource is created.
oc get imageContentSourcePolicy ibm-cp-security -o yaml - Verify the status of the nodes.
oc get MachineConfigPool -wAfter the ImageContentSourcePolicy resource is created, the configuration of your nodes is updated sequentially.
Important: Wait until all MachineConfigPools are updated before you proceed to the next step. - If you are using an insecure registry, you must add the local registry to the cluster insecureRegistries
oc patch image.config.openshift.io/cluster --type=merge \ -p '{"spec":{"registrySources":{"insecureRegistries":["'${TARGET_REGISTRY}'"]}}}'Important: Do not use insecure registries for production systems. - Verify the status of the nodes.
oc get MachineConfigPool -wAfter the insecureRegistries list is updated, the configuration of your nodes is updated sequentially.
Important: Wait until all MachineConfigPools are updated before you proceed to the next step.
After your images are mirrored to your target registry, you can deploy Cloud Pak for Security to Red Hat OpenShift in your air-gapped environment.
Include specific IP addresses and URLs in an allowlist at the network layer for sites that need to be accessed externally. For more information, see Creating an allowlist for air-gapped installation.
Procedure
- Log in to the Red Hat OpenShift Container Platform cluster as a cluster administrator.
oc login <openshift_URL> --username=<cluster_admin_user> --password=<cluster_admin_password>If you are getting errors complaining about a self-signed certificate, you can log in to the UI, and then grab the command line token session login. Do not use the system: admin account because you can get SCC errors. - Verify that there is an ImageContentSourcePolicy named ibm-cp-security.
oc get imagecontentsourcepolicy - Create the namespace where you are installing Cloud Pak for Security.
oc new-project <cp4s_namespace> - Set the $CP4S_NAMESPACE environment variable to <cp4s_namespace>, the namespace where you are installing Cloud Pak for Security.
export CP4S_NAMESPACE=<cp4s_namespace> - Extract the Cloud Pak for Security CASE by typing the following command.
tar -xf $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION/ibm-cp-security-$CASE_VERSION.tgz -C $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION - Update the parameters in the $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION/ibm-cp-security/inventory/ibmSecurityOperatorSetup/files/values.conf file. The following table lists the configurable parameters for the Cloud Pak for Security installation and their descriptions.
Important: Do not use a values.conf file from a release older than 1.8 because some of the parameters are different. Using a values.conf file from a release older than 1.8 causes the installation to fail. - Important, if you define a domain, you have to specify the whole FQDN for the URL, like cp4s.apps.ocp4.airgap
- Archive the Cloud Pak for Security CASE by typing the following command:
tar czf $IBMPAK_HOME/.ibm-pak/data/cases/ibm-cp-security/$CASE_VERSION/ibm-cp-security-$CASE_VERSION.tgz -C $IBMPAK_HOME/.ibm-pak/data/cases/ibm-cp-security/$CASE_VERSION/ ibm-cp-security - Install Cloud Pak for Security by typing the following command:
Important: Read the Cloud Pak for Security license that is in the $IBMPAK_HOME/.ibm-pak/data/cases/ibm-cp-security/licenses directory. By accepting the license, you confirm that you read the license, and accept the terms. For the Cloud Pak for Security installation to proceed, the acceptLicense true parameter is added to the installation action. After Cloud Pak for Security is installed, you can use the license and usage page to turn on and off applications to comply with your Cloud Pak for Security license purchase. For more information, see Managing licensing and usage.oc ibm-pak launch -t 1 $CASE_NAME --version $CASE_VERSION --inventory ibmSecurityOperatorSetup --namespace $CP4S_NAMESPACE --action install --args "--acceptLicense true --inputDir $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION" - After a few minutes you see this output:
... [✓] CASE launch script completed successfully configmap/cp4s-values created [INFO] Installing Cloud Pak for Security via OLM [INFO] Create Cloud Pak for Security operator subscription subscription.operators.coreos.com/ibm-cp-security-operator created [INFO] Waiting for ibm-cp-security-operator CSV to be created... [INFO] Waiting for ibm-cp-security-operator CSV to be created... [INFO] ibm-cp-security-operator CSV has been successfully created. [INFO] Setting up certificates secret/isc-ingress-default-secret created cp4sthreatmanagement.isc.ibm.com/threatmgmt created [✓] CASE launch script completed successfully - In the OpenShift Web Console, select Home > Events > Project: All Projects.
- Check whether the images are being pulled successfully.
Important: Installation takes approximately 1.5 hours. When installation is complete, the latest version of IBM Cloud Pak foundational services, and Cloud Pak for Security 1.10.0 are installed. - Verify Cloud Pak for Security installation by typing the following command:
oc ibm-pak launch -t 1 $CASE_NAME --version $CASE_VERSION --inventory ibmSecurityOperatorSetup --namespace $CP4S_NAMESPACE --action validate - The following message is displayed when installation is complete:
[INFO] IBM Cloud Pak for Security deployment is complete. - If the following message is displayed, follow the instructions in SOAR playbooks not available, or SOAR automation limited to resolve the issue. Knative Serving needs to be installed. You do not need to reinstall Cloud Pak for Security.
[WARN] IBM Cloud Pak for Security deployment is complete but SOAR Playbooks are not available. - To get the IBM provided credentials:
oc get secret platform-auth-idp-credentials -o jsonpath='{.data.admin_username}' -n ibm-common-services | base64 -d | awk '{print $1}' oc get secret platform-auth-idp-credentials -o jsonpath='{.data.admin_password}' -n ibm-common-services | base64 -d | awk '{print $1}'
Upgrade from 1.10.3 to 1.10.4 using CASE
Mirror the contents for the CASE_VERSION=1.0.29 and upload it to the mirror registry. Afterward, you can see that most CSVs get updated to version 1.10.4, but the CSV for IBM Cloud Pak for Security (ibm-cp-security-operator.v1.10.3) and IBM Cloud Pak for Security Foundations Services (cp4s-foundations-operator.v1.10.3) did not get updated as expected and stayed at version 1.10.3.
It appears that the rollback of the foundational services does the trick here.
It does detect that there is a newer version available when communicating to the registry, as most of the CSVs are updated as expected after uploading the content to the mirror registry. Just if you go from 1.10.3 to 1.10.4 in a mirrored environment you also need to run the cs_rollback, the CASE script runs the rollback script.
Upgrade from 1.10.3 to 1.10.4 by using the web console
oc edit subscription ibm-cp-security-operator
..
19 spec:
20 channel: v1.10
21 installPlanApproval: Automatic
22 name: ibm-cp-security-operator
23 source: cp4s
24 sourceNamespace: openshift-marketplace
25 startingCSV: ibm-cp-security-operator.v1.10.4
26 status:
..
If under spec: you find this line:
startingCSV: ibm-cp-security-operator.v1.10.4
you need to remove the startingCSV: line completely before the rollback of the foundational services to the Long Time Support Release.
oc exec deploy/cp-serviceability -- /opt/bin/cs_rollback -f --channel v1.10 $(oc whoami -t) ${NAMESPACE} ibm-common-services
source /store/cp4s.var
cd $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION
oc ibm-pak launch -t 1 --case ibm-cp-security --version /$CASE_VERSION --inventory ibmSecurityOperatorSetup --namespace /$CP4S_NAMESPACE --action uninstall
If you do not have any other instances of Cloud Pak for Security on your cluster, delete the catalog sources and image content source policies from the openshift-marketplace namespace, and the CRDs from the cluster, by typing the following command:
oc ibm-pak launch -t 1 $CASE_NAME --version /$CASE_VERSION --inventory ibmSecurityOperatorSetup --namespace /$CP4S_NAMESPACE --action uninstall --args "--deleteCrd --airgap"
If you do not have any other IBM Cloud Paks on your cluster, you can uninstall IBM Cloud® foundational services by typing the following command:
oc ibm-pak launch -t 1 $CASE_NAME --version /$CASE_VERSION --inventory ibmSecurityOperatorSetup --namespace ibm-common-services --action uninstall-foundationalservices --args "--inputDir $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME /$CASE_VERSION"
At this stage, both namespaces cp4s and ibm-common-services have been deleted.
If you find that a namespace remains "terminating" you might want to try https://www.redhat.com/sysadmin/openshift-terminating-state
The registered trademark Linux® is used pursuant to a sublicense from the Linux Foundation, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis.ation.
Red Hat® and OpenShift® are trademarks or registered trademarks of Red Hat, Inc. or its subsidiaries in the United States and other countries.
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
03 August 2024
UID
ibm16826041