Les pubs vous déplaisent ? Aller Sans pub Auj. 

Générateur de ConfigMap et de Secret Kubernetes

DonnéesPromoteurSécurité

[iotools_kubernetes_configmap_secret_generator]

Guide

Générateur de ConfigMap et de Secret Kubernetes

Crée des manifestes de ConfigMap et de Secret prêts à être utilisés avec kubectl à partir d'une simple liste de paires clé=valeur. Le générateur vérifie les noms de ressources selon RFC 1123, encode les valeurs de Secret en base64 pour le champ, et génère un YAML propre que vous pouvez directement pipé dans data . kubectl apply -f -. Aucune donnée ne quitte votre navigateur.

Comment utiliser

Choisissez le type de ressource : ConfigMap pour la configuration non sensible ou Secret pour les identifiants, les tokens et les certificats.
Entrez un nom de ressource en minuscules (RFC 1123) et, optionnellement, un espace de noms.
Pour les Secrets, sélectionnez le type de secret (Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls, etc.) et décidez si vous souhaitez automatiser l'encodage en base64 (data:) ou les laisser en clair (stringData:).
Collez vos paires clé/valeur, une KEY=value par ligne. Ajoutez des étiquettes et des annotations si nécessaire.
Copiez le YAML généré ou téléchargez-le sous forme de .yaml fichier prêt à être utilisé dans kubectl apply.

Caractéristiques

Un outil pour créer des ConfigMap et des Secrets en un seul lieu – Alternez entre les types de ressources sans perdre vos entrées.
Encodage automatique en base64 – Les valeurs de Secret sont encodées avec support complet du UTF-8, donc les mots de passe et les tokens contenant des caractères non-ASCII sont correctement transférés.
mode stringData – Évitez l'encodage lorsque vous souhaitez un manifeste éditable par humain ; Kubernetes effectuera l'encodage en base64 lors de l'application.
Tous les types standard de Secret – Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls, kubernetes.io/basic-auth, kubernetes.io/ssh-authet kubernetes.io/service-account-token.
Validation en temps réel selon RFC 1123 – Détectez les noms, espaces de noms et clés de données invalides avant que kubectl apply ne les rejettent.
Étiquettes, annotations et indicateur immuable – Ajoutez des métadonnées et activez l'indicateur immuable pour les ressources qui ne doivent jamais changer.
Citation intelligente du YAML – Les valeurs qui ressemblent à des nombres, des booléens ou contiennent des caractères spéciaux sont automatiquement encadrées ; les valeurs multi-lignes utilisent des scalaires en bloc.
Traitement côté client à 100 % – Les clés et les valeurs ne quittent jamais le navigateur ; rien n'est envoyé, enregistré ou transmis.

 FAQ

Quelle est la différence entre un ConfigMap et un Secret dans Kubernetes ?

Les ConfigMaps stockent la configuration non sensible sous forme de paires clé/valeur simples, tandis que les Secrets sont destinés aux identifiants, aux tokens et aux autres données sensibles. Les valeurs des Secrets sont stockées en base64 et Kubernetes peut les monter avec des autorisations plus strictes, les intégrer avec des fournisseurs de chiffrement en place et limiter les nœuds qui les reçoivent.
Pourquoi les valeurs de Secret Kubernetes sont-elles encodées en base64 ?

L'encodage en base64 permet aux données binaires de se déplacer en toute sécurité dans YAML/JSON sans détruire la structure ou produire des caractères invalides. Cela ne constitue pas une cryptographie, donc tout utilisateur ayant accès à l'API du cluster peut toujours déchiffrer les valeurs. La protection réelle vient des RBAC, du chiffrement en stockage et des journaux d'audit.
Quand devrais-je marquer un ConfigMap ou un Secret comme immuable ?

Marquez un ConfigMap ou un Secret comme immuable lorsque vous n'attendez pas de le modifier et que vous souhaitez réduire la charge du kubelet dans les grands clusters. Les ressources immuables évitent les mises à jour basées sur les observations, donc le kubelet cesse d'envoyer des requêtes périodiques. Le coût est que vous devez supprimer et recréer la ressource pour modifier une valeur.
Quelle est la différence entre data et stringData dans un manifeste de Secret ?

Le champ data doit contenir des valeurs encodées en base64 ; le serveur API les stocke telles quelles. Le champ stringData accepte des chaînes plain UTF-8 que le serveur API encode en base64 lors de la création ou de la mise à jour. Si les deux sont présents, stringData prévaut pour toute clé en surcroît. Utilisez stringData lors de la création de secrets à la main et data lors de l'intégration avec des outils qui encodent déjà.

Envie d'une expérience sans pub ? Passez à la version sans pub



 Installez nos extensions

Ajoutez des outils IO à votre navigateur préféré pour un accès instantané et une recherche plus rapide

Sur

恵 Le Tableau de Bord Est Arrivé !

Tableau de Bord est une façon amusante de suivre vos jeux, toutes les données sont stockées dans votre navigateur. D'autres fonctionnalités arrivent bientôt !

ANNONCE · Supprimer ?