¿Cómo permitir que el usuario cargue archivos en el depósito S3, pero no sobrescribir ni eliminar?


19

Tengo la siguiente política de IAM para un usuario

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1395161912000",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:PutObject",
        "s3:*"
      ],
      "Resource": [
        "arn:aws:s3:::bucketname"
      ]
    },
    {
      "Sid": "list",
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    }
  ]
}

El objetivo es permitir que el usuario cargue archivos en el depósito, pero no sobrescribir ni eliminar. Es para respaldo. Comencé con ListBuckety PutObject, pero agregué *ya que no funcionó. Ni siquiera *permite al usuario cargar archivos, solo obtenerlos Access Denied.

Cuando intento el simulador, devuelve Denied - Implicitly denied (no matching statements found).a ListBucket, que parece extraño ya que he permitido que implícitamente.

He probado tanto Cyberduck como 3Hub como clientes S3.

¿Alguna idea de lo que está mal?

Respuestas:


25

Al elaborar políticas de Amazon IAM para Amazon S3 , debe tener en cuenta la diferencia entre Operaciones en el Servicio (por ejemplo, ListAllMyBuckets ), Operaciones en Buckets (por ejemplo, ListBucket ) y Operaciones en Objetos (por ejemplo, GetObject ).

En particular, la Resourceespecificación de su política debe abordar las entidades objetivo apropiadas de acuerdo con los siguientes patrones (consulte, por ejemplo, las distintas Políticas de ejemplo para Amazon S3 ):

  • Operaciones en servicio - arn:aws:s3:::*
  • Operaciones en cubos - arn:aws:s3:::<bucket>
  • Operaciones en objetos - arn:aws:s3:::<bucket>/<object>

Solución

Se está encontrando Access Denied, porque ha especificado un recurso de nivel de depósito para PutObject, que requiere una especificación de recurso de nivel de objeto como arn:aws:s3:::<bucket>/*, en consecuencia, la siguiente política debería cubrir su caso de uso de muestra:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::bucketname"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::bucketname/*"
      ]
    }
  ]
}

1
Increíble, eso funcionó a la perfección. ¡Gracias! ¿Entonces sidno es obligatorio?
Znarkus

1
Según Sid , es un identificador opcional que usted proporciona para la declaración de política , que debe ser único dentro de una política . Dado que parece funcionar bien sin (pero ver más abajo), tiendo a eliminarlo aquí por brevedad y al versionar políticas, pero no me molesto al generar políticas automáticamente, por ejemplo, sin embargo, según la Nota siguiente : Algunos servicios de AWS (por ejemplo, Amazon SQS o Amazon SNS) puede requerir este elemento [...] .
Steffen Opel

3
OP dice que quiere "permitir que el usuario cargue archivos en el bucket, pero no sobrescribir o eliminar", pero esta política otorga PutObject, lo que permite anular objetos, ¿no? Creo que no hay forma de separar eso.
Xiong Chiamiov

2
@XiongChiamiov: la acción 'PutObject' de S3 de hecho implica sobrescribir, es simplemente cómo funciona S3 de forma predeterminada. Si necesita protección contra la eliminación accidental, es posible que desee considerar el uso de versiones para preservar, recuperar y restaurar cada versión de cada objeto almacenado en su bucket de Amazon S3. - esto le permite recuperarse fácilmente tanto de acciones no deseadas del usuario como de fallas de la aplicación .
Steffen Opel

44
Sí, el control de versiones le brinda la capacidad de recuperar objetos que se han sobrescrito (pero debe descubrir que lo han estado y luego hacer eso). De todos modos, -1 porque no proporciona una respuesta precisa a la pregunta.
Xiong Chiamiov
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.