RosettaOps™ Sharing
Native access, no policy and no keys
Say who.
The policy writes itself.
These are your own cloud resources, shared through your cloud’s own mechanisms. What changes is that nobody composes the policy document, and nobody has to remember to take it back.
Native resources, shared natively
Nothing is copied, proxied or wrapped. The resource stays where it is, in your account, and the cloud enforces the access itself.
IAM roles
The way to give a person console or CLI access. They assume the role, work, and hold no credential afterwards.
Object storage
A whole bucket or a single folder path inside it, with the rights you choose. The bucket policy is generated to match.
Machine images
Images built through federation, shared natively so a recipient launches from them in their own account.
Account pools
A pool of accounts shared with a group, so the people in it draw from the pool without an allocation step.
IAM users
For the native users already in your estate. Shared as a session, so the keys stop circulating while you move off them.
Share with a group,
and the group is what is enforced
A hand-written policy names people. It is accurate on the day it is written and slowly stops being true after that. Here the share names the group, and the policy is regenerated as membership moves.
A person
One named recipient. The narrowest share and the easiest to reason about.
A group
Membership decides access. The policy follows the group rather than the list of names it happened to contain on the day it was written.
A role
Everyone holding a role, so access tracks what people do rather than who they are.
An organisation
Everyone in it, including the people who join after the share was made.
Joiners and leavers stop being a task
Someone joining the group has the access because they are in the group. Someone leaving loses it as they go. The most common way access outlives its purpose is that revoking it was one more thing on a list, and this removes the list.
How people get in
Console and CLI access,
with nothing left to rotate
Your cloud provider asks you to keep human access on temporary credentials, and the reason is not theoretical. A permanent access key has to be rotated, and the ones that get forgotten are the ones that turn up in a repository two years later.
So a shared role is the way in. The recipient assumes it, gets a session, and holds nothing between sessions. There is no key to rotate because there is no key.
Into the console
A sign-in straight into your cloud’s own console, with no password to circulate and nothing to take away afterwards.
Or the command line
Short-lived keys for a script, a terminal or an SDK, issued for the session and expiring with it.
Narrowed further
A policy applied on top, so a share can grant strictly less than the role itself carries.
For a set time
You choose the session length. When it lapses the access is simply not there any more.
And the recipient needs no account of their own
Not on your cloud, and not on RosettaHub. The role is created inside the perimeter of what its author is already allowed to do, so sharing one can never hand out more than the person sharing it holds.
The external collaborator
A partner lab, an agency, a team at another institution, for as long as the project runs.
The auditor
Read what they came to read, for the length of the audit, under a policy that says so.
The supplier with one job
Onboarding them properly usually costs more than the work, which is why it so often gets done badly instead.
The estate you already have
Native users, without the keys in circulation
Almost every estate still has native users in it, and they will not all be gone by the end of the quarter. Sharing one is supported for that reason, not as the recommended path.
When you do share one, the recipient never receives the credentials. They get a session in that identity’s name, with the same controls a shared role has: console or command line, narrowed by a policy, for a length of time you choose. The permanent key stays where it is and stops being passed around, which is the useful half of the problem solved while you work on the other half.
If you are choosing today, share a role.
The other half of sharing
This page is about resources that already exist in your accounts. RosettaCloud shares the things the platform creates and runs for you, such as formations, clusters, storage and images, across accounts and across clouds. Most organisations end up wanting both.
See sharing in RosettaCloud →Common questions
How do I share an S3 bucket without writing an IAM policy?
Name who it goes to and what they may do with it. The native bucket policy is generated and applied for you, scoped to a folder path if you want only part of the bucket shared. Nobody hand-writes JSON and nobody reviews it afterwards.
What happens when someone joins or leaves the team?
If the resource is shared with a group or an organisation, the native policy is rewritten when membership changes. A new joiner has access because they are in the group, and a leaver loses it the moment they are out. Nothing needs to be remembered and nothing needs to be revoked by hand.
How do I give someone console or CLI access without a permanent access key?
Share a role. The recipient assumes it and receives a session, either a sign-in to your cloud’s own console or short-lived keys for the command line, and holds nothing between sessions. There is no permanent key to rotate, expire or find in a repository later, which is what your cloud provider’s own guidance asks for.
Can I give an external collaborator access without creating them an account?
Yes, by sharing a role. The recipient gets a session in your account with no cloud account of their own and nothing left behind when the share ends. The role is created within the perimeter of what its author is already allowed to do, so sharing one cannot hand out more access than the person sharing it holds.
Should I share an IAM user or a role?
A role, if you are choosing today. Native users tend to carry long-lived access keys that somebody has to rotate, and those are the credentials that outlive their purpose. Sharing a native user is supported because most estates still contain them: the recipient gets a session rather than the credentials, so the key stops circulating while you move off it.
How is this different from sharing in RosettaCloud?
RosettaCloud shares objects the platform creates and manages, such as formations, clusters and images, across accounts and across clouds. RosettaOps shares resources that already exist natively in your accounts, by generating and maintaining that cloud’s own policies. Most organisations end up using both.