web-dev-qa-db-fra.com

Quelle est la bonne façon de déployer des magasins de clés secrètes Java dans un environnement OpenShift?

Nous avons une Java qui est censée être déplacée d'un modèle de déploiement normal (installation sur un serveur) vers un environnement OpenShift (déploiement en tant que conteneur Docker). Actuellement, cette application consomme un ensemble de Java magasins de clés (fichiers .jks) pour les certificats clients pour communiquer avec des interfaces Web tierces. Nous avons un magasin de clés par interface.

Ces fichiers jks sont déployés manuellement sur les machines de production et sont parfois mis à jour lorsque des certificats tiers doivent être mis à jour. Notre application a un paramètre avec un chemin d'accès aux fichiers du magasin de clés et au démarrage, elle en lira les certificats, puis les utilisera pour communiquer avec les systèmes tiers.

Maintenant, lorsque nous passons à un déploiement OpenShift, nous avons une image de docker avec l'application qui va être utilisée pour tous les environnements (développement, test et production). Toute la configuration est donnée sous forme de variables d'environnement. Cependant, nous ne pouvons pas donner de fichiers jks en tant que variables d'environnement, celles-ci doivent être montées dans le système de fichiers du conteneur Docker.

Comme ces certificats sont un secret, nous ne voulons pas les incorporer à l'image. J'ai analysé la documentation d'OpenShift pour trouver des indices sur la façon d'aborder cela et j'ai trouvé essentiellement deux options: utiliser des secrets ou monter une revendication de volume persistante (PVC).

Les secrets ne semblent pas fonctionner pour nous car ce sont à peu près des paires clé-valeur que vous pouvez monter en tant que fichier ou avoir remises en tant que variables d'environnement. Ils ont également une limite de taille. L'utilisation d'un PVC fonctionnerait théoriquement, mais nous aurions besoin d'avoir un moyen d'obtenir les fichiers JKS dans ce volume en premier lieu. Un moyen simple serait de simplement démarrer un conteneur Shell pour monter le PVC et y copier manuellement les fichiers à l'aide des outils de ligne de commande OpenShift, mais j'espérais une solution un peu moins manuelle.

Avez-vous trouvé une solution intelligente à ce problème ou à un problème similaire dans lequel vous deviez placer des fichiers dans un conteneur?

openshiftclient-certificates
9
Jan Thomä

Il s'avère que j'ai mal compris comment fonctionnent les secrets. Ce sont en effet des paires clé-valeur que vous pouvez monter sous forme de fichiers. La valeur peut cependant être tout binaire encodé en base64 qui sera mappé en tant que contenu du fichier. La solution consiste donc à coder d'abord le contenu du fichier JKS en base64:

cat keystore.jks| base64

Ensuite, vous pouvez mettre cela dans votre définition secrète:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: my-namespace
data:
  keystore.jks: "<base 64 from previous command here>"

Enfin, vous pouvez monter cela dans votre conteneur Docker en le référençant dans la configuration de déploiement:

apiVersion: v1
kind: DeploymentConfig
spec:
  ...
  template:
    spec:
      ...
      container:
       - name: "my-container"
         ...
         volumeMounts:
            - name: secrets
              mountPath: /mnt/secrets
              readOnly: true

     volumes:
        - name: secrets
          secret:
            secretName: "my-secret"
            items:
              - key: keystore.jks
                path: keystore.jks

Cela montera le volume secret secrets à /mnt/secrets et crée l'entrée avec le nom keystore.jks disponible sous forme de fichier keystore.jks sous /mnt/secrets.

Je ne sais pas si c'est vraiment une bonne façon de procéder, mais cela fonctionne au moins ici.

10
Jan Thomä

Vous pouvez ajouter et monter les secrets comme indiqué par Jan Thomä, mais c'est plus facile comme ça, en utilisant l'outil de ligne de commande oc:

./oc create secret generic crnews-keystore --from-file=keystore.jks=$HOME/git/crnews-service/src/main/resources/keystore.jks --from-file=truststore.jks=$HOME/git/crnews-service/src/main/resources/truststore.jks --type=opaque

Cela peut ensuite être ajouté via l'interface utilisateur: Applications-> Déploiements -> -> "Ajouter des fichiers de configuration" où vous pouvez choisir quel secret vous souhaitez monter où.

Notez que les paires nom = valeur (par exemple truststore.jks =) seront utilisées comme filename = base64decoded-Content.

6
Frischling

S'appuyant sur ce que @Frischling et @ Jan-Thomä ont dit, et en accord avec Frischling, son chemin a été plus facile et s'est occupé des deux magasins de clés de certificats de confiance, après avoir ajouté les magasins de clés en secret, sous Applications->Deployments->[your deployments name] Cliquez sur le lien environnement et ajoutez les propriétés système suivantes:
Nom: Java_OPTS_APPEND et
Valeur-Djavax.net.ssl.keyStorePassword=changeme -Djavax.net.ssl.keyStore=/mnt/keystores/your_cert_key_store.jks -Djavax.net.ssl.trustStorePassword=changeme -Djavax.net.ssl.trustStore=/mnt/keystores/your_ca_key_store.jks

Cela, comme indiqué, ajoutera les chemins d'accès aux fichiers de clés, les mots de passe aux options Java utilisées par l'application, par exemple JBoss/WildFly ou Tomcat).

0
JGlass