salesforce/policy_sentryGénère des politiques IAM AWS du moindre privilège basées sur les ARNs de ressources et les niveaux d'accès, automatisant la création sécurisée de politiques pour l'infrastructure cloud.
Pour des tutoriels détaillés et la documentation complète, veuillez consulter le projet sur ReadTheDocs.
Consultez le billet du blog Salesforce Engineering sur Policy Sentry.
Rédiger manuellement des politiques IAM soucieuses de la sécurité peut être très fastidieux et inefficace. De nombreux développeurs d'Infrastructure as Code ont déjà vécu quelque chose comme cela :
Un tel processus n'est idéal ni pour la sécurité ni pour les développeurs d'Infrastructure as Code. Nous devons faciliter la rédaction sécurisée de politiques IAM et abstraire la complexité de la rédaction de politiques IAM à privilèges minimaux. C'est pourquoi j'ai créé cet outil.
Policy Sentry permet aux utilisateurs de créer des politiques IAM à privilèges minimaux en quelques secondes, plutôt que de les rédiger laborieusement à la main. Ces politiques sont restreintes en fonction des niveaux d'accès et des ressources. En cas d'intrusion, cela permet de limiter le champ d'explosion des informations d'identification compromises en n'accordant aux principaux IAM que l'accès à ce dont ils ont besoin.
Avant cet outil, il fallait des heures pour élaborer une politique IAM avec des contraintes d'ARN de ressource — mais maintenant, cela peut prendre quelques secondes. Ainsi, les développeurs n'ont qu'à déterminer les ressources auxquelles ils ont besoin d'accéder, et Policy Sentry abstrait la complexité des politiques IAM de leurs processus de développement.
La fonctionnalité phare de Policy Sentry est qu'il peut créer des politiques IAM basées sur les ARN de ressources et les niveaux d'accès. Notre fonctionnalité CRUD adopte l'approche directive selon laquelle les développeurs d'IaC ne devraient pas avoir à comprendre les complexités d'AWS IAM - nous devrions abstraire la complexité pour eux. En fait, les développeurs devraient simplement pouvoir dire...
arn:aws:s3:::example-org-sbx-vmimport"arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret"arn:aws:ssm:us-east-1:123456789012:parameter/test"...et notre automatisation devrait créer des politiques correspondant à ces niveaux d'accès.
Comment y parvenons-nous ? Eh bien, Policy Sentry s'appuie sur la documentation AWS sur les Actions, Ressources et Conditions Keys pour rechercher les actions, les niveaux d'accès et les types de ressources, et génère des politiques en fonction des ARN et des niveaux d'accès. Considérez l'extrait de tableau ci-dessous :
| Actions | Niveau d'accès | Types de ressources |
|---|---|---|
| ssm:GetParameter | Lecture | parameter |
| ssm:DescribeParameters | Liste | parameter |
| ssm:PutParameter | Écriture | parameter |
| secretsmanager:PutResourcePolicy | Gestion des autorisations | secret |
| secretsmanager:TagResource | Étiquetage | secret |
Policy Sentry agrège toute cette documentation dans une base de données unique et utilise cette base pour générer des politiques en fonction des actions, des ressources et des niveaux d'accès.
brew tap salesforce/policy_sentry https://github.com/salesforce/policy_sentry
brew install policy_sentry
pip3 install --user policy_sentry
Pour activer l'autocomplétion Bash, placez ceci dans votre .bashrc :
eval "$(_POLICY_SENTRY_COMPLETE=bash_source policy_sentry)"
Pour activer l'autocomplétion ZSH, placez ceci dans votre .zshrc :
eval "$(_POLICY_SENTRY_COMPLETE=zsh_source policy_sentry)"
policy_sentry create-template --output-file crud.yml --template-type crud
mode: crud
name: ''
# Specify resource ARNs
read:
- ''
write:
- ''
list:
- ''
tagging:
- ''
permissions-management:
- ''
# Actions that do not support resource constraints
wildcard-only:
single-actions: # standalone actions
- ''
# Service-wide - like 's3' or 'ec2'
service-read:
- ''
service-write:
- ''
service-list:
- ''
service-tagging:
- ''
service-permissions-management:
- ''
# Skip resource constraint requirements by listing actions here.
skip-resource-constraints:
- ''
# Exclude actions from the output by specifying them here. Accepts wildcards, like kms:Delete*
exclude-actions:
- ''
# If this policy needs to include an AssumeRole action
sts:
assume-role:
- ''
assume-role-with-saml:
- ''
assume-role-with-web-identity:
- ''
mode: crud
read:
- 'arn:aws:ssm:us-east-1:123456789012:parameter/myparameter'
write:
- 'arn:aws:ssm:us-east-1:123456789012:parameter/myparameter'
list:
- 'arn:aws:ssm:us-east-1:123456789012:parameter/myparameter'
tagging:
- 'arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret'
permissions-management:
- 'arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret'
policy_sentry write-policy --input-file crud.yml
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SsmReadParameter",
"Effect": "Allow",
"Action": [
"ssm:GetParameter",
"ssm:GetParameterHistory",
"ssm:GetParameters",
"ssm:GetParametersByPath",
"ssm:ListTagsForResource"
],
"Resource": [
"arn:aws:ssm:us-east-1:123456789012:parameter/myparameter"
]
},
{
"Sid": "SsmWriteParameter",
"Effect": "Allow",
"Action": [
"ssm:DeleteParameter",
"ssm:DeleteParameters",
"ssm:LabelParameterVersion",
"ssm:PutParameter"
],
"Resource": [
"arn:aws:ssm:us-east-1:123456789012:parameter/myparameter"
]
},
{
"Sid": "SecretsmanagerPermissionsmanagementSecret",
"Effect": "Allow",
"Action": [
"secretsmanager:DeleteResourcePolicy",
"secretsmanager:PutResourcePolicy"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret"
]
},
{
"Sid": "SecretsmanagerTaggingSecret",
"Effect": "Allow",
"Action": [
"secretsmanager:TagResource",
"secretsmanager:UntagResource"
],
"Resource": [
"arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret"
]
}
]
}
Remarquez comment la politique ci-dessus reconnaît les ARN fournis par l'utilisateur, ainsi que le niveau d'accès demandé. Par exemple, le SID SecretsmanagerTaggingSecret contient des actions d'étiquetage assignées uniquement au type de ressource secret.
Cela accélère considérablement le temps de développement des politiques IAM et garantit que toutes les politiques créées limitent l'accès exactement à ce dont votre rôle a besoin. Ainsi, les développeurs n'ont qu'à déterminer les ressources auxquelles ils ont besoin d'accéder, et nous abstraions la complexité des politiques IAM de leurs processus de développement.
# Créez d'abord des modèles !!! Ainsi vous pouvez simplement coller les valeurs nécessaires sans vous souvenir du format YAML
# Mode CRUD
policy_sentry create-template --output-file tmp.yml --template-type crud
# Mode Actions
policy_sentry create-template --output-file tmp.yml --template-type actions
# Écrire une politique basée sur les niveaux d'accès spécifiques aux ressources
policy_sentry write-policy --input-file examples/yml/crud.yml
# Écrire une politique basée sur une liste d'actions
policy_sentry write-policy --input-file examples/yml/actions.yml
###############
# Table des actions
###############
# REMARQUE : utilisez --fmt yaml ou --fmt json pour changer le format de sortie. Par défaut json pour les requêtes
# Obtenir la liste des actions qui ne supportent pas les contraintes de ressources
policy_sentry query action-table --service s3 --resource-type "*" --fmt yaml
# Obtenir la liste des actions au niveau "Écriture" dans S3 qui ne supportent pas les contraintes de ressources
policy_sentry query action-table --service s3 --access-level write --resource-type "*" --fmt yaml
# Obtenir la liste de toutes les actions IAM dans TOUS les services ayant un accès "Gestion des autorisations"
policy_sentry query action-table --service all --access-level permissions-management
# Obtenir la liste de toutes les actions IAM disponibles pour le service RAM
policy_sentry query action-table --service ram
# Obtenir les détails de l'action IAM `ram:TagResource`
policy_sentry query action-table --service ram --name tagresource
# Obtenir la liste de toutes les actions IAM du service RAM ayant le niveau d'accès Gestion des autorisations.
policy_sentry query action-table --service ram --access-level permissions-management
# Obtenir la liste de toutes les actions IAM du service SES supportant la condition key `ses:FeedbackAddress`.
policy_sentry query action-table --service ses --condition ses:FeedbackAddress
###########
# Table des ARN
###########
# Obtenir la liste de tous les formats d'ARN bruts disponibles pour le service SSM.
policy_sentry query arn-table --service ssm
# Obtenir le format d'ARN brut pour l'ARN `cloud9` avec le nom court `environment`
policy_sentry query arn-table --service cloud9 --name environment
# Obtenir les paires clé/valeur de tous les formats d'ARN bruts avec leurs noms courts
policy_sentry query arn-table --service cloud9 --list-arn-types
######################
# Table des conditions keys
######################
# Obtenir la liste de toutes les conditions keys disponibles pour le service Cloud9
policy_sentry query condition-table --service cloud9
# Obtenir les détails sur la condition key intitulée `cloud9:Permissions`
policy_sentry query condition-table --service cloud9 --name cloud9:Permissions
# Initialiser le dossier de configuration policy_sentry et créer les tables de la base IAM.
policy_sentry initialize
# Récupérer la version la plus récente de la documentation AWS pour pouvoir expérimenter avec les nouveaux services.
policy_sentry initialize --fetch
# Remplacer les niveaux d'accès en spécifiant vos propres niveaux d'accès (exemple : correction des niveaux de Gestion des autorisations)
policy_sentry initialize --access-level-overrides-file ~/.policy_sentry/overrides-resource-policies.yml
policy_sentry initialize --access-level-overrides-file ~/.policy_sentry/access-level-overrides.yml
create-template : Crée les modèles de fichiers YML pour les utiliser dans les types de commandes write-policy.
write-policy : Utilise un fichier YAML pour écrire des politiques à votre place
query : Interrogez les tables de la base IAM. Cela peut être utile pour remplir les modèles Policy Sentry, ou simplement pour requêter la base pour une connaissance rapide.
action-table)arn-table)condition-table)initialize : (Optionnel). Crée une base de données SQLite qui contient tous les services disponibles via la documentation Actions, Ressources et Conditions Keys. Voir la documentation.
Si vous développez votre propre code Python et souhaitez importer Policy Sentry en tant que package tiers, vous pouvez ignorer l'initialisation et utiliser le fichier de base de données local fourni avec le package Python lui-même.
C'est particulièrement utile pour les développeurs qui souhaitent exploiter les capacités de Policy Sentry nécessitant l'utilisation de la base IAM (comme interroger la table de la base IAM). Ainsi, vous n'avez pas besoin d'initialiser la base de données et pouvez la requêter immédiatement.
L'exemple de code se trouve ici. Il est également reproduit ci-dessous.
from policy_sentry.querying.actions import get_actions_for_service
def example():
actions = get_actions_for_service('cloud9') # Vous pouvez ensuite utiliser toute méthode nécessitant un accès à la base.
for action in actions:
print(action)
if __name__ == '__main__':
example()
Les résultats ressembleront à :
cloud9:CreateEnvironmentEC2
cloud9:CreateEnvironmentMembership
cloud9:DeleteEnvironment
cloud9:DeleteEnvironmentMembership
cloud9:DescribeEnvironmentMemberships
cloud9:DescribeEnvironmentStatus
cloud9:DescribeEnvironments
cloud9:GetUserSettings
cloud9:ListEnvironments
cloud9:ListTagsForResource
cloud9:TagResource
cloud9:UntagResource
cloud9:UpdateEnvironment
cloud9:UpdateEnvironmentMembership
cloud9:UpdateUserSettings
Si vous préférez utiliser Docker plutôt que d'installer le script avec Python, nous le supportons également. Depuis la racine du dépôt, utilisez ceci pour construire l'image Docker :
docker build -t kmcquade/policy_sentry .
Utilisez ceci pour exécuter quelques commandes de base :
# Commandes de base sans arguments
docker run -i --rm kmcquade/policy_sentry:latest "--help"
docker run -i --rm kmcquade/policy_sentry:latest "query"
# Interroger la base de données
docker run -i --rm kmcquade/policy_sentry:latest "query action-table --service all --access-level permissions-management"
La commande write-policy supporte également la transmission du fichier de configuration YML via STDIN. Si vous utilisez la méthode Docker, essayez-la ici :
# Écrire des politiques en transmettant la configuration via STDIN
cat examples/yml/crud.yml | docker run -i --rm kmcquade/policy_sentry:latest "write-policy"
cat examples/yml/actions.yml | docker run -i --rm kmcquade/policy_sentry:latest "write-policy"
Le module Terraform est publié et maintenu ici.