Je suis en train de configurer une sélection de compartiments S3 et souhaite restreindre leur accès à un VPC tout en autorisant l'accès aux compartiments depuis la console AWS.
Comme proposé ici J'ai créé un point de terminaison S3 et l'ai également ajouté à la table de routage principale. La politique sur le point de terminaison permet un accès complet à toutes les ressources.
J'ai créé une politique S3 (voir ci-dessous) et l'ai ajoutée au compartiment. Dès que j'enregistre la politique, l'accès au bucket depuis la console n'est plus possible.
J'ai également essayé d'ajouter spécifiquement un utilisateur à la condition "StringNotEquals" sous la forme "aws: username": "user1", en vain.
{
"Version": "2012-10-17",
"Id": "Policy-S3-Bucket-myBucket",
"Statement": [
{
"Sid": "Access-via-VPC-only",
"Principal": "*",
"Action": "s3:*",
"Effect": "Deny",
"Resource": [
"arn:aws:s3:::myBucket",
"arn:aws:s3:::myBucket/*"
],
"Condition": {
"StringNotEquals": {
"aws:sourceVpc": "vpc-01c9d66c12345"
}
}
},
{
"Sid": "Allow-console-access",
"Action": [
"s3:*"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::myBucket",
"arn:aws:s3:::myBucket/*"
],
"Principal": {
"AWS": [
"arn:aws:iam::<account-id>:user/user1", "arn:aws:iam::<account-id>:user/user2"
]
}
}
]
}
3 Réponses :
J'ai trouvé une solution qui semble fonctionner. Je l'ai testé dans le simulateur de politique et il semble également fonctionner correctement dans l'environnement en direct. La politique suivante fait l'affaire:
{
"Version": "2012-10-17",
"Id": "Policy-S3-Bucket-myBucket",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:username": ["user1", "user2"]
}
}
},
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::myBucket"],
"Condition": {
"StringEquals": {
"aws:sourceVpc": "vpc-01c9d66c12345"
}
}
},
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::myBucket"],
"Condition": {
"StringEquals": {
"aws:username": ["user1", "user2"]
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": ["arn:aws:s3:::myBucket/*"],
"Condition": {
"StringEquals": {
"aws:sourceVpc": "vpc-01c9d66c12345"
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": ["arn:aws:s3:::myBucket/*"],
"Condition": {
"StringEquals": {
"aws:username": ["user1", "user2"]
}
}
}
]
}
La politique exige que la chaîne sourceVpc OU le nom d'utilisateur soit comme indiqué dans la condition.
Certes, la politique est verbeuse et il y a une quantité substantielle de réplication. Si quelqu'un a une idée pour résoudre ce problème plus efficacement, je suis tout à fait à l'écoute.
Notez que cette stratégie autorise l'accès à partir de vpc-01c9d66c12345 mais n'empêche pas l'accès à partir d'autres VPC. Donc, dans ce sens, il ne "restreint pas l'accès [aux compartiments S3] à un VPC", ce qui était l'une de vos exigences déclarées. Cela peut être acceptable, à moins que vous n'ayez vraiment besoin d'empêcher l'accès à partir d'autres VPC - comme écrit, toute personne avec s3: *, par exemple, peut accéder à ce compartiment à partir d'un VPC différent.
Hmm, ce n'est pas l'intention alors. Qu'est-ce qui vous indique que les buckets sont accessibles à partir d'autres VPC? Cela ne devrait fonctionner que si vous êtes l'un des utilisateurs spécifiés, n'est-ce pas? Donc, si vous êtes dans le VPC mentionné OU si vous êtes utilisateur1 ou utilisateur2, vous avez accès, sinon vous n'avez pas ... n'est-ce pas?
La stratégie efficace au moment de l'exécution est une combinaison de la stratégie de compartiment S3 et de la stratégie IAM du client. Si le client dispose d'une stratégie IAM autorisant s3: * contre ressource: *, par exemple, il peut écrire dans ce compartiment S3 - rien dans la stratégie de compartiment ne refusera cet accès IAM. La politique du compartiment S3 ne l'autorise pas explicitement, mais elle ne la refuse pas non plus explicitement et la politique IAM l'autorisera. L'évaluation de la politique est un refus explicite> une autorisation explicite> un refus implicite. Par défaut, en l'absence de règles, tout est un refus implicite, comme vous vous en doutez.
L'astuce semble être de tout nier sauf si cela vient de l'utilisateur ou du VPC, mais il doit être dans le même état. Le fonctionnement des stratégies est que les règles de refus précèdent toutes les autres règles, donc si vous refusez, vous ne pouvez pas autoriser une règle ultérieure; c'est déjà refusé et c'est tout.
Au fait, l'aws: userid de l'utilisateur root est l'ID de compte. Probablement une mauvaise pratique d'utiliser cet utilisateur, mais bon: P
Donc, mon compartiment n'accepte désormais que le trafic du VPC et de l'utilisateur auquel je me connecte via la console Web AWS (donc je n'ai pas accès a refusé les erreurs dans la console Web)
{
"Version": "2012-10-17",
"Id": "Policy154336817545456388",
"Statement": [
{
"Sid": "Block-if-not-from-VPC-or-Me",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-4598ujfjrhc",
"aws:userid": "576767373466"
}
}
}
]
}
Cette politique a été testée et donne exactement ce dont vous avez besoin:
Statement": {
"Sid": "Allow-anonymous-access-from-specific-VPC",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket_name/*",
"Condition": {
"StringEquals": {
"aws:SourceVpc": "some-vpc-id"
}
}
}
Cela permettra l'accès anonyme à partir des requêtes provenant de "some-vpc-id", tout en autorisant l'accès depuis la console AWS.
Votre VPC doit avoir un point de terminaison S3 configuré pour que cela fonctionne.
Lorsque vous dites que vous souhaitez autoriser l'accès à partir de la console, voulez-vous vraiment dire cela ou voulez-vous dire que vous voulez que le compartiment S3 soit accessible à un utilisateur IAM spécifique (quel que soit le mécanisme utilisé, que ce soit la console, le SDK, AWSCLI )? Votre tentative de politique suggère ce dernier.
Plus précisément, je souhaite rendre les compartiments S3 disponibles aux utilisateurs administratifs (IAM) à l'aide de la console AWS. Cela signifie modifier la configuration du compartiment, modifier la stratégie, etc. directement dans la console. Actuellement, ce n'est pas possible. L'accès via SDK et AWSCLI serait également une bonne chose, même si je ne sais pas comment y parvenir. Sur le front SDK / CLI, j'utiliserais des rôles pour cela (encore une fois, je dois déterminer quelle est la bonne façon de le faire)
Pourriez-vous tester une politique contenant uniquement la première instruction 'deny' (en supprimant l'instruction 'allow' que vous avez actuellement) et modifier la condition en: "StringNotEquals": {"aws: sourceVpce": "vpc-01c9d66c12345", "aws : username ":" user1 "," aws: username ":" user2 "}. Idéalement, testez cela sur un nouveau seau dont vous ne vous souciez pas, juste au cas où.
J'ai essayé ça. Il semble que cela aboutirait à une instruction AND, pas à un OR. Pour autant que je l'ai compris, vous pouvez avoir plusieurs valeurs pour une seule clé, ces valeurs sont évaluées comme «OU». Deux clés, en revanche, sont évaluées comme un ET. Ainsi, ce qui précède nécessiterait que les deux instructions "aws: sourceVpce" = "vpc-01c9d66c12345" AND "aws: username" = "user1" soient vraies.
Oui, c'est un ET. Cependant, la politique que j'ai proposée ne fonctionnerait pas de toute façon car vous ne pouvez pas avoir plusieurs éléments aws: username dans la même condition.