कॉन्फ़िगरेशन फाइल का उपयोग करके सीक्रेट्स का प्रबंधन
शुरू करने से पहले
आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:
सीक्रेट बनाएं
आप पहले JSON या YAML फॉर्मेट में एक मैनिफेस्ट में Secret
ऑब्जेक्ट को परिभाषित कर सकते हैं, और फिर उस ऑब्जेक्ट को बना सकते हैं। Secret रिसोर्स में दो मैप्स होते हैं: data
और stringData
। data
फील्ड का उपयोग मनमाना डेटा स्टोर करने के लिए किया जाता है, जो base64 का उपयोग करके एनकोड किया जाता है। stringData
फील्ड सुविधा के लिए प्रदान किया जाता है, और यह आपको समान डेटा को अनएनकोडेड स्ट्रिंग्स के रूप में प्रदान करने की अनुमति देता है। data
और stringData
की कुंजियों में अल्फ़ान्यूमेरिक वर्ण, -
, _
या .
होने चाहिए।
निम्नलिखित उदाहरण data
फील्ड का उपयोग करके एक सीक्रेट में दो स्ट्रिंग्स स्टोर करता है।
-
स्ट्रिंग्स को base64 में कनवर्ट करें:
echo -n 'admin' | base64 echo -n '1f2d1e2e67df' | base64
टिप्पणी:
सीक्रेट डेटा के सीरियलाइज्ड JSON और YAML मान base64 स्ट्रिंग्स के रूप में एनकोड किए जाते हैं। इन स्ट्रिंग्स के भीतर न्यूलाइन मान्य नहीं हैं और इन्हें छोड़ा जाना चाहिए। Darwin/macOS परbase64
यूटिलिटी का उपयोग करते समय, उपयोगकर्ताओं को लंबी लाइनों को विभाजित करने के लिए-b
विकल्प का उपयोग करने से बचना चाहिए। इसके विपरीत, Linux उपयोगकर्ताओं कोbase64
कमांड में-w 0
विकल्प जोड़ना चाहिए या यदि-w
विकल्प उपलब्ध नहीं है तोbase64 | tr -d '\n'
पाइपलाइन का उपयोग करना चाहिए।आउटपुट इस तरह का होता है:
YWRtaW4= MWYyZDFlMmU2N2Rm
-
मैनिफेस्ट बनाएं:
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm
ध्यान दें कि एक सीक्रेट ऑब्जेक्ट का नाम एक मान्य DNS सबडोमेन नाम होना चाहिए।
-
kubectl apply
का उपयोग करके सीक्रेट बनाएं:kubectl apply -f ./secret.yaml
आउटपुट इस तरह का होता है:
secret/mysecret created
यह सत्यापित करने के लिए कि सीक्रेट बनाया गया था और सीक्रेट डेटा को डिकोड करने के लिए, kubectl का उपयोग करके सीक्रेट्स का प्रबंधन देखें।
सीक्रेट बनाते समय अनएनकोडेड डेटा निर्दिष्ट करें
कुछ परिदृश्यों के लिए, आप stringData
फील्ड का उपयोग करना चाह सकते हैं। यह फील्ड आपको सीक्रेट में सीधे एक नॉन-base64 एनकोडेड स्ट्रिंग डालने की अनुमति देता है, और जब सीक्रेट बनाया या अपडेट किया जाता है तो स्ट्रिंग आपके लिए एनकोड की जाएगी।
इसका एक व्यावहारिक उदाहरण यह हो सकता है जहां आप एक एप्लिकेशन डिप्लॉय कर रहे हैं जो कॉन्फ़िगरेशन फाइल को स्टोर करने के लिए एक सीक्रेट का उपयोग करता है, और आप अपनी डिप्लॉयमेंट प्रक्रिया के दौरान उस कॉन्फ़िगरेशन फाइल के कुछ हिस्सों को पॉप्युलेट करना चाहते हैं।
उदाहरण के लिए, यदि आपका एप्लिकेशन निम्नलिखित कॉन्फ़िगरेशन फाइल का उपयोग करता है:
apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"
आप इसे निम्नलिखित परिभाषा का उपयोग करके एक सीक्रेट में स्टोर कर सकते हैं:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml: |
apiUrl: "https://my.api.com/api/v1"
username: <user>
password: <password>
टिप्पणी:
सीक्रेट के लिएstringData
फील्ड सर्वर-साइड एप्लाई के साथ अच्छी तरह से काम नहीं करता है।जब आप सीक्रेट डेटा प्राप्त करते हैं, तो कमांड एनकोडेड मान वापस करता है, न कि वे प्लेनटेक्स्ट मान जो आपने stringData
में प्रदान किए थे।
उदाहरण के लिए, यदि आप निम्नलिखित कमांड चलाते हैं:
kubectl get secret mysecret -o yaml
आउटपुट इस तरह का होता है:
apiVersion: v1
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
name: mysecret
namespace: default
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
data
और stringData
दोनों निर्दिष्ट करें
यदि आप एक फील्ड को data
और stringData
दोनों में निर्दिष्ट करते हैं, तो stringData
से मान का उपयोग किया जाता है।
उदाहरण के लिए, यदि आप निम्नलिखित सीक्रेट को परिभाषित करते हैं:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
stringData:
username: administrator
टिप्पणी:
सीक्रेट के लिएstringData
फील्ड सर्वर-साइड एप्लाई के साथ अच्छी तरह से काम नहीं करता है।Secret
ऑब्जेक्ट इस प्रकार बनाया जाता है:
apiVersion: v1
data:
username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
name: mysecret
namespace: default
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
YWRtaW5pc3RyYXRvcg==
डिकोड होकर administrator
बनता है।
सीक्रेट को संपादित करें
मैनिफेस्ट का उपयोग करके बनाए गए सीक्रेट में डेटा को संपादित करने के लिए, अपने मैनिफेस्ट में data
या stringData
फील्ड को संशोधित करें और फाइल को अपने क्लस्टर में लागू करें। आप एक मौजूदा Secret
ऑब्जेक्ट को संपादित कर सकते हैं जब तक कि वह अपरिवर्तनीय नहीं है।
उदाहरण के लिए, यदि आप पिछले उदाहरण से पासवर्ड को birdsarentreal
में बदलना चाहते हैं, तो निम्नलिखित करें:
-
नई पासवर्ड स्ट्रिंग को एनकोड करें:
echo -n 'birdsarentreal' | base64
आउटपुट इस तरह का होता है:
YmlyZHNhcmVudHJlYWw=
-
अपनी नई पासवर्ड स्ट्रिंग के साथ
data
फील्ड को अपडेट करें:apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: YmlyZHNhcmVudHJlYWw=
-
मैनिफेस्ट को अपने क्लस्टर में लागू करें:
kubectl apply -f ./secret.yaml
आउटपुट इस तरह का होता है:
secret/mysecret configured
Kubernetes मौजूदा Secret
ऑब्जेक्ट को अपडेट करता है। विस्तार से, kubectl
टूल नोटिस करता है कि समान नाम का एक मौजूदा Secret
ऑब्जेक्ट है। kubectl
मौजूदा ऑब्जेक्ट को प्राप्त करता है, उसमें परिवर्तनों की योजना बनाता है, और बदले हुए Secret
ऑब्जेक्ट को आपके क्लस्टर कंट्रोल प्लेन को सबमिट करता है।
यदि आपने इसके बजाय kubectl apply --server-side
निर्दिष्ट किया है, तो kubectl
सर्वर साइड एप्लाई का उपयोग करता है।
साफ़ करें
आपके द्वारा बनाए गए सीक्रेट को हटाने के लिए:
kubectl delete secret mysecret
आगे क्या है
- सीक्रेट कॉन्सेप्ट के बारे में और पढ़ें
- kubectl का उपयोग करके सीक्रेट्स का प्रबंधन करना सीखें
- kustomize का उपयोग करके सीक्रेट्स का प्रबंधन करना सीखें