AWS - Federation Abuse

हैकट्रिक्स का समर्थन करें

SAML

SAML के बारे में जानकारी के लिए कृपया जाँचें:

SAML के माध्यम से एक पहचान संघ कैसे कॉन्फ़िगर करें इसके लिए आपको एक नाम और सभी SAML कॉन्फ़िगरेशन (एंडपॉइंट्स, सार्वजनिक कुंजी के साथ प्रमाणपत्र) को समेत करने वाले मेटाडेटा XML प्रदान करना होगा।

OIDC - Github क्रियाएँ दुरुपयोग

एक गिटहब क्रिया को पहचान प्रदाता के रूप में जोड़ने के लिए:

  1. प्रदाता प्रकार के लिए, OpenID Connect का चयन करें।

  2. प्रदाता URL के लिए, https://token.actions.githubusercontent.com दर्ज करें।

  3. प्रदाता का थंबप्रिंट प्राप्त करने के लिए थंबप्रिंट प्राप्त करें पर क्लिक करें

  4. दर्शक के लिए, sts.amazonaws.com दर्ज करें।

  5. गिटहब क्रिया को जो अनुमतियाँ चाहिए उन्हें और एक भरोसा नीति बनाएं जो प्रदाता को विश्वास करती है जैसे:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:sub": [ "repo:ORG_OR_USER_NAME/REPOSITORY:pull_request", "repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main" ], "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" } } } ] }

6. पिछली नीति में ध्यान दें कि कैसे केवल एक **शाखा** को **अनुमति** दी गई थी जो एक विशेष **ट्रिगर** के साथ **संगठन** के **पुनर्निर्माण** से अधिकृत थी।
7. गिटहब क्रिया जो **अनुकरण** कर सकती है, उस **भूमिका** का **ARN** जो गिटहब क्रिया को जानने की आवश्यकता है, इसलिए इसे एक **गुप्त** में एक **पर्यावरण** के अंदर एक **रहस्य** के रूप में **स्टोर** करें।
8. अंततः AWS क्रेडेंशियल कॉन्फ़िगर करने के लिए गिटहब क्रिया का उपयोग करें जो कार्यप्रवाह द्वारा उपयोग किए जाने वाले हैं:
```yaml
name: 'test AWS Access'

# The workflow should only trigger on pull requests to the main branch
on:
pull_request:
branches:
- main

# Required to get the ID Token that will be used for OIDC
permissions:
id-token: write
contents: read # needed for private repos to checkout

jobs:
aws:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3

- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-region: eu-west-1
role-to-assume: ${{ secrets.READ_ROLE }}
role-session-name: OIDCSession

- run: aws sts get-caller-identity
shell: bash

OIDC - EKS दुरुपयोग

# Crate an EKS cluster (~10min)
eksctl create cluster --name demo --fargate
# Create an Identity Provider for an EKS cluster
eksctl utils associate-iam-oidc-provider --cluster Testing --approve

एक EKS क्लस्टर में OIDC प्रदाताओं को एक नए ओपन आईडी आईडेंटिटी प्रदाता के रूप में सेट करके सरलता से उत्पन्न किया जा सकता है। यह एक सामान्य डिफ़ॉल्ट नीति है:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789098:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:aud": "sts.amazonaws.com"
}
}
}
]
}

यह नीति सही ढंग से इस बात की निर्देशित कर रही है कि केवल आईएकेएस क्लस्टर जिसका आईडी 20C159CDF6F2349B68846BEC03BE031B है, वह भूमिका अनुमान कर सकता है। हालांकि, यह नहीं दिखा रहा है कि कौन सी सेवा खाता इसे अनुमान कर सकती है, जिसका मतलब है कि कोई भी सेवा खाता जिसके पास एक वेब पहचान टोकन है भूमिका अनुमान कर सकती है।

भूमिका अनुमान करने के लिए कौन सी सेवा खाता अनुमान कर सकती है, इसे निर्धारित करने के लिए, एक शर्त निर्दिष्ट करना आवश्यक है, जहां सेवा खाता नाम निर्दिष्ट है, जैसे:

"oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",

संदर्भ

हैकट्रिक्स का समर्थन करें

Last updated