:computer: रहस्यों के लिए अपना टर्मिनल कभी न छोड़ें
:pager: क्लाउड वातावरण के साथ काम करने के लिए आसान और स्वच्छ वर्कफ़्लो बनाएं
:mag_right: रहस्यों को स्कैन करें और सीक्रेट स्प्रॉल से लड़ें

Teller - डेवलपर्स के लिए ओपन-सोर्स यूनिवर्सल सीक्रेट मैनेजर

अपने ऐप्स को विकसित, परीक्षण और निर्माण करते समय रहस्यों का उपयोग करने के लिए अपना टर्मिनल कभी न छोड़ें।

कस्टम स्क्रिप्ट्स, आपकी .zshrc फाइलों में टोकन, आपके bash इतिहास में दिखने वाले EXPORTs, गलत जगह रखी गई .env.production फाइलें और आपके वर्कस्टेशन के आसपास की और चीज़ों के बजाय -- बस teller का उपयोग करें और इसे किसी भी वॉल्ट, की स्टोर, या क्लाउड सेवा से कनेक्ट करें जो आपको पसंद हो (Teller Hashicorp Vault, AWS Secrets Manager, Google Secret Manager, और कई और का समर्थन करता है)।

आप Teller का उपयोग अपने स्वयं के वातावरण को व्यवस्थित करने के लिए या अपनी टीम के लिए एक प्रक्रिया और सर्वोत्तम अभ्यास के रूप में कर सकते हैं।

teller के साथ त्वरित प्रारंभ

बाइनरी डाउनलोड करें releases से बाइनरी लें

स्रोत से निर्माण करें इस विधि का उपयोग करने से आप स्रोत कोड को देख सकेंगे, उसकी समीक्षा कर सकेंगे, और स्वयं एक प्रति का निर्माण कर सकेंगे।

यह बाइनरी को आपकी मशीन पर स्थानीय रूप से इंस्टॉल करेगा:

$ cd teller-cli
$ cargo install --path .

एक नया कॉन्फ़िगरेशन बनाएं

$ teller new
? Select your secret providers ›
⬚ hashicorp_consul
⬚ aws_secretsmanager
⬚ ssm
⬚ dotenv
⬚ hashicorp
⬚ google_secretmanager

फिर, अपने प्रोवाइडर्स के लिए आवश्यक मैप्स और कीज़ सेट करने हेतु नव निर्मित .teller.yml को संपादित करें।

teller.yml पर एक नज़र

Teller YAML आपके प्रोवाइडर्स का वर्णन करता है और प्रत्येक प्रोवाइडर के भीतर एक map जो निम्न का वर्णन करता है:

• की-वैल्यू प्राप्त करने के लिए रूट पथ क्या है
• ऐसे प्रत्येक मैप के लिए, उसका अद्वितीय id जो बाद में संचालन के लिए आपके काम आएगा
• प्रत्येक मैप के लिए, एक वैकल्पिक विशिष्ट कुंजी नाम मैपिंग - आप उन कुंजियों का नाम बदल सकते हैं जिन्हें आप स्रोत प्रोवाइडर से प्राप्त करेंगे

यहाँ एक उदाहरण कॉन्फ़िगरेशन फ़ाइल है। ध्यान दें कि इसमें टेम्पलेटिंग निर्माण भी शामिल हैं -- जैसे कॉन्फ़िगरेशन लोड करते समय पर्यावरण चर प्राप्त करना:

providers:
  hashi_1:
    kind: hashicorp
    maps:
      - id: test-load
        path: /{{ get_env(name="TEST_LOAD_1", default="test") }}/users/user1
        # if empty, map everything
        # == means map to same key name
        # otherwise key on left becomes right
        # in the future: key_transform: camelize, snake_case for automapping the keys
        keys:
          GITHUB_TOKEN: ==
          mg: FOO_BAR
  dot_1:
    kind: dotenv
    maps:
      - id: stg
        path: VAR_{{ get_env(name="STAGE", default="development") }}

अब आप इन प्रोवाइडर्स को hashi_1 या dot_1 के रूप में संबोधित कर सकते हैं। Teller डिफ़ॉल्ट रूप से सभी प्रोवाइडर्स से निर्दिष्ट डेटा खींचता है।

विशेषताएँ

🏃 सबप्रोसेस चलाना

डेमो-जैसा / प्रोडक्शन-जैसा सेटअप के साथ प्रोसेस चलाने के लिए पर्यावरण चर मैन्युअल रूप से निर्यात और सेट करना?

.env.production का उपयोग करके और इसे स्थानीय प्रोजेक्ट में ही उजागर करके परेशानी में पड़ गए?

teller और एक .teller.yml फ़ाइल का उपयोग करके जो आकर्षक नज़रों के सामने कुछ भी उजागर नहीं करती, आप शून्य जोखिम के साथ धाराप्रवाह और निर्बाध रूप से काम कर सकते हैं, और कोट्स की भी आवश्यकता नहीं है:

$ teller run --reset --shell -- node index.js

🔎 वेरिएबल्स का निरीक्षण करना

यह उन वर्तमान वेरिएबल्स को आउटपुट करेगा जिन्हें teller उठाता है। निश्चित रूप से, प्रत्येक से केवल पहले 2 अक्षर दिखाए जाएंगे।

$ teller show

📺 स्थानीय शेल पॉपुलेशन

अपनी शेल स्क्रिप्ट्स और डॉटफाइल्स में रहस्यों को हार्डकोड करना?

कुछ मामलों में अपने वर्तमान शेल में वेरिएबल्स को eval करना समझ में आता है। उदाहरण के लिए आपकी .zshrc में teller का उपयोग करना अधिक समझ में आता है, न कि उन सभी को .zshrc फ़ाइल में ही हार्डकोड करना।

इस स्थिति में, आपको यह जोड़ना चाहिए:

eval "$(teller sh)"

🐳 आसान Docker वातावरण

हर तरह के वेरिएबल्स को पकड़ने, उन्हें सेट करने से थक गए हैं, और इनके आपके शेल इतिहास में भी दिखने की चिंता है?

अब से इस वन-लाइनर का उपयोग करें:

$ docker run --rm -it --env-file <(teller env) alpine sh

⚠️ रहस्यों के लिए स्कैन करें

Teller आपको सीक्रेट स्प्रॉल और हार्ड-कोडेड रहस्यों से लड़ने में मदद कर सकता है, साथ ही आपके वॉल्ट के साथ काम करने के लिए सर्वोत्तम उत्पादकता उपकरण भी हो सकता है।

यह आपके CI में भी एकीकृत हो सकता है और आपके DevSecOps पाइपलाइन के लिए shift-left सुरक्षा उपकरण के रूप में कार्य कर सकता है।

अपने कोड में अपने वॉल्ट-संग्रहीत रहस्यों की खोज करने के लिए यह चलाएं:

$ teller scan

आप इसे अपने CI में इस प्रकार लिंटर के रूप में चला सकते हैं:

run: teller scan --error-if-found

यदि इसे कुछ मिलता है तो यह आपके बिल्ड को तोड़ देगा (एग्ज़िट कोड 1 लौटाता है)।

आप --json के साथ परिणामों को JSON के रूप में निर्यात भी कर सकते हैं और -b के साथ बाइनरी फ़ाइलों को स्कैन कर सकते हैं।

♻️ प्रोसेस आउटपुट, लॉग्स और फ़ाइलों से रहस्यों को रिडैक्ट करें

आप अपने इंफ्रास्ट्रक्चर में teller को रिडैक्शन टूल के रूप में उपयोग कर सकते हैं, और उनके आउटपुट को रिडैक्ट करते हुए प्रोसेस चला सकते हैं, साथ ही लॉग्स और लॉग्स के लाइव टेल्स को साफ कर सकते हैं।

किसी भी प्रोसेस आउटपुट, टेल या लॉग्स को teller में पाइप करके उन्हें लाइव रिडैक्ट करें:

$ cat some.log | teller redact

यह tail -f के साथ भी काम करना चाहिए:

$ tail -f /var/log/apache.log | teller redact

अंत में, यदि आपके पास कुछ ऐसी फ़ाइलें हैं जिन्हें आप रिडैक्ट करना चाहते हैं, तो आप वह भी कर सकते हैं:

$ teller redact --in dirty.csv --out clean.csv

यदि आप --in छोड़ते हैं तो Teller stdin लेगा, और यदि आप --out छोड़ते हैं तो Teller stdout पर आउटपुट करेगा।

📜 टेम्पलेट्स भरें

आप कस्टम टेम्पलेट्स भर सकते हैं:

$ teller template --in config-templ.t

टेम्पलेट प्रारूप Tera है जो लिक्विड या हैंडलबार्स के समान है।

यहाँ एक उदाहरण टेम्पलेट है:

production_var: {{ key(name="PRINT_NAME")}}
production_mood: {{ key(name="PRINT_MOOD")}}

🔄 प्रोवाइडर्स के बीच डेटा कॉपी/सिंक करें

ऐसे मामलों में जहां आप प्रोवाइडर्स के बीच सिंक करना चाहते हैं, आप teller copy के साथ ऐसा कर सकते हैं।

विशिष्ट मैपिंग कुंजी सिंक

एक प्रोवाइडर से दूसरे प्रोवाइडर में मैपिंग कॉपी करने के लिए आप <provider name>/<map id> प्रारूप का उपयोग कर सकते हैं:

$ teller copy --from source/dev --to target/prod,<...>

इस सरल उदाहरण में, हम निम्नलिखित कॉन्फ़िगरेशन फ़ाइल का उपयोग करते हैं

providers:
  dot1:
    kind: dotenv
    maps:
      - id: one
        path: one.env
  dot2:
    kind: dotenv
    maps:
      - id: two
        path: two.env

यह निम्न करेगा:

1. स्रोत मैपिंग से सभी मैप किए गए मान प्राप्त करें
2. प्रत्येक लक्ष्य प्रोवाइडर के लिए, मेल खाती मैपिंग खोजें, और उसमें स्रोत से मान कॉपी करें

डिफ़ॉल्ट रूप से कॉपी करना लक्ष्य मैपिंग को अपडेट करेगा (डेटा अप्सर्ट करेगा), यदि आप प्रतिस्थापित करना चाहते हैं तो आप --replace का उपयोग कर सकते हैं।

🚲 प्रोवाइडर्स में लिखें और मल्टी-राइट करें

Teller प्रोवाइडर्स write उपयोग मामलों का समर्थन करते हैं जो प्रोवाइडर्स में मान लिखने की अनुमति देते हैं।

याद रखें, इस सुविधा के लिए यह अभी भी आपकी teller.yml फ़ाइल में परिभाषाओं के इर्द-गिर्द घूमती है:

$ teller put --providers new --map-id one NEW_VAR=s33kret

इस उदाहरण में, यह कॉन्फ़िगरेशन उपयोग किया जा रहा है:

providers:
  new:
    kind: dotenv
    maps:
      - id: one
        path: new.env

कुछ नोट्स:

• मान key=value प्रारूप में की-वैल्यू जोड़ी होते हैं और आप एक साथ कई जोड़ियाँ निर्दिष्ट कर सकते हैं
• जब आप कोई शाब्दिक संवेदनशील मान निर्दिष्ट कर रहे हों, तो सुनिश्चित करें कि ENV वेरिएबल का उपयोग करें ताकि आपके इतिहास में कुछ भी संवेदनशील दर्ज न हो
• फ़्लैग --providers आपको एक साथ एक या अधिक प्रोवाइडर्स में पुश करने देता है

❌ प्रोवाइडर्स से हटाएं और मल्टी-डिलीट करें

Teller प्रोवाइडर्स प्रोवाइडर्स से मान हटाने का समर्थन करते हैं।

$ teller delete --providers new --map-id one DELETE_ME

कुछ नोट्स:

• आप हटाने के लिए कई कुंजियाँ निर्दिष्ट कर सकते हैं, उदाहरण के लिए:
• फ़्लैग --providers आपको एक साथ एक या अधिक प्रोवाइडर्स में पुश करने देता है

YAML YAML प्रारूप में निर्यात करें

XXX TODO: कमांड एक्सपोर्ट कैसे काम करता है इसे फिर से लिखें

आप YAML प्रारूप में निर्यात कर सकते हैं, जो GCloud के लिए उपयुक्त है:

$ teller export yaml

उदाहरण प्रारूप:

FOO: "1"
KEY: VALUE

JSON JSON प्रारूप में निर्यात करें

आप JSON प्रारूप में निर्यात कर सकते हैं, जो jq या अन्य वर्कफ़्लो के माध्यम से पाइप करने के लिए उपयुक्त है:

$ teller export json

उदाहरण प्रारूप:

{
  "FOO": "1"
}

प्रोवाइडर्स

आप प्रोवाइडर्स और उनके वर्णित कॉन्फ़िगरेशन मानों की सूची दस्तावेज़ीकरण में प्राप्त कर सकते हैं।

परीक्षण जाँच सूची:

• विंडोज़ पर docker: यदि आपके पास Docker का उपयोग करने वाला कंटेनर-आधारित परीक्षण है, तो सुनिश्चित करें कि #[cfg(not(windows))] का उपयोग करके इसे Windows पर बाहर रखें

• संसाधन अर्थ (resource semantics): प्रोवाइडर्स बनाते समय, खाली और नहीं मिला के अर्थ को दो अलग-अलग अर्थों के रूप में संरेखित करें: यदि कोई प्रोवाइडर स्पष्ट "नहीं मिला" अर्थ (404, NotFound, आदि) का समर्थन करता है, तो Error::NotFound का उपयोग करें। अन्यथा जब कोई प्रोवाइडर "नहीं मिला" अर्थ को खाली डेटा बैग के रूप में संकेत देता है, तो एक खाली KV[] लौटाएं (अर्थात "खाली" के अर्थ को "नहीं मिला" में अनुवाद न करें)।

परीक्षण

परीक्षण निम्न के साथ किया जाता है:

$ cargo test --all --all-features

और इसके लिए आपकी मशीन पर Docker (या समकक्ष) की आवश्यकता होती है।

धन्यवाद:

सभी योगदानकर्ताओं को - आप यह संभव बनाते हैं, धन्यवाद!

आचार संहिता

Teller CNCF आचार संहिता का पालन करता है

कॉपीराइट

कॉपीराइट (c) 2024 @jondot। अधिक जानकारी के लिए LICENSE देखें।