RosettaCloud™ Sharing
Collaboration without tickets
Right-click. Share.
The way documents work.
Sharing a cloud resource normally means a ticket, a policy somebody has to write, and a set of keys that outlive the reason they were issued. Here it is a right-click, and the credentials appear and disappear with the sharing itself.
Three things that rarely
happen together
Most governance platforms treat sharing as user management: an administrator grants, a user receives. That is a different thing from collaboration.
Who can share
Anyone who owns something
Not just administrators. The person who built the environment is the person who shares it, with anyone they already work with, without asking a central team for permission first.
How access happens
Credentials that follow the share
Temporary delegated credentials are issued when you share and revoked when you unshare. A machine in one account reaches storage in another account, or on another cloud, with nobody exchanging keys.
Who you can be
In several organisations at once
A home institution, a consortium and a grant-funded project, each with its own role and its own budget, for the same person. Collaboration usually crosses an organisational boundary, so the model has to.
Nearly everything is shareable
Sharing is not a feature bolted onto one object type. It runs across the platform, and every object is private until you decide otherwise.
Formations
Machine images
Cloud keys
Key pairs
Storage
Kubernetes clusters
Container images
Dashboards and views
Portfolios
Compliance policies
Sessions
And the rest
Private
Where everything starts. Visible to the owner and nobody else.
Shared
With named people, a group, or a whole organisation. Withdrawn the same way it was given.
Published
Available to everyone on the platform, through the marketplace, when the thing you built is worth handing to strangers.
Open, and still governed
Letting people share without a ticket stays governed, because the limits come from the account rather than from the sharing.
Whoever receives a resource works inside their own account, under whatever limits already apply there. A shared formation launched by someone with no budget left is refused at the cloud, exactly as it would be if they had written it themselves.
The permission to collaborate and the permission to spend are different questions, and only one of them needs an administrator.
Resources you already have
Everything above is about objects the platform creates and runs for you. A bucket or a machine image that already exists in your own account is shared a different way: RosettaOps writes that cloud’s own policy for you and rewrites it as your groups change, so a joiner has access because they are in the group and a leaver loses it as they go.
Native resource sharing, in the documentation →Common questions
Do I need an administrator to share a cloud resource?
No. Whoever owns a resource can share it, with a person, a group or a whole organisation. Sharing is not gated behind a central identity team, which is what usually turns a two-minute collaboration into a two-week ticket.
How does access work across different accounts and clouds?
The platform issues temporary delegated credentials when you share and revokes them when you unshare. A machine in one account can reach storage in another account, or on another cloud, without anyone exchanging keys or writing a policy.
Can someone belong to more than one organisation?
Yes, and to several unrelated ones at once. A home institution, a research consortium and a grant-funded project can each carry their own role and their own budget for the same person.
What can be shared?
Nearly every object: formations, machine images, cloud keys, key pairs, storage, Kubernetes clusters, container images, dashboards and views, portfolios and compliance policies. Each is private by default, shared with named recipients, or published.