Policy Action's for S3 backend

[Rich Fromm]

For initial testing of Vault I've been using the file backend, and I'm now
exploring moving to S3.

I gather that as part of setting up the permissions on the S3 side, I need to
set a policy that explicitly allows certain actions. I would prefer to keep
that list minimal and allow only the actions that the S3 vault backend needs.

Does anyone know what actions are used? I gather that each of these actions
corresponds to a particular S3 API call (see
http://awsdocs.s3.amazonaws.com/S3/latest/s3-qrc.pdf for a handy reference),
and I suppose I could go through the source to the S3 backend and see what
it's using, but it would be far easier if these were just already itemized
somewhere. I have yet to find any such list. (If there is one, feel free to
just point me to it.)

As a first pass, I'll probably cast a fairly wide net via the use of
wildcards, but it would be nice to ultimately restrict this further before
deploying for production use.

Further detail about exactly what permissions are possible are listed below.

Thanks for any help anyone can provide.

- Rich

----------------------------------------------------------------------
The largest list I've found is at the following, which categorizes the
permissions somewhat:

http://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html

Amazon S3 Permissions for Object Operations

s3:GetObject   
s3:GetObjectVersion   
s3:PutObject   
s3:GetObjectAcl
s3:GetObjectVersionAcl
s3:PutObjectAcl
s3:PutObjectVersionAcl
s3:DeleteObject
s3:DeleteObjectVersion
s3:ListMultipartUploadParts
s3:AbortMultipartUpload
s3:GetObjectTorrent
s3:GetObjectVersionTorrent
s3:RestoreObject
s3:PutObjectTagging
s3:PutObjectVersionTagging
s3:GetObjectTagging
s3:GetObjectVersionTagging
s3:DeleteObjectTagging
s3:DeleteObjectVersionTagging

Amazon S3 Permissions Related to Bucket Operations

s3:CreateBucket
s3:DeleteBucket
s3:ListBucket
s3:ListBucketVersions
s3:ListAllMyBuckets
s3:ListBucketMultipartUploads

Amazon S3 Permissions Related to Bucket Subresource Operations

s3:GetAccelerateConfiguration
s3:PutAccelerateConfiguration
s3:GetBucketAcl
s3:PutBucketAcl
s3:GetBucketCORS
s3:PutBucketCORS
s3:GetBucketVersioning
s3:PutBucketVersioning
s3:GetBucketRequestPayment
s3:PutBucketRequestPayment
s3:GetBucketLocation
s3:GetBucketPolicy
s3:DeleteBucketPolicy
s3:PutBucketPolicy
s3:GetBucketNotification
s3:PutBucketNotification
s3:GetBucketLogging
s3:PutBucketLogging
s3:GetBucketTagging
s3:PutBucketTagging
s3:GetBucketWebsite
s3:PutBucketWebsite
s3:DeleteBucketWebsite
s3:GetLifecycleConfiguration
s3:PutLifecycleConfiguration
s3:PutReplicationConfiguration
s3:GetReplicationConfiguration
s3:DeleteReplicationConfiguration

----------------------------------------
Then there's a non-categorized list at the following. Note that it is *not*
just the union of everything above. The total list is somewhat smaller here:

http://docs.aws.amazon.com/IAM/latest/UserGuide/list_s3.html

s3:AbortMultipartUpload
s3:CreateBucket
s3:DeleteBucket
s3:DeleteBucketPolicy
s3:DeleteBucketWebsite
s3:DeleteObject
s3:DeleteObjectVersion
s3:GetAccelerateConfiguration
s3:GetBucketAcl
s3:GetBucketCORS
s3:GetBucketLocation
s3:GetBucketLogging
s3:GetBucketNotification
s3:GetBucketPolicy
s3:GetBucketRequestPayment
s3:GetBucketTagging
s3:GetBucketVersioning
s3:GetBucketWebsite
s3:GetLifecycleConfiguration
s3:GetObject
s3:GetObjectAcl
s3:GetObjectTorrent
s3:GetObjectVersion
s3:GetObjectVersionAcl
s3:GetObjectVersionTorrent
s3:GetReplicationConfiguration
s3:ListAllMyBuckets
s3:ListBucket
s3:ListBucketMultipartUploads
s3:ListBucketVersions
s3:ListMultipartUploadParts
s3:PutAccelerateConfiguration
s3:PutBucketAcl
s3:PutBucketCORS
s3:PutBucketLogging
s3:PutBucketNotification
s3:PutBucketPolicy
s3:PutBucketRequestPayment
s3:PutBucketTagging
s3:PutBucketVersioning
s3:PutBucketWebsite
s3:PutLifecycleConfiguration
s3:PutReplicationConfiguration
s3:PutObject
s3:PutObjectAcl
s3:PutObjectVersionAcl
s3:ReplicateDelete
s3:ReplicateObject
s3:RestoreObject

----------------------------------------
Alternatively, from the IAM Mgmt Console, I can get a list of actions as
follows:

https://console.aws.amazon.com/iam/home?#/policies$new

Edit Permissions -> AWS Service -> Amazon S3 -> Actions

Other than lacking the "s3:" prefix, this list is precisely identical to the
list immediately above (i.e. from list_s3.html, not using-with-s3-actions.html)

[Vishal Nayak]

Hi Rich,

There are no known itemized list for this purpose.

Regards,
Vishal

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/59e53437-89af-4801-a1e3-ec2a259e8905%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
vn

[Rich Fromm]

I took a look at
* htts://github.com/hashicorp/vault/physical/s3.go
I suspect the answer to this is fairly simple, and exactly what I guessed it to be.

The S3 client is referenced in the following functions, with the following calls (don't take this as literal Go syntax; I shortened for readability):

```
func Put(): s.client.PutObject()
func Get(): s.client.GetObject()
func Delete(): s.client.DeleteObject()
func List(): s.client.ListObjects()
```

If you want to follow that further, the client is implemented at:
* https://github.com/aws/aws-sdk-go/service/s3/api.go

I'm not 100% positive, but I think that these translate to respectively the following API calls:
* http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html
* http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html
* http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectDELETE.html
* http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET.html

Note, there is also a v2 of the last method:
* http://docs.aws.amazon.com/AmazonS3/latest/API/v2-RESTBucketGET.html

But that does *not* appear to be what the implementation of `ListObjects()` uses, at least not as of this writing (which is v1.6.4 for the repo, although that file hasn't changed since v1.6.1; I have no idea what vault is pointing to or even how Go dependencies work).

Anyway, I think (but again am not 100% positive; this is somewhat by intuition, I can't find a simple and definitive mapping) that these correspond to the following permissions respectively:

```
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:ListBucket",
      ],
```

With limited testing, things seem to work by having an IAM policy that allows these actions.

I am having some trouble that the behavior is not as expected when I try to take away some of these permissions for testing. But I'm not going to post too much about that right now, as it might be that I'm misunderstanding the AWS security model, or some other user error (my experience with AWS is limited; this vault/S3 integration is a bit of a learning process for me).

[Rich Fromm]

Apologies, the github links above are broken. The correct links are:
* https://github.com/hashicorp/vault/blob/master/physical/s3.go
* https://github.com/aws/aws-sdk-go/blob/master/service/s3/api.go

It's somewhat annoying that Google Groups doesn't provide a preview option. And doesn't apparently recognize markdown. And doesn't let you edit your post if you discover errors.

[Rich Fromm]

On Friday, December 16, 2016 at 1:35:12 PM UTC-8, Rich Fromm wrote:

Anyway, I think (but again am not 100% positive; this is somewhat by intuition, I can't find a simple and definitive mapping) that these correspond to the following permissions respectively:

```
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:ListBucket",
      ],
```

With limited testing, things seem to work by having an IAM policy that allows these actions.

I am having some trouble that the behavior is not as expected when I try to take away some of these permissions for testing. But I'm not going to post too much about that right now, as it might be that I'm misunderstanding the AWS security model, or some other user error (my experience with AWS is limited; this vault/S3 integration is a bit of a learning process for me).

 I think I know what's going on now, and I'm wondering if this is a minor bug with the vault S3 backend.

First of all, for future reference to anyone reading this thread, I had some confusion with S3 bucket policies vs. IAM policies, which are very similar, but not exactly the same. It looks like both can be used, and there are tradeoffs. (I'm using an IAM policy, fwiw.) See the following:
* https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/
And a page pointed to by that is useful as well:
* https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/

Anyway, here's my situation. I was trying to verify that the policy I had set was working properly, and that I could see a noticeable and sensible change in vault's behavior when I made changes to the policy.

I experienced a number of unusual circumstances; without showing all of the details, here's a summary of one that's illustrative:

1) Set an IAM policy with the following permissions

• s3:PutObject
• s3:GetObject
• s3:DeleteObject
• s3:ListBucket
  

2) Verify that you can read/write a value

3) Remove the s3:PutObject permission

4) The expected behavior would be that you can read a value, but that you can not write. The actual behavior is different. Read works fine. Write appears to fail, returning a 403 at a low level (this makes sense) that at a high level causes a 500 (which I think is probably a sign of a problem):

$ vault write secret/this/is/a/sample value=newvalue
Error writing data to secret/this/is/a/sample: Error making API request.

URL: PUT https://my.vault.server.com:8200/v1/secret/this/is/a/sample
Code: 500. Errors:

* 1 error(s) occurred:

* failed to write: AccessDenied: Access Denied
    status code: 403, request id: 28C1CA3C47185E1F
rich@rich-trusty [13:09:18 Mon Dec 19] ~

But if I then immediately try a vault read from the same path, I get the new value, even though the write allegedly failed. (And I indeed should not have permission to write.)

If I take a look at the AWS S3 console, the "Last Modified" date has not changed, indicating that the value was not updated, even though vault is returning the updated value.

After much consternation, and lots of testing, I think I know what's going on. I think that Vault is doing some kind of caching, and the change in policy has confused that. If I restart vault (with requires then unsealing it), I get the old value. This is consistent with the observation that the "Last Modified" time in S3 did not update. Only vault's in memory (okay, right now not truly, but I'll enable mlock for production use, see https://www.vaultproject.io/docs/config/#disable_mlock) copy was updated, not the real value in S3. (If the s3:PutObject permission is in the policy, I get no error, and the "Last Modified" time is immediately updated in the S3 console.)

This is also consistent with a statement I found within this thread:
* https://groups.google.com/d/msg/vault-tool/u3Vx3u9MUeY/Pxj2j9JAFAAJ
which says "Vault has caches internally for the physical store."

So is this a bug? Admittedly, changes in policy are not likely to be common in production, and having a policy that required restarting vault upon any policy changes isn't that big of a deal. (Although if that is required, documenting it would be nice.) Nevertheless, having an inconsistent cache seems bad, and any 500 returned from the server seems suspect to me.

I can file a bug, and/or provide some more details or alternate examples, if desired.

This is with vault 0.6.1. I could try upgrading to 0.6.4 if anyone thinks that might make a difference.