Access keys¶

Every request is signed with an access key, unless it is an anonymous read of something made public (see Public access). Keys are managed with leblob key, on the server, against the data directory. A change applies from the next request, with no restart.

Full-access keys¶

The first start of a store creates one key with full access, and prints it once. Create more with:

leblob key create --data-dir ./data

access key: ...
secret key: ...

The secret isn't shown again. A full-access key can do everything, on every bucket, including creating buckets.

Scoped keys¶

A scoped key starts with no rights at all. Grant it a level on each bucket it should reach:

leblob key create --scoped --data-dir ./data
leblob key grant ACCESS_KEY my-bucket read --data-dir ./data
leblob key grant ACCESS_KEY uploads write --data-dir ./data

A grant replaces any level the key had on that bucket. leblob key revoke ACCESS_KEY BUCKET removes it.

Level	Allows
`read`	Reading and listing objects and their versions, reading tags, ACLs, versioning, lifecycle and CORS settings
`write`	`read`, plus writing, copying and deleting objects, multipart uploads, setting and removing tags, and making an object private
`admin`	`write`, plus deleting the bucket, erasing a version for good, changing versioning, lifecycle rules and CORS rules, and making a bucket or an object public

Some limits follow from that table:

A scoped key can't create buckets. Create them with a full-access key, then grant.
With write, a key can delete an object in a versioned bucket, which leaves a delete marker, but can't erase the versions kept behind it. So a stolen write key can't destroy what versioning keeps.
Making anything public takes admin, on a write with x-amz-acl: public-read as much as by PUT ?acl. So a stolen write key can't expose what the store holds.
Tagging an older version by its ID takes admin, since a lifecycle rule on tags could then erase it.
UploadPartCopy and CopyObject take write on the destination and read on the source.

A scoped key sees only its own buckets when it lists them. It can't tell a bucket it has no grant on from one that doesn't exist: both answer 403 AccessDenied. An operation leBLOB adds later stays closed to scoped keys until a level is chosen for it.

Grants disappear with their bucket, so a bucket deleted and created again starts with none.

Listing and deleting keys¶

leblob key list --data-dir ./data

AKEXAMPLE1  full access
AKEXAMPLE2  my-bucket: read, uploads: write
AKEXAMPLE3  no rights

leblob key delete ACCESS_KEY deletes a key. Requests signed with it are refused from then on.

Where secrets are kept¶

SigV4 needs the secret itself on the server, so secrets are stored as they are in meta.db, in the data directory. leBLOB sets the data directory to mode 0700 at every start. A metadata backup holds the secrets too: keep it as carefully. See Backup and restore.