Functions for managing user access to buckets

[sckott]

some discussion items:

• what should these fxns return? right now they're not returning anything, or at least not on purpose.
• i assume we treat admin group permissions different from user specific permissions for a bucket, yes?
• do the actions allowed in s3_actions_read and s3_actions_full look good? or different ones for default? they are based on the aws managed policies for read and full access, respectively
• note that creating a policy document is different for S3 buckets because buckets are globally unique - so I created a new fxn for just s3 to create policy documents

[seankross]

> aws_bucket_add_user("test1-2024-03-15", "jeff", "read")
✔ jeff now has read access to bucket test1-2024-03-15
Warning message:
    Unknown or uninitialised column: `PolicyName`. 

Seemed to have worked though:

> aws_bucket_get_permissions("test1-2024-03-15")
# A tibble: 3 × 2
  user  permissions
  <chr> <chr>      
1 jeff  read       
2 scott admin      
3 sean  admin 

[sckott]

Warning message: Unknown or uninitialised column: PolicyName.

Thanks i'll take a look at that warning

[sckott]

That warning is fixed now

[seankross]

This looks good and is working well for me. In terms of the discussion items:

what should these fxns return? right now they're not returning anything, or at least not on purpose.

Good question I don't know for sure. Whatever it returns it should probably be invisible. Maybe we should look at usethis for ideas since it's also meant to be used interactively and the main thing it "returns" is messages to the user.

i assume we treat admin group permissions different from user specific permissions for a bucket, yes?

Yes, I don't have ambitions to wade deeply into this, especially not inn v0.1

do the actions allowed in s3_actions_read and s3_actions_full look good? or different ones for default? they are based on the aws managed policies for read and full access, respectively

I will get back to you in an issue and edit this comment so it's tagged here.

note that creating a policy document is different for S3 buckets because buckets are globally unique - so I created a new fxn for just s3 to create policy documents

Sounds and looks good to me.

[sckott]

WRT what to return from fxns:

• usethis just returns invisible() e.g., here
• seems good to do like usethis does and make sure to do invisible() instead of the cli message

[sckott]

@seankross okay - fxns are returning invisble now. I still need to:

• [x] make aws_bucket_change_user actually work

[sckott]

@seankross okay, aws_bucket_change_user is useable now. i still need to

• [ ] add tests for aws_bucket_change_user

but you can still try it

[sckott]

One important note: Given the desire for a simple interface to permissions - just read and write - these functions will probably only work if users do not edit their own policies and then try to use these functions. As you've seen there's no simple mapping from the policies to read or write, so we make some shortcuts here to make it possible. Just something to be aware of

[sckott]

Additional fun needed:

• [x] Get aws key and secret key for a user
  • paws has a function create_access_key(UserName)
  • context is within a workflow of a) create user, b) add user to some buckets, c) send keys to user so they can use sixtyfour/other routes of using aws
  • possibly add a draft email with keys to the users clipboard so they can easily paste into an email to that user

[sckott]

@seankross can you test out the new fxn aws_user_creds? note the copy to clipboard is default not turned on, set copy_to_cp = TRUE to use it. I'm not sure if we should have it on by default or not. And please look at the output it give sin the clipboard and whether you think it should be changed at all.

the workflow you talked about with function names:

1. aws_user_create() - create the user
2. aws_bucket_add_user() - add that user to some buckets
3. aws_user_creds() - send that user their keys

[seankross]

To start:

• aws_user_creds() has a very nice message and should therefore probaly return invisibly.
• I like the message, should we advise that the end user edits their .Renviron with usethis::edit_r_environ()?

more to come

[sckott]

Thanks. We could return invisibly - but do you think there's a use case for doing something downstream with the keys? Which is harder if they have to copy/paste them from a message.

Yeah, seems like a good idea on edit_r_environ

Please also take a look at the docs for aws_user_creds

[sckott]

@seankross aws_user_creds() now returns invisible, and added the note about r environ edit

[seankross]

Oof sorry I did't communicate this clearly: I liked the object that aws_user_creds returned, I just thought it would look cleaner in the R console if it returned that same object but returned it invisibly.

[sckott]

fixed

[seankross]

@sckott whenever we print the dev keys to the console can we print the AWS region too? I know that's copied into the clipboard, but I feel like putting it in the console wouldn't hurt.

[sckott]

@seankross will do

[seankross]

@sckott overall looks good to me, merge at your discretion.

[sckott]

@seankross waiting to merge this until we merge more-magic into this branch

[github-actions[bot]]

🚀 Deployed on https://deploy-preview-43--teal-chaja-b4836e.netlify.app