Dans le cadre du renforcement de la sécurité de nos services, je souhaite pouvoir désactiver le compilateur java interne. J’ai trouvé que je pouvais le désactiver en basculant la propriété système server.compiler à false mais ce faisant, mon application ne démarre pas bien car les sources java ne sont plus compilés au démarrage (logique) et que je ne souhaite pas avoir à les ajouter dans une image statique. Je souhaite juste que le service une fois démarré ne permette pas de modifier et recompiler le code mais que la dernière version disponible du code lue en BD soit bien prise en compte à chaque démarrage.
J’essaye aussi de bénéficier de la propriété platform.securelevel=9. Cependant, ce niveau de sécurité inhibe totalement le healthCheck de telle sorte que les services ne sont jamais considérés comme démarrés dans Kubernetes. Ce niveau de sécurité devrait réponde a minima un statut http200(fusse avec un contenu renvoyé vide) ou au moins renvoyer la réponse prévue dans le platformHook customHealthCheck.
La logique quand on inhibe le compilateur (ce qui va, d’ailleurs, de pair avec un utilisation d’une image Docker basée sur un JRE et pas un JDK) c’est de livrer son code précompilé sous forme d’un JAR (tel qu’obtenu via un mvn package) importé dans un shared code.
Ce build est donc à intégrer à un processus “CI/CD”. On doit pouvoir réfléchir à un moyen de rendre ça un peu plus fluide (ex: via importspec, création automatique du shared code sur import du module si le JAR est présent dans target ou dans le genre)
PS: on sait d’expérience que le point sur les headers HTTP arrive aussi rapidement quand on parle de “durcir” l’application et/ou que des tests sont faits via les outils de pentest usuels du marché.
Oui, je suis en train de décortiquer cette documentation
Notamment, j’explore comment tirer partie au maximum de l’option “max secure level” qui ferme au maximum par défaut (me côté feignant est très attiré par cette solution).
Le seul problème que je vois dans cette option est le fait que le health check soit totalement inhibé, empêchant le bon déploiement des services portant cette option sur notre cluster kubernetes (la réponse OK/200 étant un pré-requis du bon déploiement du service).
D’où cette question précise : est-il envisageable que le “max secure level” ne ferme pas ce flux (quitte à le minimiser en ne répondant rien d’autre que le statut HTTP 200).
En fait le “secure level” est un mécanisme resté en gestation car il avait été avait été demandé par un client mais mais n’a jamais fait l’objet d’une expression de besoin précise. A date on a donc mis en place uniquement une version “extrémiste” qui n’a à ma connaissance même pas été utilisée dans la vraie vie.
En outre, les cas de la vraie vie sont souvent a forte variabilité (je ne veux pas de compilation , mais je veux quand même faire des imports Git depuis mon serveur CI/CD et exposer un health check custom, etc.) = pas uniquement un curseur min/max avec des choix arbitraires à chaque cran. Donc il y a des chances que cette approche ne soit finalement pas la bonne stratégie et que ça finisse aux oubliettes en v7
En fait, l’approche “extrémiste” ~ “rien ne passe” me va bien, je trouve que c’est une bonne approche par défaut car elle permet de “tout” fermer sans avoir besoin de spécifier explicitement ce qui doit être fermé. Il ne lui manque qu’un “sauf…” pour dire ce qu’on autorise explicitement (dans mon cas, le health check uniquement a priori).
Elle est complémentaire à l’autre approche “opposée à l’extrême” ~ “tout passe sauf…“ qui consiste à spécifier ce qu’on ferme et qui repose sur la connaissance préalable de ce qui peut être fermé.
J’espère que mes arguments sauront sauver le soldat “secure level”
Sinon, tant pis, il y a toujours l’approche “tout passe sauf…“ qui couvrira le besoin.
En fait un “secure level” à géométrie variable fait double emploi avec les différents mécanismes existants qui permettent déjà de choisir finement ce qu’on ouvre/ferme => son seul intérêt serait de centraliser l’endroit où on le dit…
NB: certain mécanismes de durcissement ne sont pas de niveau applicatif (ex: les white lists qui sont des filters Tomcat), le “secure level” configurable ne concerne mécaniquement que le niveau applicatif
C’est pour cela qu’on met plutôt en avant le docker compose durci comme point de centralisation et d’illustration de tout ce qui peut être fait en termes de durcissement tout en laissant la possibilité de faire son choix au cas par cas
