HCL Commerce utilisateurs et privilèges liés aux conteneurs

Les autorisations de fichiers étant liées aux utilisateurs et aux groupes, tout code de personnalisation manipulant des fichiers doit être évalué afin de garantir que tout fichier manipulé dispose bien des autorisations appropriées pour l'utilisateur et le groupe comuser.

Par exemple, si un code de personnalisation crée des fichiers temporaires dans le répertoire de base de l'utilisateur root (/root/) ou dans tout répertoire du système d'exploitation appartenant à l'utilisateur root, un déploiement mis à jour n'aura plus accès à ces fichiers. Le cas échéant, votre code personnalisé devra être mis à jour afin de créer des fichiers temporaires dans le répertoire /tmp/, ou de telle sorte que ces fichiers soient créés et mis à jour dans le répertoire de base du comuser, à savoir /home/comuser/. Assurez-vous que toutes les autorisations de fichiers sont mises à jour de manière appropriée.

Le code de personnalisation est normalement empaqueté par l'utilitaire WCB aux fins du déploiement. Si l'utilitaire WCB est exécuté dans le conteneur ts-utils, les autorisations de fichiers pour le code de personnalisation sont également importantes dans la mesure où le conteneur ts-utils est également exécuté en tant qu'utilisateur comuser non root. Assurez-vous que le code de personnalisation qui est monté ou copié vers le conteneur ts-utils est accessible à l'utilisateur et au groupe comuser pour éviter tout problème.

Lorsqu'une image Docker personnalisée est générée par-dessus une image HCL Commerce, gardez à l'esprit que le contexte utilisateur actuel est comuser et non root.

Cette modification affecte principalement les instructions RUN dans votre Dockerfile. Par exemple, si vous installez un package logiciel supplémentaire à l'aide du gestionnaire de packages système, ces commandes échoueront à moins que vous ne mettiez à jour le Dockerfile et n'utilisiez l'instruction USER pour définir d'abord l'utilisateur sur root.

Tip: Du fait de la mise à jour de CentOS vers UBI dans la même version, le gestionnaire de packages yum a été remplacé par dnf. Si vous installez ou modifiez les packages dans vos conteneurs personnalisés, veillez à bien mettre à jour votre Dockerfile pour qu'il tienne compte de cette modification.

Au même titre que les problèmes d'autorisation lors de l'émission de commandes système, gardez à l'esprit les autorisations de fichiers lorsque vous utilisez les commandes COPY ou ADD. Par exemple,

COPY --chown=comuser:comuser ./my-custom-script /SETUP/bin/

Dans tous ces cas, n'oubliez pas de rebasculer le contexte utilisateur sur comuser après vos instructions privilégiées.

Les images basées sur le serveur Web étant désormais exécutées par un utilisateur non root, aucun port privilégié (1024 et inférieur) ne peut être utilisé.

Si vous avez personnalisé la configuration ou le plug-in IBM HTTP Server de telle sorte d'utiliser des ports privilégiés, tels que les ports 80 ou 443, vous devez mettre à jour votre fichier de configuration de manière à utiliser à la place un port non privilégié.

Si vous utilisez un pipeline CI/CD, vous devez passer en revue vos outils et scripts afin de vous assurer que tous les fichiers ajoutés à vos images personnalisées le sont avec la propriété et les autorisations de fichiers appropriées conformément aux instructions fournies.

HCL Commerce fournit des utilitaires pour la mise à jour et la maintenance de votre site de commerce électronique, empaquetés dans le conteneur ts-utils. Certains utilitaires, tels que dataload, nécessitent des fichiers de configuration et de données supplémentaires pour s'exécuter. Lorsque ces fichiers sont copiés ou montés dans le conteneur ts-utils, assurez-vous qu'ils disposent de la propriété et des autorisations de fichiers appropriées conformément aux instructions fournies.

Dans les déploiements Docker, un volume hôte monté dans un conteneur exécuté par Docker voit ses autorisations de fichiers préservées. Assurez-vous que tous les répertoires montés et tous les fichiers contenus disposent des autorisations appropriées afin de pouvoir y accéder et les manipuler dans le conteneur. Si vous utilisez le projet Docker Compose fourni pour votre environnement, cet aspect est déjà pris en considération.

Dans les déploiements Kubernetes, un PVC est utilisé pour conserver les fichiers utilisés par l'outil Assets dans Management Center for HCL Commerce. La mise à niveau vers un conteneur d'utilisateur non root présente un problème potentiel en fonction du type de PVC initialement provisionné :

• Un stockage ayant pour mode d'accès readWriteOnce ne présente aucun problème lors de cette mise à niveau.

  Généralement, le stockage PVC est provisionné par la classe de stockage cloud en tant que PVC à mode d'accès readWriteOnce et est monté avec l'utilisateur root comme propriétaire. Le fsGroup est défini sur 1000 dans le chart Helm HCL Commerce, garantissant que l'utilisateur non root conservera toujours un accès complet en lecture et en écriture à tous les fichiers et répertoires préexistants dans le volume monté.

• Un stockage ayant pour mode d'accès readWriteMany présente une exigence de mise à jour des autorisations lors de cette mise à niveau.

  Un type de PVC readWriteMany, qui peut être provisionné par un autre fournisseur, tel que NFS Provisioner, présente un obstacle avec les autorisations utilisateur lors de cette mise à niveau. Dans ce cas, le fsGroup spécifié dans le chart Helm HCL Commerce n'aura aucune influence sur les fichiers existants dans le volume. Ainsi, les autorisations de fichiers au sein de votre PVC doivent être modifiées de manière à ce qu'elles restent accessibles par l'utilisateur non root.

  Pour mettre à jour vos autorisations de fichiers PVC readWriteMany, consultez Mise à jour des autorisations de fichiers PVC.