Closed revolunet closed 1 year ago
Les images nginx tournent en root/port 80;
Il faut les modifier conjointement à la définition du service kube et du containerPort
WIP
Les images nginx et nginx4spa ont été corrigée, le fix à appliquer sur les produits est le suivant : https://github.com/SocialGouv/www/pull/930/files
J'ai du ajouter un config.containerPort
dans notre template autodevops pour pouvoir controller le port et ne pas risquer d'impacter l'existant. actuellement on utilise 80 implicitement via un component kosko-charts;
concernant l'image hasura, pour pouvoir la passer en rootless, il faudra investiguer, pour tracer, voici quelque tickets pour aider
https://github.com/hasura/graphql-engine/pull/5697 https://github.com/hasura/graphql-engine/issues/3824 https://github.com/hasura/graphql-engine/issues/4651
finalement, sur la dernière version il suffit d'ajouter USER 1001
à la fin du Dockerfile
concernant hasura voici un exemple d'implémentation dans eMJPM https://github.com/SocialGouv/emjpm/blob/master/packages/hasura/Dockerfile les lignes concernées sont:
il faut au minimum une v2.1
FROM hasura/graphql-engine:v2.1.1.cli-migrations-v3
seul root peut allouer des ports inférieurs à 1024 (pour hasura c'est le 80 par défaut)
ENV HASURA_GRAPHQL_SERVER_PORT=8080
et prendre garde à ne pas l'overrider pendant le deployment.
C'est la ligne essentielle :)
USER 1001
Et, petite astuce sympa, pour migrer d'une hasura v1 vers v2 sans tout casser il faut également rajouter:
ENV HASURA_GRAPHQL_V1_BOOLEAN_NULL_COLLAPSE=true
carnet-de-bord-ci restore-db-1646147185491-vh8k6
cdtn-admin-270-dependabot-npm-an-g3u43z drop-azure-db-043c4c14-qrcrs
cdtn-admin-270-dependabot-npm-an-h93qat drop-azure-db-ef680bb3-5h28w
cdtn-admin-secret backup-db-cdtn-admin-1646625600-hwr6x
mon-psy-sante-preprod import-data-1646671200-99458
mon-psy-sante-preprod import-data-1646671500-2wdwk
mon-psy-sante-preprod import-data-1646671800-tfnfw
mon-psy-sante-preprod import-data-1646672100-w4b9s
mon-psy-sante-preprod import-data-1646672400-ctdwh
secretariat-helm-deploy hasura-69c675d59-jxf9k
PSP: https://kubernetes.io/docs/concepts/security/pod-security-policy/
manifests à appliquer: https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/policy/privileged-psp.yaml https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/policy/baseline-psp.yaml https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/policy/restricted-psp.yaml
approche à utiliser pour l'implémentation du serviceAccount: https://support.cloudbees.com/hc/en-us/articles/360034591531-How-to-use-Kubernetes-Pod-Security-Policies-with-CloudBees-CI-CloudBees-Core-on-Modern-Cloud-Platforms
donc focus sur rootless containers pour l'instant
Pour lister les users de tous les pods :
kubectl get pod --all-namespaces --no-headers --field-selector=status.phase=Running | xargs -L 1 bash -c 'echo $0 $1 $(kubectl exec -n $0 $1 -- id)' | column -t > pod_users.txt
(édité)
xargs: illegal option -- l
Pour les images Strapi : https://github.com/SocialGouv/1000jours/pull/1281 Doit encore être testé un peu
Le cas de Hasura était un spécifique : le user 1001 existe déjà sur leur image, c'est hasura
dans le group hasura
. Dans d'autres cas, comme Strapi, si on utilise simplement USER 1001
sans le créer avant, on peut se retrouver avec un user 1001
dans le groupe root
. Pour éviter ça, on créer manuellement le user ; le groupe du même nom est créé automatiquement.
Exemples :
Relevé des images à traiter (prod) :
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Mark it with help wanted
label if don't want it to be considered stale. Thank you for your contributions.
USER
en numériqueex :
USER 1000
dans le Dockerfile