4
votes

Accès Lambda refusé sur S3 PutObject

J'ai créé un nouveau compartiment S3 et laissé toutes les valeurs par défaut en place. J'essaie d'écrire un objet dans le seau à partir d'une fonction lambda en utilisant la méthode PutObject. Quelles que soient les politiques que j'attache ou ce que je fais, j'obtiens un "accès refusé" pour l'action, à moins de modifier l'ACL du bucket et de la rendre entièrement publique. Ce n'est évidemment pas une très bonne solution. Je ne sais vraiment pas ce qui se passe: je sais que j'ai déjà fait cela sans aucun réglage spécial. Les compartiments lambda et S3 sont tous deux dans le même compte, et le rôle attribué au lambda est associé à la stratégie AWSLambdaFullAccess. Je deviens fou, toute aide serait appréciée.

amazon-web-services aws-lambda amazon-s3

0 commentaires

4 Réponses :

1
votes

En fonction des ensembles d'autorisations que vous avez attribués à votre fonction Lambda, AWSLambdaFullAccess ne vous donnera pas accès à votre compartiment S3. Ce dont vous avez besoin en plus de ces autorisations, c'est d'autoriser l'accès à S3. Si PutObject est la seule autorisation dont vous avez besoin, la stratégie suivante peut être ajoutée à votre rôle Lambda. Gardez à l'esprit que ces autorisations peuvent être davantage verrouillées au niveau de la ressource, mais vous pouvez commencer par celles-ci:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1546988882992",
      "Action": [
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Vous pouvez ajouter ou supprimer d'autres autorisations S3 en fonction de vos besoins.

5 commentaires

J'ai copié ce qui précède dans une stratégie en ligne pour mon rôle lambda, mais je reçois toujours un "accès refusé". Pensées?

Malheureusement, "accès refusé" est le message d'erreur complet dans les journaux CloudWatch

Je ne pense pas que ce soit la meilleure pratique d'utiliser le joker ( * ) pour la clé "Resource" , c'est une manière permissive. J'ai eu exactement le même problème. Ma solution est ci-dessous.

@codeinaire Si vous lisez ma réponse, elle indique que l'OP peut «démarrer» avec cela et une fois qu'il a fait fonctionner sa fonction, il peut la «verrouiller» sur la ressource spécifique.

@captainblack ouais, je comprends ce que vous dites. La solution que vous proposez est applicable et flexible plus généralement mais ne répond pas spécifiquement à la question. L'OP a déclaré que la seule ressource à laquelle il souhaite appliquer l'action est un compartiment qui rend la solution que vous avez fournie générale. Je pense que la réponse que j'ai fournie était plus spécifique à la question du PO, mais pas aussi généralisable ou flexible que votre solution. Cela a-t-il du sens?

3
votes

Malheureusement, "s3: PutObject" ne suffit pas pour le faire fonctionner - vous continuerez à recevoir l'erreur 403 Accès refusé .

Vous devez ajouter la stratégie "s3: PutObjectAcl" à votre rôle Lambda.

0 commentaires

1
votes

J'avais exactement ce problème.

SOLUTION

J'ai résolu le problème avec la politique ci-dessous:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PetsS3Write",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<bucket name or wildcard if you want all buckets writable>/*"
        }
    ]
}

0 commentaires

0
votes

Vous devez modifier une stratégie pour le compartiment s3. Vous pouvez donc utiliser le code suivant:

  iamRoleStatements:
    - Effect: 'Allow'
      Action:
        - 's3:PutObject'
        - 's3:GetObject'
      Resource: "arn:aws:s3:::*/*"
    - Effect: 'Allow'
      Action:
        - 's3:ListBucket'
      Resource: "arn:aws:s3:::*"

Remarque: vous devez mettre le s3: PutObjecct en action. Je souhaite de l'aide pour vous.

0 commentaires