A Model for top-level LTS Permission

[bdu-birhanu]

Pull Request

Overview

Proposed Changes

• Added a section about top-level LTS permissions.
• Added a table on permissions and responsibilities in shared LTS allocations.
• Added a table on permissions and responsibilities in individual LTS allocations.

Related Issues

Fixes #654
Fixes #671

[wwarriner]

Three main pieces of information needed to fully manage an LTS allocation:

1. Access key (one per person, per allocation)
2. Secret key (same)
3. Allocation IAM (one per allocation)

1 + 2 grant full control of an allocation
3 can be used in policies

What does a steward have that can't be granted by policy? Bucket management.

[wwarriner]

Policies are treated like objects, to modify, must delete and put a new version. Must do a get, modify, put cycle to change even a small typo.

[wwarriner]

Each person (identity) can be involved with managing multiple allocations, and will need a key set for each one. Each key set may be granted for different roles, depending on the person's functional title (PI, Core Director, everyone else) and their role in the allocation.

• PI owner of a shared allocation
• Core Director owner of a shared allocation
• Steward of a shared allocation, regardless of title
• Owner of an individual allocation, regardless of title

[wwarriner]

Let's arrange the text into sections like this:

• Terminology

• Shared Allocations

  • Functional Roles (Owner, Steward, Member)
    • Make a table of permissions and responsibilities
    • Roles are columns
    • Permissions are rows:
      • responsible for allocation (owner only)
      • create bucket, delete bucket, rename bucket (owner and steward)
      • all other operations (owner and steward get mark, "member" gets text like "per bucket policy")
  • Who can have what role?
    • Owners must be Core Directors or a Lab PI.
    • Stewards may be anyone designated by an owner.
    • Members may be anyone with access to the system, i.e., has created an individual allocation and a Cheaha account.
  • How do I gain access to my role?
    • Owners and stewards have key sets for the allocation(s) they manage. These key sets are distinct, one per person per allocation, and separate from the key set they use for their individual allocations.
    • Members are granted access by bucket policy for each bucket they need access to.

• Individual Allocations

[wwarriner]

I think this is good, it needs a bit of tweaking, and I raised a question.

My question: should we merge this with "Bucket Permissions" and call that page "Access Control"? What are your thoughts?

[wwarriner]

This is great, let's pivot to Identity and Access Management (IAM) instead of Access Control or Permissons. Don't use the term "Access Control" nor "Permissions" since those are S3 concepts we aren't documenting yet.

[wwarriner]

Great work! I think this is the final round of review, probably.

In addition to specific comments, let's be consistent with capitalizing "Core" when referring to the concept of a "Research Core".

[wwarriner]

One typo then ready to go.