Administration Guides
Utilisateurs par défaut
La registry est configuré avec les utilisateurs initiaux suivants :
atheaadmin: Administrateur de la registry avec l'ensemble des permissions sur l'ensemble des cheminskosmosuser: Un utilisateur qui peut lire, pousser ou mettre à jour des images, mais pas en supprimerkosmospull: Un simple utilisateur en lecture seule
Création d'un utilisateur
Pour ajouter des utilisateurs, il faut modifier la clef htpasswd du secret kubernetes nommé zot-htpasswd-secret en y ajoutant votre utilisateur sur une nouvelle ligne.
Afin de créer cette ligne, vous devrez utiliser le binaire htpasswd de cette manière :
# Quand demandé, fournissez votre mot de passe puis vérifiez le
htpasswd -BnC 10 [username]
# Exemple de résultat
[username]:$2y$10$sUqgphW8AarFqcsVjvyCOuvcA0X6IiBQXrvNwR1wyt9Mt7m2/NqO6
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: zot-htpasswd-secret
namespace: kosmos-dev-restricted
stringData:
htpasswd: |
user1:$2a$10$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
user2:$2a$10$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
user3:$2a$10$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mynewuser:$2y$10$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[...]
Si vous souhaitez pouvoir utiliser ces credentials dans d'autres applications ou un déploiement Helm il est conseillé de créer aussi un secret qui contiendra votre nom d'utilisateur et mot de passe.
Configuration du contrôle d'accès
Afin de configurer le contrôle d'accès il faudra modifier la clef config.json dans la configmap nommée kosmos-registry-config.
Dans ce fichier json vous devrez modifier le contenu du champ .http.accessControl.repositories.
A chaque patch de zot la configmap kosmos-registry-config est écrasée. Pour persister les modifications la fonctionnalité de values-custom de l'installation via le platform-provisioner peut être utilisée.
Pour cela localiser le répertoire qui contient les values-custom. Sa valeur est :
- soit
KOSMOS_VALUES_CUSTOM_PATHsi cette variable d'environnement est définie - soit la valeur de la propriété
valuesCustomPathdans le fichierenvironments/$ENV.yamlou par défautenvironments/default.yaml
Dans la suite on considère que sa valeur est $KOSMOS_VALUES_CUSTOM_PATH
Dans ce répertoire, s'il n'est pas déjà présent :
- créer le fichier
$KOSMOS_VALUES_CUSTOM_PATH/zot/values.yaml - initialiser ce fichier avec la valeur de
configFiles.config.jsondu fichierplatform-provisioner/values/zot/values.yaml
Editer ensuite le fichier $KOSMOS_VALUES_CUSTOM_PATH/zot/values.yaml conformément aux explications ci-dessous sur la gestion des droits d'accès de zot.
Une fois terminé, déployer les modifications avec la commande helmfile -e $ENV -l name=zot-registry sync
Cette partie du fichier de configuration vous permet de :
- Décrire un 'repository' à l'aide d'un 'motif glob' (similaire au principe des expressions régulières). Toute image dont le nom complet valide ce motif sera impacté par la configuration qui suit.
- ec:
athea/test/**validera toutes les images dont le nom commence parathea/test/
- ec:
- Donner une liste de règles, chacune ayant comme configuration :
- Une liste d'utilisateurs (
users) et/ou de groupes (groups) concernés - Une liste d'
actionsautorisés :read: droit de lecturecreate: droit de pousser des imagesupdate: droit de mettre à jour une image existantedelete: droit de supprimer une image existante
- Une liste d'utilisateurs (
N'oubliez pas de donner accès dans votre nouvelle zone à l'utilisateur Kosmospull qui sera utilisé par le cluster kubernetes pour récupérer vos images.
Une fois terminé, redémarrez le serveur afin que la configuration soit appliquée.
- Le contrôle d'accès est basé sur la règle la plus spécifique. Les différentes règles ne sont pas fusionnées.
- Si une règle pour
athea/test/**&athea/test/foo/**existent, l'imageathea/test/foo/bar/image:tagne se verra concerné que par celles définies dans le bloc de préfixeathea/test/foo/**. - Vous devrez ainsi redéfinir certaine règles plusieurs fois dans vos configuration dans certains cas (cas de l'exemple ci-dessous pour l'utilisateur
kosmospull)
- Si une règle pour
- L'action
readest une action qu'i lest obligatoire d'avoir pour utiliser les actionscreate,update&delete. Avoir une des dernières sans la première est une configuration incorrecte.
Exemple
Considérons la configuration initiale suivante :
{
"http": {
"auth": {
"htpasswd": {
"path": "/secrets/htpasswd/htpasswd"
}
},
"accessControl": {
"repositories": {
"**": {
"policies": [
{
"users": [
"kosmospull"
],
"actions": [
"read"
]
},
{
"users": [
"kosmosuser"
],
"actions": [
"read",
"create"
]
}
],
"defaultPolicy": []
}
},
"adminPolicy": {
"users": [
"atheaadmin"
],
"actions": [
"read",
"create",
"update",
"delete"
]
}
},
[...]
},
[...]
}
Si nous voulons que notre nouvel utilisateur mynewuser créé durant l'étape précédente et lui donner accès au préfixe athea/test/** avec des droits élevé et au reste de la registry uniquement en lecture, nous utiliserons la configuration suivante :
{
"http": {
"auth": {
"htpasswd": {
"path": "/secrets/htpasswd/htpasswd"
}
},
"accessControl": {
"repositories": {
"**": {
"policies": [
{
"users": [
"kosmospull",
"mynewuser"
],
"actions": [
"read"
]
},
{
"users": [
"kosmosuser"
],
"actions": [
"read",
"create"
]
}
],
"defaultPolicy": []
},
"athea/test/**": {
"policies": [
{
"users": [
"kosmospull"
],
"actions": [
"read"
]
},
{
"users": [
"mynewuser"
],
"actions": [
"read",
"create",
"delete"
]
}
],
"defaultPolicy": []
},
},
"adminPolicy": {
"users": [
"atheaadmin"
],
"actions": [
"read",
"create",
"update",
"delete"
]
}
},
[...]
},
[...]
}
Comme zot effectue son contrôle d'accès basé sur la règle la plus spécifique, nous avons défini une règle pour l'utilisateur kosmospull qui semble être un doublon de celle pour le préfixe ** qui devrait servir de joker et correspondre à l'ensemble de la registry.
Mais sans cela, kosmospull serait incapable d'accéder aux images préfixées par athea/test/**.
Mise à jour de l'image Zot
La réinstallation de Zot (helmfile sync) supprime le pod Zot courant et tente de relancer un pod Zot qui de fait ne pourra rechercher l'image de Zot que dans la Registry embarquée de Kubernetes (et non le ZOT OCI Registry). La Registry embarquée de Kubernetes (rke2) contient la version de l'image Zot présente à l'initialisation de la plateforme (kube-provisioner). Si la mise à jour de Zot ammène une nouvelle image Zot, il convient donc qu'elle soit injectée manuellement dans cette Registry embarquée.
Pour cela, lancer les commandes suivantes :
- en mettant la bonne version de l'image zot à importer pour la variable
zot_image - en mettant
node_networkà.admin.artemissi ce réseau existe sur la plateforme mise à jour
node_network=""
zot_image="project-zot/zot:vX.Y.Z"
zot_username=$(kubectl -n kosmos-dev-restricted get secret zot-admin-secret -o jsonpath='{.data.username}' | base64 -d )
zot_password=$(kubectl -n kosmos-dev-restricted get secret zot-admin-secret -o jsonpath='{.data.password}' | base64 -d )
sudo podman login -u "${zot_username}" -p "${zot_password}" https://kosmos-registry.${KOSMOS_DOMAIN}/v2/
sudo podman pull kosmos-registry.${KOSMOS_DOMAIN}/athea/${zot_image}
sudo podman tag kosmos-registry.${KOSMOS_DOMAIN}/athea/${zot_image} ghcr.io/${zot_image}
sudo podman save ghcr.io/${zot_image} > /data/release-zot.tar
sudo zstd --rm -4 -f /data/release-zot.tar
node=$(kubectl get node | grep master | awk '{print $1}' | head -1)
ssh ${node}${node_network} "sudo mv /var/lib/rancher/rke2/agent/images/release-zot.tar.zst /var/lib/rancher/rke2/agent/images/release-zot.tar.zst.old"
scp /data/release-zot.tar.zst ${node}${node_network}:/tmp
ssh ${node}${node_network} "sudo cp -a /tmp/release-zot.tar.zst /var/lib/rancher/rke2/agent/images/"