Identity Federation through SAML को कॉन्फ़िगर करने के लिए आपको केवल एक नाम प्रदान करना होगा और metadata XML जिसमें सभी SAML कॉन्फ़िगरेशन (endpoints, certificate with public key) शामिल हैं।
OIDC - Github Actions Abuse
Github action को Identity provider के रूप में जोड़ने के लिए:
Provider type के लिए, OpenID Connect चुनें।
Provider URL के लिए, https://token.actions.githubusercontent.com दर्ज करें।
प्रोवाइडर के thumbprint प्राप्त करने के लिए Get thumbprint पर क्लिक करें।
Audience के लिए, sts.amazonaws.com दर्ज करें।
Github action की जरूरत के अनुसार नया रोल बनाएं जिसमें अनुमतियाँ और ऐसी trust policy हो जो प्रोवाइडर पर भरोसा करे जैसे:
6. पिछली पॉलिसी में ध्यान दें कि कैसे केवल एक **शाखा** को **संगठन** के **रिपॉजिटरी** से विशिष्ट **ट्रिगर** के साथ अधिकृत किया गया था।
7. Github action द्वारा **नकली** किए जाने वाले **रोल** का **ARN** "सीक्रेट" होगा जिसे github action को जानना होगा, इसलिए इसे किसी **पर्यावरण** में **सीक्रेट** के रूप में **स्टोर** करें।
8. अंत में, वर्कफ़्लो द्वारा प्रयुक्त होने वाले AWS क्रेडेंशियल्स को कॉन्फ़िगर करने के लिए एक github action का उपयोग करें:
```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)eksctlcreatecluster--namedemo--fargate
# Create an Identity Provider for an EKS clustereksctlutilsassociate-iam-oidc-provider--clusterTesting--approve
एक EKS क्लस्टर में OIDC प्रोवाइडर्स को सिर्फ क्लस्टर के OIDC URL को नए Open ID Identity प्रोवाइडर के रूप में सेट करके जनरेट किया जा सकता है। यह एक सामान्य डिफ़ॉल्ट नीति है:
यह नीति सही ढंग से संकेत कर रही है कि केवलEKS क्लस्टर जिसकी id20C159CDF6F2349B68846BEC03BE031B है, वही भूमिका को मान सकता है। हालांकि, यह यह नहीं बता रहा है कि कौन सा सेवा खाता इसे मान सकता है, जिसका अर्थ है कि कोई भी सेवा खाता जिसके पास वेब पहचान टोकन है वह भूमिका को मानने में सक्षम होगा।
यह निर्दिष्ट करने के लिए कि कौन सा सेवा खाता भूमिका को मानने में सक्षम होना चाहिए, एक शर्त निर्दिष्ट करनी होगी जहां सेवा खाते का नाम निर्दिष्ट किया गया हो, जैसे कि: