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 their own budget and their own quotas. 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.
The other half of sharing
Everything above is about objects the platform creates and runs for you. Resources that already exist natively in your own accounts, such as a bucket, a machine image or an IAM user, are shared by a different mechanism: RosettaOps generates that cloud’s own policy and rewrites it as your groups change.
See native sharing in RosettaOps →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.