Fichiers de confiance et TLS

Les fichiers de confiance

Ces fichiers decident de qui entre et de ce qu’il peut faire : quiconque peut les ecrire peut se donner l’acces. Le serveur les juge au demarrage, et au rechargement pour ceux qui se rechargent.

Fichier	Juge
le fichier passe a `--config`	demarrage, rechargement
`sftp.host_keys`	demarrage
`auth.users_file`, `auth.methods.local.users_file`, ou `users.toml` adopte	demarrage, rechargement
`auth.roles_file`, ou `roles.toml` adopte	demarrage, rechargement
`auth.jwt.public_key_file`	demarrage
`admin.tls.cert_file`, `admin.tls.key_file`	demarrage, rechargement
`admin.session.key_file`	demarrage
`CRAFT_FILE_GATE_JWT_SECRET_FILE`, `CRAFT_FILE_GATE_ADMIN_BEARER_TOKEN_FILE`	demarrage
`auth.password_file` et `ca_bundle` d’un backend `webhdfs`	construction du backend
`SSL_CERT_FILE`, `SSL_CERT_DIR`, s’ils sont poses	demarrage

Le fichier, et chaque repertoire traverse depuis / pour l’atteindre (liens symboliques compris), est juge sur ses bits de mode, son proprietaire et son groupe. Le serveur lit ensuite le fichier par le descripteur qu’il a juge.

Les poser

Pose	Verdict
appartient a root, ecrit par son seul proprietaire, repertoires de meme	accepte sans un mot
appartient a l’uid du serveur, ecrit par lui seul	accepte, dit au demarrage
sur un montage en lecture seule (Secret ou ConfigMap Kubernetes, volume `:ro`)	accepte ; les repertoires ne sont pas juges
`/`, `/tmp` (root, bit sticky) sur le chemin	accepte

La pose recommandee :

chown root:root /etc/craft-file-gate /etc/craft-file-gate/*
chmod 755 /etc/craft-file-gate
chmod 644 /etc/craft-file-gate/config.toml /etc/craft-file-gate/roles.toml
chmod 640 /etc/craft-file-gate/users.toml /etc/craft-file-gate/host_ed25519
chgrp craft-file-gate /etc/craft-file-gate/users.toml /etc/craft-file-gate/host_ed25519

En conteneur, montez la configuration en lecture seule (readOnly: true, :ro): un Secret Kubernetes en 0440 avec le fsGroup du pod convient tel quel.

`[security]`

Toutes les cles : Reference [security].

Lue au demarrage. A reserver a un deploiement ou le groupe du serveur ne contient que lui.

Ce que le serveur cree lui-meme

Le processus pose umask(077) au demarrage.

Cree par le serveur	Mode
cle d’hote generee, cle TLS admin generee	`0600` (certificat genere : `0644`)
repertoire d’une cle generee, fichier de bans, fichiers temporaires	`0700` / `0600`
fichiers deposes par les clients, repertoires d’accueil (backend local)	`0666` / `0777` masques par l’`umask` herite du lancement
fichiers de log et d’audit	`0640` masque par l’`umask` herite

Les instances qui partagent un volume de bans tournent sous le meme uid.

Les chemins des clients

Un chemin client est juge sur sa forme virtuelle, puis le backend le resout sous sa racine. Sur un backend local, un lien symbolique ne sort jamais de la racine : voir Local.

Racines de confiance TLS

Il s’agit du TLS sortant : backend S3 en HTTPS, jwks_url, service d’autorisation, collecteur OTLP en https://, backend WebHDFS. Le TLS entrant de la console se regle dans [admin.tls] (voir Console et API).

Le serveur n’embarque aucune racine : il lit le magasin du systeme.

Variable	Contenu
`SSL_CERT_FILE`	un fichier PEM, un nombre quelconque de certificats
`SSL_CERT_DIR`	des repertoires, separes par `:`

Posee, l’une de ces variables remplace le magasin du systeme, elle ne s’y ajoute pas. Pour faire confiance a une autorite interne et aux racines publiques, concatenez :

cat /etc/ssl/certs/ca-certificates.crt ca-interne.pem > bundle.pem

Sans variable, le premier fichier trouve parmi les chemins usuels l’emporte (/etc/ssl/certs/ca-certificates.crt, /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, /etc/pki/tls/certs/ca-bundle.crt, /etc/ssl/ca-bundle.pem, /etc/ssl/cert.pem), puis les repertoires /etc/ssl/certs et /etc/pki/tls/certs. Les images :latest et :alpine portent un magasin ; l’image :scratch n’en a pas.

Monter un jeu de racines

Le bundle Mozilla que maintient le projet curl convient :

curl -fsSLo bundle.pem https://curl.se/ca/cacert.pem

Montez-le au chemin par defaut (/etc/ssl/certs/ca-certificates.crt, en lecture seule), ou n’importe ou avec SSL_CERT_FILE ; en Kubernetes, un ConfigMap suffit, ce n’est pas un secret.

Un deploiement sans connexion TLS sortante (backend local ou proxy SFTP, comptes locaux ou cle JWT statique, pas d’OTLP) n’a besoin d’aucune racine.

Recommandations de deploiement

Sujet	Recommandation
fichiers de confiance	en lecture seule, a root ; un Secret ou un ConfigMap monte `readOnly: true`
secrets	les formes `_FILE` plutot que les variables, lisibles dans `/proc/<pid>/environ`
uid	un uid dedie par instance, `NoNewPrivileges=yes`, un filtre seccomp (`SystemCallFilter=@system-service`, `seccompProfile: RuntimeDefault`)
pod	le chart Helm applique le profil restricted : voir Kubernetes
port d’administration	`control_listen` sur une interface interne ; en conteneur, derriere une NetworkPolicy (le chart Helm en pose une, et un Service `ClusterIP` a part)
description OpenAPI	`[api] openapi`, eteinte par defaut : sans authentification, elle decrit toute l’API
TLS de la console	`[admin.tls]`, certificat fourni ou genere
force brute	les trois listes de bans et les deux limiteurs (voir Bans)
piste d’audit	exportee en entier hors de l’hote ; les refus d’authentification sont en `INFO`, un filtre `WARN` les perd
JWT	rotation reguliere des cles de signature ; `issuer` et `audience` poses

Keyboard shortcuts

CraftFileGate