Operations Guide

Referenced documentation

Introduction

The Orchestrator is a component of SWaaP.

The component is in charge of making TDP SWF compliant to host Export Control Projects, helps with TDP meetings regulatory requirements for data protection and privacy across its services. Orchestrator is a solution for labeling, checking assets inside SWaaP. It also allows users to:

• Get a workspace inside SWaaP dedicated to Export Control.
• Track modifications inside this workspace.

Learn more about it

Billing and onboarding

Orchestrator component appears in the Software Factory as a Product (SWaaP).

The access management on Orchestrator is described in the Low Level Design and this guide. Because of Orchestrator is based on others tools from SWaaP, we have a natural integration between Orchestrator and Offer Management on the TDP platforms to covers the biling. The rest of the platforms will have their own onboarding and billing process.

Billing & onboarding on TDP

The onboarding for Orchestrator is managed via the PostIT request for Onboard an Export Control Project .

Billing & onboarding on RTDP

The Orchestrator capability is not valable yet on RDTP.

Billing & onboarding on CASTLE

The Orchestrator capability is not valable yet on CASTLE.

Component Deployment and Configuration

Requirements & Pre-requisite

• All associated ECOL prerequisites are detailed in §4.2 of LLD Orchestrator

Configuration

Setting Helm Values

Orchestrator component is part of SWaaP. For more information, refer to the Getting Started section in the other repository.

Configuring Kubernetes Secrets

For the orchestrator component to function, some secrets need to be recreated with tokens created in the enabled COTS. By default, the component is installed with dummy K8S secrets.

The procedure of replacing the tokens is as follows:

1. Export variables with the following names:

       SPRING_DATASOURCE_USERNAME
       SPRING_DATASOURCE_PASSWORD
   

2. Create DB Secret in K8S:

   kubectl -n orchestrator delete secret orchestrator-database-creds
   kubectl create secret generic orchestrator-database-creds --from-literal=db-user=$SPRING_DATASOURCE_USERNAME --from-literal=db-password=$SPRING_DATASOURCE_PASSWORD --namespace orchestrator
   

3. Create one token for each COTS with admin rights.

4. Export variables with the following names:

       ORCHESTRATOR_GITLAB_API_TOKEN
       ORCHESTRATOR_ARTIFACTORY_API_TOKEN 
       ORCHESTRATOR_SONARQUBE_API_TOKEN 
       (which contain the corresponding tokens created previously)
   

5. Execute the following commands:

       - kubectl -n orchestrator delete secret orchestrator-gitlab-token-secret
       - kubectl -n orchestrator delete secret orchestrator-artifactory-token-secret
       - kubectl -n orchestrator delete secret orchestrator-sonarqube-token-secret
       - kubectl create secret generic orchestrator-gitlab-token-secret --from-literal=gitlab-token=$ORCHESTRATOR_GITLAB_API_TOKEN --namespace orchestrator
       - kubectl create secret generic orchestrator-artifactory-token-secret --from-literal=artifactory-token=$ORCHESTRATOR_ARTIFACTORY_API_TOKEN --namespace orchestrator
       - kubectl create secret generic orchestrator-sonaqube-token-secret --from-literal=sonarqube-token=$ORCHESTRATOR_SONARQUBE_API_TOKEN --namespace orchestrator
       - kubectl -n orchestrator rollout restart $(kubectl get deployments -o name -n orchestrator | grep 'orchestrator-api')
   

Deployment & Update Procedure

The component is deployed as a standard component using Flux and SWaaP packaging.

Orchestrator Prerequisites:

• PostgreSQL DB (>= v15)
• Helm (>= v3)
• K8S Cluster (>= v1.26)

A valid PostgreSQL DB is required for the orchestrator to function. Several values need to be edited (see “Customize Orchestrator” chapter). Install Helm: Install Helm on your local machine. You can download it from the official Helm website, more instructions can be found in the official documentation

Add Helm Repository: Add the helm repository where “orchestrator” chart is located. In this example the orchestrator component is in Artifactory, and to access it a valid Artifactory user/password needs to be provided

helm repo add orchestrator https://artifactory.thalesdigital.io/artifactory/helm-virtual-softwarefactory --username "YOUR_USERNAME" --password "YOUR_PASSWORD"
helm repo update

Install the Orchestrator Helm Chart: Use the helm install command to deploy the chart to your Kubernetes cluster. Replace <release-name> with a name for your release and <namespace> with the desired namespace.

helm install orchestrator-api orchestrator/orchestrator --namespace orchestrator --set env=packaging

Verify the Deployment:

helm status orchestrator -n orchestrator

Uninstall the Helm Release:

Use the following command to uninstall the release.

helm uninstall orchestrator --namespace orchestrator

Verify the Uninstallation: Check to ensure that all resources associated with the release have been removed.

kubectl get all -n orchestrator

Settings

After default installation Orchestrator component can be customized as follows.

Copy default values parameters to a new file (ex. orchestrator-customized.yaml) Make the changes to orchestrator-customized.yaml. Run the command.

helm upgrade --install orchestrator --n orchestrator -f orchestrator-customized.yaml.

Check the status of your deployed Helm releases.

helm status orchestrator -n orchestrator

The helm values that can be customized are the following:

Functional Configuration

N/A

Logging

The logging is defined as follows for the SOC:

• New {sf_workspace_name} export control project was created.
• New GitLab project {project.name} in {sf_workspace_name} export control project.
• {user} user state update {user.state} in GitLab EC project {project.name}.
• {user} user added as {user.state} in GitLab EC project {project.name}.
• {user} user deleted in GitLab EC project {project.name}.
• New repo {repo_key} created in {sf_workspace_name} Artifactory EC project.
• {user} roles update {roles} in Artifactory EC project {repo_key}.
• {user} user added as {roles} in Artifactory EC project {repo_key}.
• {user} user deleted in Artifactory EC project {repo_key}.

More info about logging workflow

The Orchestrator component offers a standard logging policy that can be customized based on specific needs. This policy limits the file size to 10 MB and implements an automatic rolling policy if the size is exceeded.

The Time-To-Live (TTL) for these log files is set to 180 days. However, since the platform storage cannot be controlled, it is the responsibility of the platform to ensure long-term storage policies for specific regulations, such as Export Control.

Monitoring

Spring Boot Actuator is a sub-project of Spring Boot that provides a set of built-in production-ready features to help you monitor and manage your application. Actuator includes several endpoints that allow you to interact with the application, gather metrics, check the health, and perform various management tasks. Spring Boot Actuator provides a variety of built-in endpoints. Below are some of the most commonly used ones:

• /actuator/health: Displays the health status of the application.
• /actuator/info: Displays arbitrary application information.
• /actuator/metrics: Shows ‘metrics’ information for the current application.
• /actuator/env: Displays properties from the Environment.
• /actuator/beans: Displays a complete list of all Spring beans in your application.

For instance, we can check liveness and readiness with /actuator/health endpoint, see image below:

Figure 1 - Response liveness/readiness checking

Business Metrics

For Export Control Compliancy purpose, we store multiple meta-data information and from it we can extract metrics as below :

• Number of Export Control Workspace
• DORA-like metrics: Number of success/failure Export Control Workspace creation