Je souhaite stocker des fichiers dans Kubernetes Secrets mais je n’ai pas trouvé comment le faire à l’aide d’un fichier yaml
.
J'ai pu le faire en utilisant le cli avec kubectl
:
kubectl create secret generic some-secret --from-file=secret1.txt=secrets/secret1.txt
Mais quand j'essaie quelque chose de similaire dans une yaml
:
apiVersion: v1
kind: Secret
metadata:
name: some-secret
type: Opaque
data:
secret1.txt: secrets/secret1.txt
J'ai cette erreur:
[pos 73]: json: error decoding base64 binary 'assets/elasticsearch.yml': illegal base64 data at input byte 20
Je suis ce guide http://kubernetes.io/docs/user-guide/secrets/ . Il explique comment créer un secret à l'aide de yaml
mais pas comment créer un secret à partir de file à l'aide de yaml
.
C'est possible? Si oui, comment puis-je le faire?
Lorsque vous utilisez le format CLI
, vous utilisez essentiellement un générateur de yaml avant de le poster sur le serveur.
Puisque Kubernetes est une application client-serveur avec l'API REST entre les deux, et que les actions doivent être atomiques, le YAML posté doit contenir le contenu du fichier. Le meilleur moyen de le faire est de l'incorporer en base64. formater en ligne. Ce serait bien si le fichier pouvait être autrement incorporé (l'indentation pourrait peut-être être utilisée pour créer les limites du fichier), mais je n'en ai pas vu d'exemple jusqu'à présent.
Cela étant dit, il n'est pas possible de mettre une référence de fichier sur le yaml, il n'y a pas de rendu avant vol du yaml pour inclure le contenu.
Donc, je viens d'apprendre un élément fondamental de k8 super utile que j'ai manqué, puis j'ai découvert qu'il était associé à une vulnérabilité de sécurité et j'ai trouvé une résolution.
TLDR:
Vous pouvez avoir cleartext multiline strings/textfiles en tant que secret.yaml est dans votre repo secret !!! :)
(Remarque: je recommande de stocker cela dans Hashicorp Vault. Vous pouvez stocker des fichiers de configuration versionnés contenant des secrets, et les visualiser/les éditer facilement via la page Web du coffre-fort. Contrairement à un dépôt Git, vous pouvez bénéficier d'un contrôle d'accès précis, les pipelines peuvent utilisez l’API REST pour extraire les secrets mis à jour, ce qui facilite également la rotation des mots de passe.)
cleartext-appsettings-secret.yaml
appsettings.Dummy.json est le nom de fichier par défaut (clé du secret)
(J'utilise le nom de fichier par défaut de Word, comme vous pouvez le remplacer dans le montage yaml)
et le texte JSON code en clair est le contenu du fichier (valeur du secret)
apiVersion: v1
kind: Secret
metadata:
name: appsettings
namespace: api
type: Opaque
stringData:
appsettings.Dummy.json: |-
{
"Dummy": {
"Placeholder": {
"Password": "blank"
}
}
}
Quand je
kubectl apply -f cleartext-appsettings-secret.yaml
kubectl get secret appsettings -n = api -o yaml
Le secret apparaît en texte clair dans l'annotation ...
apiVersion: v1
data:
appsettings.Dummy.json: ewogICJEdW1teSI6IHsKICAgICJQbGFjZWhvbGRlciI6IHsKICAgICAgIlBhc3N3b3JkIjogImJsYW5rIgogICAgfQogIH0KfQ==
kind: Secret
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{},"name":"appsettings","namespace":"api"},"stringData":{"appsettings.Dummy.json":"{\n \"Dummy\": {\n \"Placeholder\": {\n \"Password\": \"blank\"\n }\n }\n}"},"type":"Opaque"}
creationTimestamp: 2019-01-31T02:50:16Z
name: appsettings
namespace: api
resourceVersion: "4909"
selfLink: /api/v1/namespaces/api/secrets/appsettings
uid: f0629027-2502-11e9-9375-6eb4e0983acc
Apparemment, le yaml utilisé pour créer le secret apparaissant dans l'annotation est le comportement attendu pour kubectl apply -f secret.yaml depuis 2016/a été publié en tant que rapport de bogue, mais le problème est fermé sans solution/ils l'ignorent et le corrigent.
Si vous êtes secret original, yaml est écrit en base64, l'annotation sera au moins en base64, mais dans ce scénario, il s'agit d'un texte clair lisible par l'homme et non directement en base64.
Note1: cela n'arrive pas avec la création secrète impérative
kubectl crée des applicationsettings génériques secrètes - à partir d’applications de fichier.Dummy.json --namespace = api
Note2: Une autre raison de préférer le déclarative appsettings-secret.yaml est que, quand il sera temps d'éditer kubectl apply -f configurera le secret, mais si vous exécutez cette commande create, elle indiquera déjà une erreur et vous devrez supprimez-le avant qu'il ne vous laisse exécuter à nouveau la commande create.
Note3: Une raison pour laquelle kubectl crée un nom générique secret --from-file fichier --namespace/une raison contre secret.yaml est que kubectl show secret ne vous montrera pas la dernière fois que le secret a été modifié. Comme avec la commande create, comme vous devez la supprimer avant de pouvoir la recréer, vous saurez quand elle a été modifiée pour la dernière fois en fonction de sa durée de vie. (Mais il y a de meilleures façons de vérifier)
kubectl applique -f cleartext-appsettings-secret.yaml
kubectl annoter les paramètres d'application secrets -n = api kubectl.kubernetes.io/last-applied-configuration-
kubectl get secret appsettings -n = api -o yaml
Contre la fuite
apiVersion: v1
data:
appsettings.Dummy.json: ewogICJEdW1teSI6IHsKICAgICJQbGFjZWhvbGRlciI6IHsKICAgICAgIlBhc3N3b3JkIjogImJsYW5rIgogICAgfQogIH0KfQ==
kind: Secret
metadata:
creationTimestamp: 2019-01-31T03:06:55Z
name: appsettings
namespace: api
resourceVersion: "6040"
selfLink: /api/v1/namespaces/api/secrets/appsettings
uid: 43f1b81c-2505-11e9-9375-6eb4e0983acc
type: Opaque
Vous pouvez utiliser secode pour remplacer les valeurs secrètes par des chaînes codées base64
, en effectuant simplement:
secode secrets.yaml > secrets_base64.yaml
Il code tous les champs data
et fonctionne avec plusieurs secrets (kind:Secret
) par fichier yaml
, lorsqu'ils sont définis dans une liste (kind: List
).
Avertissement: je suis l'auteur
Pour les utilisateurs Windows de la salle, utilisez ceci pour chacun des fichiers .cer et .key (l'exemple montre le fichier .key codé pour l'insertion dans le fichier YAML):
$Content = Get-Content -Raw -Path C:\ssl-cert-decrypted.key
[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Content)) | Out-File -FilePath C:\ssl-cert-decrypted.key.b64
Ouvrez le nouveau fichier .b64
et collez la sortie (sur une seule ligne) dans votre fichier YAML. Sachez que si vous archivez le fichier YAML dans un référentiel de code source contenant ces informations, la clé sera effectivement compromise, car base64 n'est pas cryptage.