REX: CRC déployé sur Debian + déploiement de Trivy |

Contenu

Mon setup

Prérequis du hardware par Redhat

4 virtual CPUs (vCPUs)
8 GB de mémoire
35 GB d’espace de stockage

Config de mon Serveur Bare-metal

Debian 12/bookworm
16 GB de RAM
8 CPUs

Version CRC

CRC version: 2.12.0+74565a6
OpenShift version: 4.11.18
Podman version: 4.2.0

Un peu de Blabla

CRC

Red Hat CodeReady Containers apporte un cluster Openshift (en version 4.1 ou plus) minimal préconfiguré sur votre serveur ou ordinateur de bureau, tant que ce dernier a les capacités nécessaires pour accueillir ce cluster. Pour ma part, les prérequis matériels qu’a annoncé RedHat a suffit pour l’installation de CRC seulement, par contre ca a commencé à être gourmand lorsque j’ai voulu installé d’autres outils derrière. Pour ce REX, je vais utiliser une application légère.

Le but de ce REX

Déployer un cluster Openshift ou OKD afin de pour pouvoir tester les conteneurs qu’on déploierait dessus, là en l’occurence ca sera un opérateur Trivy + un POD Nginx.
D’avoir déployé sur un Debian pourrait permettre à ceux qui voudraient se lancer, d’éviter d’éventuels problématiques que j’ai pu rencontrer.

RedHat préconise d’utiliser une distribution RedHat ou RedHat-like, style CentOS ou Rocky Linux par exemple. Étant plutôt Debian, j’ai quand même voulu tenter le déploiement sur ma distrib de tous les jours 😄

Liens utiles

Voici le github de CRC: https://github.com/crc-org/crc
La documentation: https://crc.dev/crc/#introducing_gsg

Déploiement

Prérequis

Vérifier que sur le serveur sur lequel vous déployer, le port 80 et 443 ne sont pas déjà écoutés par une autre application style Nginx, Apache2, HAProxy etc..
J’ai commencé à installer les paquets nécessaires au déploiement de CRC

1
2


sudo apt install qemu-kvm libvirt-daemon libvirt-daemon-system systemd-resolved
sudo usermod -aG libvirt-qemu <youruser>

On utilise donc l’hyperviseur qemu-kvm qui nous permet de déployer des VMs

Avoir un compte RedHat et se connecter dessus.
Téléchargement du binaire CRC depuis le site redhat.com https://developers.redhat.com/products/openshift-local/overview. Il faut cliquer sur “Install Openshift on your laptop” et ensuite choisir l’OS Linux, puis cliquer sur Download Openshift Local. Extraire l’archive puis copier le binaire crc dans votre /usr/local/bin (vérifier que ce chemin est présent dans votre $PATH)
Téléchargement du pull secret

Config, démarrage et debug de CRC, 2 façons:

Config et démarrage classique:

1
2
3
4
5
6
7


crc config set network-mode user
crc setup
crc start -c 8 -m 12000 -p pull-secret --log-level debug
crc status
crc ip
oc login -u kubeadmin -p <password> https://api.crc.testing:6443
oc projects

Config, démarrage et Debug depuis la VM déployée:

Remarque

Normalement, il n’est pas nécessaire de se connecter sur notre VM mais si besoin, nous pouvons le faire pour diagnostiquer et debugguer plus en détail.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


crc config set network-mode user
crc setup
crc start -c 8 -m 12000 -p pull-secret --log-level debug
crc status
crc ip
ssh -i ~/.crc/machines/crc/id_ecdsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null  core@192.168.130.11
crc console --credentials
oc login -u kubeadmin -p <password> https://api.crc.testing:6443
oc projects
oc get pods -A
oc get co
crictl ps

Explication des commandes:

crc config set network-mode user: j’utilise le mode user comme mode de réseau CRC, ce qui me permet d’utiliser l’ip 127.0.0.1 au lieu d’avoir l’ip fixée par défaut par CRC (qui est 192.168.130.11). Autrement ça ne fonctionnait pas de mon côté, je n’ai pas pu creuser le pourquoi du comment, ça jouait peut-être avec mes règles iptables, mais pas sûr…
crc setup: j’initialise mon cluster
crc start -c 8 -m 12000 -p pull-secret –log-level debug: je démarre ma machine virtuelle
- -c 8 -m 12000: je demande 8 vCPUs et 12 GB de RAM à attribuer sur la machine virtuelle qui va être lancée
- -p pull-secret: Je lui précise le fichier pull-secret à prendre en compte car pour pouvoir lancer CRC, il avoir un user Openshift valide et le renseigner
- –log-level debug: je demande un niveau de log de sortie en mode debug. Attention, c’est très verbeux, et il ne faut pas prendre en compte toutes les “erreurs” qu’on aperçoit, car souvent ça concerne le temps d’attendre (timeout) que l’étape en question se finisse.
  Si notre commande crc start se termine avec succès, nous pouvons voir le lien de notre interface Openshift. Nous voyons également les identifiants pour se connecter à notre API Openshift via la commande oc ou kubectl.
crc status: On vérifie le statut de notre cluster

1
2
3
4
5
6
7


openshift@sv1-12:20>~ $ crc status
CRC VM:          Running
OpenShift:       Running (v4.11.18)
RAM Usage:       7.549GB of 12.27GB
Disk Usage:      15.48GB of 32.74GB (Inside the CRC VM)
Cache Usage:     16.18GB
Cache Directory: /home/openshift/.crc/cache

crc console –credentials: cette commande nous indique comment se connecter à notre cluster via la command-line OC avec deux types d’utilisateur (kubeadmin ou developer)

1
2
3


openshift@sv1-12:24>~ $ crc console --credentials
To login as a regular user, run 'oc login -u developer -p developer https://api.crc.testing:6443'.
To login as an admin, run 'oc login -u kubeadmin -p gX9Ps-2auUQ-RFD4t-wxwi2 https://api.crc.testing:6443'

oc login -u kubeadmin -p https://api.crc.testing:6443: on se connecte à notre cluster via l’utilisateur kubeadmin

1
2
3
4
5
6


openshift@sv1-12:24>~ $ oc login -u kubeadmin -p gX9Ps-2auUQ-RFD4t-wxwi2 https://api.crc.testing:6443
Login successful.

You have access to 67 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "default".

oc projects: on liste les projets créés par défaut

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72


openshift@sv1-10:30>~ $ oc projects
You have access to the following projects and can switch between them with 'oc project <projectname>':

  * default
    hostpath-provisioner
    kube-node-lease
    kube-public
    kube-system
    openshift
    openshift-apiserver
    openshift-apiserver-operator
    openshift-authentication
    openshift-authentication-operator
    openshift-cloud-controller-manager
    openshift-cloud-controller-manager-operator
    openshift-cloud-credential-operator
    openshift-cloud-network-config-controller
    openshift-cluster-csi-drivers
    openshift-cluster-machine-approver
    openshift-cluster-node-tuning-operator
    openshift-cluster-samples-operator
    openshift-cluster-storage-operator
    openshift-cluster-version
    openshift-config
    openshift-config-managed
    openshift-config-operator
    openshift-console
    openshift-console-operator
    openshift-console-user-settings
    openshift-controller-manager
    openshift-controller-manager-operator
    openshift-dns
    openshift-dns-operator
    openshift-etcd
    openshift-etcd-operator
    openshift-host-network
    openshift-image-registry
    openshift-infra
    openshift-ingress
    openshift-ingress-canary
    openshift-ingress-operator
    openshift-insights
    openshift-kni-infra
    openshift-kube-apiserver
    openshift-kube-apiserver-operator
    openshift-kube-controller-manager
    openshift-kube-controller-manager-operator
    openshift-kube-scheduler
    openshift-kube-scheduler-operator
    openshift-kube-storage-version-migrator-operator
    openshift-machine-api
    openshift-machine-config-operator
    openshift-marketplace
    openshift-monitoring
    openshift-multus
    openshift-network-diagnostics
    openshift-network-operator
    openshift-node
    openshift-nutanix-infra
    openshift-oauth-apiserver
    openshift-openstack-infra
    openshift-operator-lifecycle-manager
    openshift-operators
    openshift-ovirt-infra
    openshift-route-controller-manager
    openshift-sdn
    openshift-service-ca
    openshift-service-ca-operator
    openshift-user-workload-monitoring
    openshift-vsphere-infra

Using project "default" on server "https://api.crc.testing:6443".

debug dans la VM:

Utiliser la console Openshift en GUI

Redirection

Lorsqu’on déploie CRC, nous pouvons remarquer que notre machine écoute désormais sur les ports 80, 443 et 6443. Vu que le DNS préconfiguré de notre cluster Openshift n’est pas déclaré publiquement, pour accéder à la console en mode GUI je dois modifier le fichier /etc/hosts de mon PC local pour rediriger notre demande de requête DNS vers ma machine distante, je renseigne donc l’IP publique de cette dernière.

1
2


vim /etc/hosts
<ip-publique> console-openshift-console.apps-crc.testing oauth-openshift.apps-crc.testing

Dans ce cas là, je renseigne l’IP publique en question car ma machine est distante, mais ça aurait pu être l’IP privée de celle-ci si j’avais essayé d’accéder à cette console depuis une autre machine du même réseau.

Accès et déploiement d’un opérateur

J’accède à ma console via mon navigateur en utilisant cet URL https://console-openshift-console.apps-crc.testing, ce qui me redirigera vers la deuxième URL d’authentification que j’ai renseigné dans mon /etc/hosts, et j’utilise mes identifiants d’admin:
Voici la page d’accueil lorsqu’on vient de se connecter:
Je clique sur OperatorHub dans le menu à gauche, je cherche Trivy comme opérateur à installer et je l’installe:
Une fois installé, je peux vérifier dans Installed Operators et je clique sur mon composant pour avoir plus de détails:

Utilisation de Trivy

Trivy est un logiciel OpenSource qui scanne des OS ou des configurations IaC (Infrastructure-as-Code) et détecte leurs potentiels vulnérabilités. Le fonctionnement est relativement simple, il suffit d’indiquer à Trivy le type d’éléments à scanner, dans mon cas ce sera une image Docker que je vais déployer via une définition yaml.

Je me suis basé sur ce tutoriel: https://www.programmersought.com/article/429010837103/
Vu que mon Trivy est installé via la GUI, je passe direct à l’exposition de mon service Trivy:

1
2


openshift@sv1-11:11>~ $ oc expose svc trivy-operator -n openshift-operators
route "trivy-operator" exposed

Je stocke ensuite ma route dans une variable TRIVY_ADDR:

1
2
3
4


openshift@sv1-11:13>~ $ TRIVY_ADDR=$(oc get route trivy-operator -o jsonpath='{.spec.host}' -n openshift-operators)

openshift@sv1-11:13>~ $ echo $TRIVY_ADDR
trivy-operator-openshift-operators.apps-crc.testing

Je déploie le yaml proposé:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


apiVersion: v1
kind: Namespace
metadata:
  labels:
    trivy-scan: "true"
    trivy-operator-validation: "false"
  name: trivytest
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: trivytest
spec:
  initContainers:
  - name: init
    image: nginxinc/nginx-unprivileged:latest
    command: ['sh', '-c', 'echo The app is running! && sleep 10']
  containers:
  - image: nginx:1.18
    imagePullPolicy: IfNotPresent
    name: nginx

1
2
3


openshift@sv1-11:24>~ $ oc apply -f trivy-test.yaml 
namespace "trivytest" created
pod "nginx" created

ce qui se passe:
- Je crée un Namespace nommé trivytest
- Je crée un Pod avec une image nginx en version 1.18 (qui est donc une ancienne version et du coup idéal pour faire apparaître des vulnérabilités sur mon rapport de scan Trivy)
Vérification:

1
2
3
4
5
6
7


openshift@sv1-12:19>~ $ oc projects | grep trivy
    trivytest
openshift@sv1-12:19>~ $ oc project trivytest
Now using project "trivytest" on server "https://api.crc.testing:6443".
openshift@sv1-12:19>~ $ oc get pods
NAME      READY     STATUS    RESTARTS   AGE
nginx     1/1       Running   0          54m

Mon namespace et mon POD sont bien créés

Je peux maintenant atteindre ma route et compter le nombre de vulnérabilités total ou par catégorie: LOW, HIGH, CRITICAL

1
2
3
4
5
6
7
8


openshift@sv1-12:13>~ $ curl -s ${TRIVY_ADDR}/metrics | grep LOW | wc -l
312
openshift@sv1-12:14>~ $ curl -s ${TRIVY_ADDR}/metrics | grep HIGH | wc -l
224
openshift@sv1-12:14>~ $ curl -s ${TRIVY_ADDR}/metrics | grep CRITICAL | wc -l
129
openshift@sv1-12:14>~ $ curl -s ${TRIVY_ADDR}/metrics | grep -E 'LOW|HIGH|CRITICAL' | wc -l
665

Fin

Pour finir, si on en revient à notre cluster CRC, en refaisant un crc status je peux apercevoir la RAM et l’espace disque qui ont augmenté du à notre déploiement:

1
2
3
4
5
6
7


openshift@sv1-12:20>~ $ crc status
CRC VM:          Running
OpenShift:       Running (v4.11.18)
RAM Usage:       9.437GB of 12.27GB
Disk Usage:      18.79GB of 32.74GB (Inside the CRC VM)
Cache Usage:     16.18GB
Cache Directory: /home/openshift/.crc/cache