Storage permissions improvements GENI Workspaces

GENI Workspaces runs development instances inside your own cloud account, and mounts your buckets and NAS volumes into them. That makes the permission on each mount the thing standing between a researcher’s shell and your data. This release makes those permissions hold: what you declare when you register a storage is now the most any instance can ever do with it.

A storage’s permission is a ceiling

Storage carries a permission — read-only, write-only or read-write — and so does each attachment of that storage to an instance. Previously only the attachment’s permission was used, so a bucket registered read-only could still be mounted read-write.

Now the storage’s permission is the ceiling:

Storage permission	Attachments allowed
read-only	read-only
write-only	write-only
read-write	read-only, write-only, read-write

read-only and write-only are not ordered — neither contains the other — so only a read-write storage admits an attachment that differs from its own permission.

The rule is enforced twice. The API refuses the request, and the worker caps the grant again when it writes the instance’s IAM role, so an attachment recorded before this release cannot outlive it. A capped attachment is recorded in the audit log with both permissions.

Only admins can give an instance write access to your existing buckets

Storage GENI Workspaces creates is one thing; a bucket you already had is another. Registered storage is data GENI Workspaces did not create, never mutates, and never deletes.

Attaching registered storage with write access now requires an admin or support role. Analysts continue to attach registered storage read-only, and to attach managed storage with any permission that storage allows. Registration itself now defaults to read-only: the CLI asks for confirmation before registering with write access, and the web app shows a warning next to the choice.

Writable registered buckets must be versioned

A mount behaves like a local directory, which means rm behaves like rm. On an unversioned bucket that is permanent.

So a registered bucket may only carry read-write or write-only while S3 versioning is enabled on it. Registration checks it, and every instance apply checks it again, because versioning can be suspended long after a bucket is registered.

Versioning keeps old copies, so pair it with a lifecycle rule that expires noncurrent versions after a few days if the bucket holds scratch data.

Every instance reaches only its own resources

The permission on a mount is one half. The other half is what the instance’s own IAM role can do in your account. Three changes tighten that:

• Buckets in this account only. Every bucket grant in an instance’s role now carries an aws:ResourceAccount condition, so a GENI grant can never reach a bucket outside the account the instance runs in.
• Its own disks. When an instance has an autoscaling /home pool, its role could previously create, tag, attach and delete EBS volumes across the account. Those permissions are now limited to volumes tagged with that instance’s own stack, and restoring a snapshot is no longer possible at all.
• Its own mount points. Storage mounts at /<name>, and a name that collides with a system directory such as /etc or /usr is refused by the API, the worker and the instance itself.