मुख्य सामग्री पर जाएँ

चरण 3 - Secrets Manager में secrets बनाएँ

CDR reports वाले S3 bucket (s3name) तक Glasswall Halo की पहुँच सक्षम करने के लिए, एक iam user और role आवश्यक है।

  • एक IAM user (external_secrets_iam_user) बनाएँ और एक role (external_secrets_iam_role) असाइन करें, जिसमें ऐसी policy हो जो उस s3 bucket पर read और write की अनुमति देती हो जिसमें CDR reports संग्रहीत होंगी। यह bucket prerequisites चरण में बनाई जा चुकी होनी चाहिए।

  • iam user access key id को संग्रहीत करने वाला AWS_ACCESS_KEY_ID Secret बनाएँ।

  • iam user secret access key को संग्रहीत करने वाला AWS_SECRET_ACCESS_KEY Secret बनाएँ।

3.1 - MongoDB connection string​

Glasswall Halo Policy Management API को MongoDB में policies बनाने और प्रबंधित करने में सक्षम करने के लिए, MongoDB connection string को AWS Secrets Manager में संग्रहीत करें।

  • आप नीचे दिए गए उदाहरण में दिखाए अनुसार AWS Console से DocumentDB MongoDB compatible connection string प्राप्त कर सकते हैं।
mongodb://${username}:${password}@${endpoint}:${port}/?ssl=true&ssl_ca_certs=rds->combined-ca-bundle.pem&replicaSet=rs0&readPreference=secondaryPreferred&retryWrites=false
  • ${mongodb_connstring} को बदलकर अपनी connection string (स्क्रीनशॉट में हाइलाइट की गई) दर्ज करें, और ${region} को बदलकर अपना AWS region दर्ज करें (जैसा नीचे दिखाया गया है)।
aws secretsmanager create-secret --name "mongodb-connectionstring" --secret-string >"${mongodb_connstring}" --region "${region}"

MongoDB passwords को AWS Secret Manager में एक secret के रूप में जोड़ें​

नोट: यदि आपने पहले AWS के भीतर MongoDB को configure और setup किया है और ऊपर सूचीबद्ध अनुसार अपनी MongoDB connection string बना ली है, तो आप इस चरण को छोड़ सकते हैं।

यदि नहीं, तो Glasswall Halo's Policy Management API को MongoDB में policies बनाने और प्रबंधित करने, और Asynchronous API को requests बनाने और प्रबंधित करने में सक्षम करने के लिए, MongoDB को Step 8 में सूचीबद्ध Helm charts का उपयोग करके deploy करना होगा।

MongoDB Helm chart द्वारा दो users बनाए जाएंगे और संबंधित user का password Key Vault secret में सेट किया जाना चाहिए।

Passwords जैसे संवेदनशील डेटा AWS Secrets Manager में होने चाहिए।

aws secretsmanager create-secret --name "mongodb-cdrp-password" --secret-string "<cdrp-user-password>" --region "${region}"
aws secretsmanager create-secret --name "mongodb-admin-password" --secret-string "<admin-user-password>" --region "${region}"

3.2 - Amazon DocumentDB Certificate Authority (CA)​

cdrplatform-policy-API service के MongoDB से सफलतापूर्वक authenticate होने के लिए, उसे Amazon DocumentDB Certificate Authority पर trust करना चाहिए।

  • Secrets Manager में cdrp-rds-ca-bundle नाम का एक secret बनाएं और Amazon द्वारा प्रदान की गई certificate authority की सामग्री जोड़ें।

3.3 - [वैकल्पिक] ReversingLabs credentials जोड़ें​

Glasswall Halo को ReversingLabs के साथ integrate करने के लिए, ReversingLabs credentials को AWS Secrets Manager में संग्रहीत करें।

$reversinglabs_username और $reversinglabs_password को वास्तविक username और password से बदलें।

aws secretsmanager create-secret  --name "halo-reversinglabs-username" --secret-string "${reversinglabs_username}" --region "${region}"
aws secretsmanager create-secret  --name "halo-reversinglabs-password" --secret-string "${reversinglabs_password}" --region "${region}"

3.4 - [वैकल्पिक] ICAP MTLS प्रमाणपत्र जोड़ें​

ICAP सर्वरों को MTLS प्रमाणपत्रों का उपयोग करके पारस्परिक client authentication के लिए कॉन्फ़िगर किया जा सकता है। प्रमाणपत्रों को Kubernetes secrets का उपयोग करके ICAP server pods में माउंट किया जाएगा।

Server certificates और certificate authority को AWS Secrets Manager में जोड़ें ताकि उन्हें Kubernetes secrets में sync किया जा सके।

aws secretsmanager create-secret --name "tls-server-cert" --region "$region" --secret-string <file://path/to/mtls-server-cert.pem>
aws secretsmanager create-secret --name "tls-server-key" --region "$region" --secret-string <file://path/to/mtls-server-key.pem>
aws secretsmanager create-secret --name "tls-cafile" --region "$region" --secret-string <file://path/to/mtls-ca-cert.pem>

जारी रखें

मदद चाहिए?

अंतिम बार अपडेट किया गया को