AWS - Federation Abuse
SAML
Для отримання інформації про SAML, будь ласка, перевірте:
Для налаштування ідентифікаційної федерації через SAML вам потрібно лише надати ім'я та метадані XML, що містять всю конфігурацію SAML (кінцеві точки, сертифікат з відкритим ключем)
OIDC - Зловживання діями Github
Для додавання дії Github як постачальника ідентифікації:
Для Типу постачальника виберіть OpenID Connect.
Для URL постачальника введіть
https://token.actions.githubusercontent.com
Натисніть на Отримати відбиток для отримання відбитка постачальника
Для Аудиторії введіть
sts.amazonaws.com
Створіть нову роль з дозволами, які потрібні дії Github, та політикою довіри, яка довіряє постачальнику, наприклад:
{ "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" } } } ] }
Зловживання OIDC - EKS
Можливо створити постачальників OIDC в кластері EKS, просто встановивши URL OIDC кластера як новий постачальник ідентифікації Open ID. Це загальна політика за замовчуванням:
Ця політика правильно вказує, що тільки кластер EKS з ідентифікатором 20C159CDF6F2349B68846BEC03BE031B
може припускати роль. Однак вона не вказує, який обліковий запис служби може це зробити, що означає, що БУДЬ-ЯКИЙ обліковий запис служби з токеном веб-ідентифікації зможе припускати роль.
Для того, щоб вказати, який обліковий запис служби повинен мати можливість припускати роль, потрібно вказати умову, де вказано ім'я облікового запису служби, наприклад:
References
Last updated