Existe-t-il une politique S3 pour limiter l'accès à un seul seau?
j'ai un seau simple qui ressemble à images.mysite.com
sur mon S3 et d'autres seaux contenant des sauvegardes, etc.
je veux permettre à un utilisateur spécifique d'accéder au seau images.mysite.com
afin de télécharger des images. Cependant, je ne veux pas qu'il voie les autres seaux; pas même qu'ils existent.
Je ne pouvais pas faire une politique qui fait cela; chaque fois que je tente quelque chose de restrictif, il finit par bloquer la liste des seaux.
21 réponses
j'ai essayé cela pendant un certain temps et finalement trouvé une solution de travail. Vous devez utiliser différentes "Ressources" selon le type d'action que vous effectuez. J'ai aussi inclus des actions manquantes dans la réponse précédente (comme DeleteObject
) et des restrictions supplémentaires (comme PutBucketAcl
).
la Politique IAM suivante fonctionne pour moi maintenant:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:ListBucketMultipartUploads"
],
"Resource": "arn:aws:s3:::itnighq",
"Condition": {}
},
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectVersion",
"s3:GetObjectVersionAcl",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectVersionAcl"
],
"Resource": "arn:aws:s3:::itnighq/*",
"Condition": {}
},
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*",
"Condition": {}
}
]
}
les actions concernant un seau et celles concernant les objets doivent avoir arn différente.
notre cas d'utilisation: Fournir un espace de sauvegarde pour les clients de notre application cloud qui peut être accédé par les clients directement en utilisant les outils S3 communs. Bien sûr, aucun client ne devrait voir ce que les autres clients ont.
comme cloudberryman a expliqué ," vous pouvez soit énumérer tous les seaux ou aucun.", nous avons donc à venir avec un travail autour de. Background:
accorder à ListAllMyBuckets des droits à l'utilisateur est nécessaire afin que la console AWS S3 ou s3fox se connecter sans message d'erreur. Mais ListAllMyBuckets répertorie tous les seaux, indépendamment des ressources attribuées (en fait, seulement arn:...:::* travail.) C'est un gros insecte, si vous voulez mon avis. Btw. refuser ListBucket pour tous les seaux ne les empêche pas d'être listés, car ListBucket accorde des droits pour lister le contenu du seaux.
il y a 3 possibilités que je considère comme un travail autour. J'ai choisi la dernière.
(1) utiliser des noms de seau cryptiques, p.ex. des GUIDs
Avantage: Facile à configurer
Inconvénient: difficile à gérer, surtout pour le client. (imaginez trouver un guide spécifique parmi des milliers d'autres.), Indique également le nombre de seaux = nombre de clients utilisant le service de sauvegarde.
(2) Utiliser un seau avec des dossiers client spécifiques
C'est ainsi Qu'Amazon suggère par leurs exemples S3/IAM de fournir de l'espace auquel seuls certains utilisateurs ou groupes d'utilisateurs peuvent accéder. Voir: AWS Exemple IAM Politiques
avantage: assez facile à mettre en place, va avec des idées AWS
désavantage: forces pour rendre l'existence de tous les seaux publique, afin que le client puisse trouver leur "maison" seau. AWS accounting fournit des statistiques sur l'utilisation de seau, mais pas sur l'utilisation de dossier, ce qui rend difficile de calculer le coût par client.
(3) n'accordent pas de droit d'accès pour ListAllMyBuckets
Avantage: vous obtenez ce que vous voulez: les clients ne peuvent pas voir les seaux des autres clients
Inconvénient: le client ne peut pas voir son propre seau. S3Browser est livré avec un beau message "ne peut pas faire" et demande le nom de seau pour entrer. S3Fox envoie un message d'erreur lors de la connexion à la racine, mais permet une navigation directe vers le seau du client si le nom du seau est connu. Amazon S3 console ne fonctionne pas du tout.
Espère que cela a aidé à gérer S3 IAM que vous en avez besoin.
essayez cette politique. prenez également en compte qu'il n'y a aucun moyen de laisser la liste des utilisateurs que seau sélectionné. Vous pouvez énumérer tous les seaux ou aucun.
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:GetObjectAcl",
"s3:PutObjectAcl",
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:PutBucketAcl",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::your_bucket_here/*",
"Condition": {}
},
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*",
"Condition": {}
}
]
}
il n'est pas possible de fournir l'accès à la Console S3 sans accorder la permission ListAllMyBuckets
.
dans mon cas (et peut-être le vôtre aussi, futur lecteur) une alternative acceptable est de rediriger les utilisateurs sur la connexion directement dans le seau que vous souhaitez qu'ils voient.
pour ce faire, ajoutez ce qui suit à votre signe IAM dans l'url:
/s3/?bucket=bucket-name
Full URL de connexion (remplacer votre-alias et godet-name ):
https://your-alias.signin.aws.amazon.com/console/s3/?bucket=bucket-name
Politique IAM (remplacer seau-nom ):
{
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
}
]
}
pour plus d'informations sur la façon de créer des permissions spécifiques au seau pour les utilisateurs, lisez ce blog: http://mikeferrier.com/2011/10/27/granting-access-to-a-single-s3-bucket-using-amazon-iam /
j'interprète cette question comme suit:" puis-je permettre l'accès à un seau où aucun autre seau ne sera accessible et donc invisible."Parce que, montrer le nom du seau auquel aucun accès n'a été accordé équivaut toujours à une fuite d'information.
et la bonne réponse est non. La permission requise est ListAllMyBuckets qui permettra à l'utilisateur de voir tous les seaux. En omettant cette permission, la console sera inutilisable.
il y a un grand moyen pour permettre aux utilisateurs d'accéder à un seau spécifique sans comprendre la connaissance d'autres seaux. Une stratégie de groupe qui est comme celui-ci permettra aux utilisateurs de ne voir que les "seau". Le seul inconvénient est que l'utilisateur ne pourra jamais accéder au seau que s'il se connecte à l'extrémité du seau donné. Dans l'exemple ci-dessous: bucket-a.s3.amazonaws.com. Le seau peut aussi avoir des "utilisateurs authentifiés" autorisés pour que cela se produise.
{
"Statement": [
{
"Sid": "<EXAMPLE_SID>",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::bucket-a"
]
},
{
"Sid": "<EXAMPLE_SID>",
"Action": "s3:*",
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::bucket-a/*"
]
}
]
}
cette méthode a été testée avec Cyberduck sur Mac OS/X et en utilisant le paquet s3cmd
./s3cmd ls s3://bucket-a --access_key=ACCESS_KEY --secret_key=SECRET_KEY --bucket-locat
ion=ap-southeast-2
confus au sujet de pourquoi aucune réponse a été vérifiée?
décomposons chaque énoncé de politique des solutions ci-dessus:
cet énoncé de politique de s'applique au contenu du seau, mais pas au seau lui-même. C'est probablement et non ce que la question demandait, parce que vous ne pouvez pas voir ce qu'il y a dans le seau.
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:GetObjectAcl",
"s3:PutObjectAcl",
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:PutBucketAcl",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::your_bucket_here/*",
"Condition": {}
}
ces deux énoncé de politique de dérivé de donne accès en lecture seule au seau à ( arn:aws:s3:::your_bucket_here/
) readonly , mais permet toujours CRUD ops sur le contenu du seau( arn:aws:s3:::your_bucket_here/*
).
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:ListBucketMultipartUploads"
],
"Resource": "arn:aws:s3:::your_bucket_here",
"Condition": {}
},
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectVersion",
"s3:GetObjectVersionAcl",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectAclVersion"
],
"Resource": "arn:aws:s3:::your_bucket_here/*",
"Condition": {}
}
cependant, la Politique inclut l'énoncé ci-dessous, qui permet à un utilisateur de voir tous les seaux à l'extrémité. C'est probablement pas ce que la question demandait.
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*",
"Condition": {}
}
cependant, le ci-dessus très utile si vous utilisez un client qui navigue un magasin S3. Si votre client accède directement au magasin et non au seau, vous devez donc accéder à la liste des seaux à la racine.
probablement le cas d'utilisation le plus simple:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::bucket-name"]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::bucket-name/*"]
}
]
}
il y a moyen ou solution facile de faire cela en utilisant des organisations AWS. AWS organization vous permet d'avoir plusieurs comptes d'utilisateur. Votre compte principal pourra avoir plusieurs comptes AWS (Sub) et quels que soient les services(S3/EC2/*) qui sont ajoutés dans n'importe quel compte AWS, seules les ressources seront visibles.
consultez https://aws.amazon.com/blogs/aws/aws-organizations-policy-based-management-for-multiple-aws-accounts/ https://aws.amazon.com/organizations /
j'ai réussi à faire marcher ce qui suit. Signifie que la liste d'autres seaux a reçu L'Accès refusé message. Mais était toujours capable de voir le seau que je voulais si j'ai relié avec le nom du seau mis comme chemin.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets"
],
"Resource": "arn:aws:s3:::test"
},
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::test"]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::test/*"]
}
]
}
J'utilisais Cyberduck pour tester cette connexion.
bien qu'il ne soit pas possible de restreindre l'action s3:ListAllMyBuckets
à des seaux spécifiques, comme pour les contournements, vous pouvez leur envoyer L'URL de la Console pour un seaux spécifique, par exemple
-
https://s3.console.aws.amazon.com/s3/buckets/BUCKET_NAME/
Source: liste limitative des S3 buckets de la Console S3
pour cela, vous devez spécifier la politique suivante: document pour un utilisateur ou un groupe donné:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:ListBucketMultipartUploads"
],
"Resource": [
"arn:aws:s3:::my-bucket-1",
"arn:aws:s3:::my-bucket-2"
]
},
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectVersion",
"s3:GetObjectVersionAcl",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectVersionAcl"
],
"Resource": [
"arn:aws:s3:::my-bucket-1/*",
"arn:aws:s3:::my-bucket-2/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets"
],
"Resource": "arn:aws:s3:::*"
}
]
}
où my-bucket-1
et my-bucket-2
sont vos seaux pour donner l'accès lire et écrire.
Related:
- Écrit IAM Politiques: Comment Accorder l'Accès à un compartiment Amazon S3
- restreindre la liste des seaux pour un utilisateur spécifique
- comment fournir à un utilisateur pour accéder seulement à un seau particulier dans AWS S3?
- spécifiant des ressources dans une politique & Permissions relatives aux opérations sur godets
comme il a été bien discuté ci-dessus, la liste d'un seul seau sur la console n'est pas possible. Mais si l'accès de S3 bucket est attaché à un IAM, IAM peut accéder directement au bucket si URL to bucket est disponible. S3 bucket url sera comme:
https://s3.console.aws.amazon.com/s3/buckets/BucketName
où BucketName est le nom de bucket IAM a accès à
C'est détaillé par Amazon sur http://blogs.aws.amazon.com/security/post/Tx3VRSWZ6B3SHAV/Writing-IAM-Policies-How-to-grant-access-to-an-Amazon-S3-bucket
la solution ci-dessous a fonctionné pour moi. Je voulais une politique d'accès à un utilisateur spécifique my_iam_user sur un compartiment spécifique mon-s3-seau .
cette politique permet à mon utilisateur de lister, supprimer, obtenir E mettre des fichiers sur un seau S3 spécifique.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListBucket",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/my_iam_user"
},
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::my-s3-bucket"
},
{
"Sid": "AddDeleteFiles",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/my_iam_user"
},
"Action": [
"s3:DeleteObject",
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-s3-bucket/*"
}
]
}
j'ajoute juste un besoin similaire, résolu par ceci:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:Put*",
"s3:DeleteObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-bucket-name",
"arn:aws:s3:::my-bucket-name/*"
]
}
]
}
j'utilise les trucs suivants pour cacher le contenu de bucket d'autres utilisateurs. Cela aide non seulement à cacher d'autres seaux (N'utilisez pas ListAllMyBuckets), mais aussi des dossiers dans le même seau, lorsque vous faites un seau, mais que vous voulez avoir des sous-dossiers dans l'attribution des permissions appropriées à L'utilisateur/sous-dossier IAM.
la politique suivante est appliquée au groupe IAM et tous les utilisateurs sont dans ce groupe. Vous devez prendre aws:userid
et faire un sous-dossier avec le même nom dans le seau.
UserID peut être pris: aws iam get-user --user-name "user_name_for_folder_access":
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::bucket_name/${aws:userid}/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bucket_name"
]
}
]
}
ajouter une clause Deny
pour le ou les godets auxquels vous ne voulez pas accéder. Rappelez-vous qu'ils pourraient encore être cités, mais vous ne serez pas en mesure d'accéder au contenu à l'intérieur.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] } ] }
ça a été parfait pour moi . L'utilisateur peut Télécharger, Télécharger et obtenir la liste des dossiers mais ne pourra pas voir des dossiers d'autre seau.
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:GetObjectAcl",
"s3:PutObjectAcl",
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:PutBucketAcl",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::mybucketname/*",
"Condition": {}
},
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*",
"Condition": {}
},
{
"Effect": "Deny",
"Action": [
"s3:DeleteBucket",
"s3:DeleteBucketPolicy",
"s3:DeleteBucketWebsite",
"s3:DeleteObject",
"s3:DeleteObjectVersion"
],
"Resource": "arn:aws:s3:::mybucketname/*",
"Condition": {}
}
]
}
une bonne solution simple que nous avons trouvé est de bloquer l'utilisateur pour se connecter au répertoire racine. Ils doivent donc se connecter avec le chemin distant défini au dossier désiré.
{
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::folder-name*",
"Condition": {}
}
]
}
- créer l'utilisateur.
- cliquez sur Utilisateur créé sous L'écran de gestion IAM.
- cliquez sur Ajouter des permissions.
- cliquez sur joindre directement les polices existantes. "151920920 cliquez sur" créer une stratégie.
- sélectionnez JSON, coller ci-dessous JSON remplacer bucket_name avec votre nom de seau.
- cela permet à cet utilisateur particulier de voir,Mettre et obtenir des objets de ce seau seulement.
{
{"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bucket_name"
]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::bucket_name/*"
]
}
]}
}
Non, il n'est pas actuellement possible de limiter les utilisateurs à voir les seaux sélectifs sous root ou ailleurs. Tu n'as que ces trois options maintenant.
j'ai choisi de demander au client d'utiliser le seau explicitement le nom.