Amazon web services Amazon S3策略阻止创建根级别文件夹

我们希望防止S3用户在bucket的根目录中创建新文件夹。换句话说，他们必须使用bucket中的现有文件夹来上传或修改文件。如果愿意，他们可以选择在这些现有文件夹中创建子文件夹

注意：使用S3策略。用户可以选择任何现有文件夹。它们没有指定的文件夹

我知道S3将文件和文件夹都视为对象，所以我不确定这是否可以实现，但我相信社区的潜力

以下是我想要的：

Bucket名称：测试Bucket

操作：在测试bucket的根目录中创建文件夹。 期望结果：拒绝

操作：在测试bucket的根目录中上载随机文件。 期望结果：拒绝

操作：在测试bucket的现有folder1文件夹testbucket/folder1/file1中上载文件file1。 期望的结果：成功

操作：在测试bucket的现有folder1文件夹test bucket/folder1/sub-folder1/中创建文件夹sub-folder1。 期望的结果：成功

---

您的概念模型中存在缺陷

我知道S3将文件和文件夹都视为对象

这是不对的

以下是正确的版本：

S3服务和API没有文件夹的概念。 S3对象不是真正意义上的层次结构。 S3控制台是唯一具有文件夹概念的实体。 S3服务和API支持前缀、分隔符和公共前缀的概念。 当对API的列表对象请求带有指定前缀时，仅返回键以该前缀开头的对象，而不管前缀后的对象键中是否有/

当列表对象请求附带前缀和分隔符（通常为/）时，API仅返回其键与给定前缀匹配且在键中的请求中指定的前缀之后没有后续/的对象。这些类似于文件夹中的文件

与给定前缀匹配但在指定前缀/之后有后续前缀的任何对象的键的前缀合并为其前缀的唯一列表，并截断为其下一个/。这些是常见的前缀，类似于文件夹中的文件夹

但是，事实上，其他任何东西都没有真正意义

控制台通过向API读取列表对象请求中的公共前缀，并将其显示为文件夹，从而创建文件夹的幻觉

控制台允许您创建一个文件夹，这进一步加深了这种错觉——但实际上它不是一个文件夹，甚至不需要它。它只是一个带有最后一个字符为/的键的空对象。S3的正常操作不需要此对象，但创建此对象是为了方便，以便您可以导航到空文件夹并将文件上载到空文件夹中

然而，真正发生的是：

Console: "create folder foo in the root of the bucket"
API: PUT /foo/
     Content-Length: 0

Console: "click folder foo"
API: GET /?prefix=foo/&delimiter=/

Console: "upload file bar.txt inside folder foo"
API: PUT /foo/bar.txt

现在。。。如果您使用一个空的bucket，并且使用API而不是控制台，那么您只需放入/foo/bar.txt，就可以在控制台中得到完全相同的净结果-您会看到一个名为foo的文件夹，其中包含bar.txt。显示文件夹是因为有一个前缀为foo/的对象。删除该对象，文件夹将消失

相反，如果您使用控制台从顶部执行此操作，则一旦删除bar.txt，仍然会有文件夹foo，因为这实际上只是一个空对象，其唯一目的是在没有其他具有该公用前缀的对象时，使文件夹出现在控制台导航中

所以，不。。。S3不会将文件和文件夹都视为对象。S3控制台创建欺骗文件夹的对象，严格来说是为了帮助导航，这里的神奇之处在于对象的键以/。另一方面，如果这些空对象不在那里，控制台仍然显示对象，就好像它们在文件夹中一样

然后你就会看到问题的发展。S3服务不能被要求测试它不知道并且实际上不需要存在的东西

因此，技术上不可能完全按照你的要求去做；然而，似乎有一个有限的解决办法。主要限制是不能指定文件夹必须存在，但可以指定对象键前缀必须与预定义的模式集匹配

bucket或用户策略的相关部分可能如下所示

   "Action": "s3:PutObject",
   "Resource": [ 
      "arn:aws:s3:::examplebucket/taxdocuments/*",
      "arn:aws:s3:::examplebucket/personnel/*",
      "arn:aws:s3:::examplebucket/unicorns/*"
      ...
   ],

受此策略影响的用户将能够在ExampleBack bucket中创建以taxdocuments/或Personal/或unicorns/开头的任何对象，并且将无法创建没有这些前缀之一的对象。除此之外，只要这些前缀中的一个位于每个假文件夹的对象键的开头，就可以整天在文件夹中的文件夹中创建控制台文件夹

当然，限制是使另一个文件夹有资格访问需要修改策略

这也可能有效，但请谨慎行事：

"Resource": "arn:aws:s3:::examplebucket/?*/?*",

从直觉上看，这似乎可行，但缺陷h

---

ere-假设？*/？*有效，那么？与*不匹配0个字符-这允许用户在根目录中创建一个新的伪文件夹，只要他们使用API同时在其中创建名称至少有一个字符长的东西-也就是说，创建一个具有pics/cat.jpg键的对象时，如果pics文件夹不存在，则创建它，如上所述。从控制台上，这将阻止在根目录中创建新文件夹，但从API上，它不会施加此类限制。

您的概念模型中存在缺陷

我知道S3将文件和文件夹都视为对象

这是不对的

以下是正确的版本：

S3服务和API没有文件夹的概念。 S3对象不是真正意义上的层次结构。 S3控制台是唯一具有文件夹概念的实体。 S3服务和API支持前缀、分隔符和公共前缀的概念。 当对API的列表对象请求带有指定前缀时，仅返回键以该前缀开头的对象，而不管前缀后的对象键中是否有/

当列表对象请求附带前缀和分隔符（通常为/）时，API仅返回其键与给定前缀匹配且在键中的请求中指定的前缀之后没有后续/的对象。这些类似于文件夹中的文件

与给定前缀匹配但在指定前缀/之后有后续前缀的任何对象的键的前缀合并为其前缀的唯一列表，并截断为其下一个/。这些是常见的前缀，类似于文件夹中的文件夹

但是，事实上，其他任何东西都没有真正意义

控制台通过向API读取列表对象请求中的公共前缀，并将其显示为文件夹，从而创建文件夹的幻觉

控制台允许您创建一个文件夹，这进一步加深了这种错觉——但实际上它不是一个文件夹，甚至不需要它。它只是一个带有最后一个字符为/的键的空对象。S3的正常操作不需要此对象，但创建此对象是为了方便，以便您可以导航到空文件夹并将文件上载到空文件夹中

然而，真正发生的是：

Console: "create folder foo in the root of the bucket"
API: PUT /foo/
     Content-Length: 0

Console: "click folder foo"
API: GET /?prefix=foo/&delimiter=/

Console: "upload file bar.txt inside folder foo"
API: PUT /foo/bar.txt

现在。。。如果您使用一个空的bucket，并且使用API而不是控制台，那么您只需放入/foo/bar.txt，就可以在控制台中得到完全相同的净结果-您会看到一个名为foo的文件夹，其中包含bar.txt。显示文件夹是因为有一个前缀为foo/的对象。删除该对象，文件夹将消失

相反，如果您使用控制台从顶部执行此操作，则一旦删除bar.txt，仍然会有文件夹foo，因为这实际上只是一个空对象，其唯一目的是在没有其他具有该公用前缀的对象时，使文件夹出现在控制台导航中

所以，不。。。S3不会将文件和文件夹都视为对象。S3控制台创建欺骗文件夹的对象，严格来说是为了帮助导航，这里的神奇之处在于对象的键以/。另一方面，如果这些空对象不在那里，控制台仍然显示对象，就好像它们在文件夹中一样

然后你就会看到问题的发展。S3服务不能被要求测试它不知道并且实际上不需要存在的东西

因此，技术上不可能完全按照你的要求去做；然而，似乎有一个有限的解决办法。主要限制是不能指定文件夹必须存在，但可以指定对象键前缀必须与预定义的模式集匹配

bucket或用户策略的相关部分可能如下所示

   "Action": "s3:PutObject",
   "Resource": [ 
      "arn:aws:s3:::examplebucket/taxdocuments/*",
      "arn:aws:s3:::examplebucket/personnel/*",
      "arn:aws:s3:::examplebucket/unicorns/*"
      ...
   ],

受此策略影响的用户将能够在ExampleBack bucket中创建以taxdocuments/或Personal/或unicorns/开头的任何对象，并且将无法创建没有这些前缀之一的对象。除此之外，只要这些前缀中的一个位于每个假文件夹的对象键的开头，就可以整天在文件夹中的文件夹中创建控制台文件夹

当然，限制是使另一个文件夹有资格访问需要修改策略

这也可能有效，但请谨慎行事：

"Resource": "arn:aws:s3:::examplebucket/?*/?*",

从直觉上看，这似乎可行，但这里的缺陷——假设？*/？*是有效的，那么？与*不匹配0个字符-这允许用户在根目录中创建一个新的伪文件夹，只要他们使用API同时在其中创建名称至少有一个字符长的东西-也就是说，创建一个具有pics/cat.jpg键的对象时，如果pics文件夹不存在，则创建它，如上所述。从控制台上看，这将阻止在根目录中创建新文件夹，但从API上看，它不会强制执行此类操作

---

限制。

谢谢您的详细回复@Michael。您完全正确地说，API和CLI调用可以在非空时继续创建根级文件夹。控制台和S3浏览器访问按预期工作。这是一种妥协，但这是我们能达到的最接近我们想要的。以下是我使用的桶策略：

{
  "Version": "2012-10-17",
  "Id": "Policy1486492608325",
  "Statement": [

    {
      "Sid": "Stmt1486492495770",
      "Effect": "Allow",
      "Principal": {
        "*"
      },
      "Action": [
        "s3:DeleteObject",
        "s3:Get*",
        "s3:List*",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::test-storage",
        "arn:aws:s3:::test-storage/*"
      ]
    },
    {
      "Sid": "Stmt1486492534643",
      "Effect": "Deny",
      "Principal": {
        "*"
      },
      "Action": [
        "s3:DeleteObject",
        "s3:PutObject"
      ],
      "NotResource": "arn:aws:s3:::test-storage/?*/?*"
    }
  ]
}

---

谢谢你详尽的回复@Michael。您完全正确地说，API和CLI调用可以在非空时继续创建根级文件夹。控制台和S3浏览器访问按预期工作。这是一种妥协，但这是我们能达到的最接近我们想要的。以下是我使用的桶策略：

{
  "Version": "2012-10-17",
  "Id": "Policy1486492608325",
  "Statement": [

    {
      "Sid": "Stmt1486492495770",
      "Effect": "Allow",
      "Principal": {
        "*"
      },
      "Action": [
        "s3:DeleteObject",
        "s3:Get*",
        "s3:List*",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::test-storage",
        "arn:aws:s3:::test-storage/*"
      ]
    },
    {
      "Sid": "Stmt1486492534643",
      "Effect": "Deny",
      "Principal": {
        "*"
      },
      "Action": [
        "s3:DeleteObject",
        "s3:PutObject"
      ],
      "NotResource": "arn:aws:s3:::test-storage/?*/?*"
    }
  ]
}