☰
Conductor Documentation

WRC-CFS Deployment on WRCP

Introduction

CFS (Conductor File Service) provides file access and retrieval, as well as WRCP ISO customization services for WRC workflows.

This page explains how to deploy CFS within WRCP. CFS utilizes Ceph for persistent storage, and administrators can configure multiple replicas (more than one) across worker nodes to ensure high availability.

IMPORTANT: Deploying CFS within the same WRCP cluster it is intended to manage can create a circular dependency during upgrades. If the WRCP cluster hosting CFS becomes unavailable, CFS itself will be unavailable, potentially disrupting upgrades or other operations that rely on CFS. This deployment model is supported for specific customer requests, but it is strongly recommended to deploy CFS on a separate cluster or infrastructure if possible. This document assumes a co-located deployment (CFS within the managed WRCP cluster) unless otherwise specified. Carefully consider the implications for high availability and upgrade procedures before choosing a co-located deployment.

Installation Procedure

Create an override-values.yaml file as shown in the following example:

# Default values for cfs services.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
nameOverride: "cfsapp"
fullnameOverride: "cfsapp"
 
global:
  namespace: cfs
 
cfsapp:
  image:
    repository: (registry-ip)/conductor/conductor-file-service
    tag: WRC_latest-250102_1651Z
  logginglevel: "DEBUG"
  FILE_SERVER_URLROOT: "http://<wrcp-floating-ip>:30220"  # Use a distinct IP
  FILE_SERVER_PATHROOT: "/cfs-data"
 
cfsfileserver:
  image:
    repository: (registry-ip)/conductor/nginxinc/nginx-unprivileged  # Use the same distinct IP
    tag: 1.25.4
 
volume:
  accessModes: ReadWriteOnce
 
persistentVolume:
  size: 20Gi
  storageClass: cephfs
 
certificates:
  enabled: false

Installation Command:

You have the following installation options:

If you choose to not configure certificates, run following:

<cfs-charts.tgz> is the downloaded CFS Helm chart package.

helm install -n cfs cfsapp -f cfs-override-values.yaml <cfs-charts.tgz>

If choose to configure certificates, extract the helm chart, create certificates directory under resources, follow Certifications configuration instructions, and then run following:

helm install -n cfs cfsapp . -f cfs-override-values.yaml

Uninstall Command:

To uninstall, enter:

helm uninstall cfsapp -n cfs

Upload a file:

Login to the WRCP cluster that hosts cfs and run the following commands:

Get the name of the CFS pod (replace with the actual pod name).

kubectl get pods -n cfs

Open a shell within the cfsfileserver container inside the CFS pod.

kubectl exec -it <cfsapp pod> /bin/bash  -n cfs -c cfsfileserver

Copy a file (e.g., test.yaml) from your local machine to the /cfs-data directory within the cfsfileserver container:

kubectl cp test.yaml <cfsapp pod>:/cfs-data -n cfs -c cfsfileserver

File Access: 

http://<wrcp-floating-ip>:30220/

ISO customization Access: 

http://<wrcp-floating-ip>:30215/

Example: ISO customization access

Certificate Configuration (Optional)

These steps describe how to configure TLS certificates for CFS. This is optional but recommended for production deployments.

  1. Create a Certificate Directory:

On the WRCP host that will host CFS, create a directory to hold the CFS certificates.

mkdir -p resources/certificates

(This assumes you are in the extracted helm chart directory.)

Generate Certificates (if using selfSigned certs)

  1. Generate Certificates on CFS WRCP host:

On a secure machine (this could be your local machine or a dedicated CA server), generate a root CA key and certificate.

openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=SelfSignedRootCA"
  1. Generate Server Certificates:

On the WRCP host that will host CFS, generate the server key and certificate signing request (CSR).

openssl genrsa -out server.key 2048
 
openssl req -newkey rsa:2048 -nodes \
  -subj "/CN=<wrcp-floating-ip>" \
  -addext "subjectAltName=IP:<wrcp-floating-ip>" \
  -keyout server.key \
  -out server.csr

Important: Replace with the actual floating IP address of your WRCP cluster.

openssl x509 -req \
  -in server.csr \
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -days 3650 \
  -sha256 \
  -out server.crt \
  -extfile <(echo "subjectAltName=IP:<wrcp-floating-ip>")

Important: Replace <wrcp-floating-ip> with the actual floating IP address of your WRCP cluster.

  1. Move Certificates:

On the WRCP host that will host CFS, move the generated server certificates to the resources/certificates/ directory:

cp /tmp/server.crt resources/certificates/
cp /tmp/server.key resources/certificates/
  1. Update override-values.yaml:

Modify your cfs-override-values.yaml file to enable certificates and point to the correct certificate files:

FILE_SERVER_URLROOT: "https://<wrcp-floating-ip>:30220"  # Use HTTPS and the correct IP
certificates:
  enabled: true
  serverCert: "resources/certificates/server.crt"
  serverKey: "resources/certificates/server.key"
  1. Configure WRC (Important):

To enable certificate verification on the WRC side, you must configure WRC to trust the CA certificate. This typically involves:

1. Setting the following input parameters in your WRC workflow configuration:
    - `cfs_use_custom_ssl_ca_bundle: true`
    - `file_server_use_custom_ssl_ca_bundle: true`
2. Creating a Kubernetes secret named cfs_ssl_ca_chain containing the contents of your ca.crt file. The exact steps for creating this secret depend on your WRC setup. Consult the WRC documentation for details.
  1. Verification:

On a machine that has access to the WRCP cluster and has the ca.crt file, verify the certificate configuration using curl.

Replace and ca.crt with appropriate value.

You should see a successful TLS handshake and the output of the Nginx index page if everything is configured correctly. The output should include “SSL certificate verify ok.”

curl https://<wrcp-floating-ip>:30220 -v --cacert ca.crt
*   Trying xx.xx.xx.xx:30220...
* Connected to xx.xx.xx.xx (xx.xx.xx.xx) port 30220 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: server.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  start date: Jan  2 01:29:50 2025 GMT
*  expire date: Dec 31 01:29:50 2034 GMT
*  subjectAltName: host "2620:10a:a001:aa0c::70" matched cert's IP address!
*  issuer: CN=2620:10a:a001:aa0c::70
*  SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.74.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP OK
  Server: nginx
  Date: Thu Jan :42:06 GMT
  Content-Type: texthtml
  Transfer-Encoding: chunked
  Connection: keep-alive
  html>
<head><title>Index of /</title></head>
<body>
<h1>Index of /</h1><hr><pre><a href="../">../</a>
</pre><hr></body>
</html>