Comment injecter le secret Kubernetes dans le fichier de configuration

essayez les étapes ci-dessous

1.  add the password as an environment variable

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>javax.jdo.option.ConnectionUserName</name>
    <value>hive</value>
  </property>
  <property>
    <name>javax.jdo.option.ConnectionPassword</name>
    <value>${my_db_password}</value>
  </property>

2. include the password in secret object
3. load the env variable from secret object. you need to define env from secret object ref in pod definition

Vous pouvez utiliser une combinaison d'un conteneur d'initialisation et d'un volume partagé pour cela, si vous ne souhaitez pas exposer le secret directement au conteneur d'application.

Le conteneur d'initialisation utilise le secret pour créer le fichier de configuration à partir d'un modèle (par exemple, sed remplaçant un espace réservé) et placer le fichier dans un volume partagé. Le conteneur d'application utilise le volume pour récupérer le fichier. (Étant donné que vous pouvez configurer le chemin où l'application attend le fichier de configuration.)

L'autre option consiste simplement à utiliser le secret comme variable d'environnement pour votre application et à le récupérer séparément de la configuration générale.

Le problème est que XML ne développera pas cette variable. Je ne sais pas si cela correspond à votre cas d'utilisation, mais nous avions une application JVM avec une configuration XML et avons fait ce qui suit pour la faire fonctionner:

1. Créer Secret
2. Référence Secret dans les variables d'environnement Depoyment
3. Injectez-les en tant que Propriétés système dans une variable JAVA_OPT
4. Les propriétés système sont développées

Exemple

Fichier de déploiement:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>javax.jdo.option.ConnectionUserName</name>
    <value>"#{systemProperties['db.user']}"</value>
  </property>
  <property>
    <name>javax.jdo.option.ConnectionPassword</name>
    <value>"#{systemProperties['db.password']}"</value>
  </property>

Votre fichier de configuration XML:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myimage
          ports:
            - containerPort: 8080
          env:
            - name: DB_USER
              valueFrom:
                secretKeyRef:
                  name: my-secret-credentials
                  key: user
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: my-secret-credentials
                  key: password
            - name: JAVA_OPTS
              value: "-db.user=$(DB_USER) -Ddb.password=$(DB_PASSWORD)"

De cette façon, votre secret est injecté en toute sécurité. Faites juste attention lorsque vous faites référence à des variables d'environnement à partir d'une autre variable d'environnement dans le déploiement yaml, il utilise des parenthèses au lieu d'accolades.

J'espère que cela aide

Je ne sais pas si cette approche fonctionne sur Hadoop 2.

Dans Hadoop 3+, j'ai utilisé la configuration suivante pour core-site.xml et hive-metastore.xml pour définir les valeurs de configuration à partir des variables d'environnement:

core-site.xml

   <property>
      <name>javax.jdo.option.ConnectionPassword</name>
      <value>${env.METASTORE_PASSWORD}</value>
   </property>

metastore-site.xml:

<property>
    <name>fs.defaultFS</name>
    <value>${env.HADOOP_DEFAULT_FS}</value>
</property>

Où HADOOP_DEFAULT_FS et METASTORE_PASSWORD sont définis dans un secret k8s qui est attaché au conteneur en tant que variables env.