Skip to content

Native Resource Sharing

Share a resource that already exists in your cloud account. RosettaOps generates that cloud's own policy and regenerates it as your groups change.

Two sharing mechanisms

"Sharing" means two different things in RosettaHub, and they use different machinery.

RosettaCloud sharing RosettaOps native sharing
What is shared Artifacts the platform creates and manages: formations, clusters, images, storages Resources that already exist natively in your accounts
How access is granted Delegated credentials issued on share, revoked on unshare The cloud's own resource policy, generated and maintained for you
Crosses clouds Yes No, a native resource is native to its own cloud
Typical user Anyone who owns an artifact An account owner exposing part of an existing estate

Most organizations use both. This page covers the second.

What can be shared

Resource Notes
Object storage buckets A whole bucket, or a single folder path within it, with the rights you choose
Machine images Images built through federation, shared natively so a recipient can launch from them
IAM users Shared as a session rather than as credentials. See Sharing an identity
IAM roles The recommended way to grant console or CLI access. See Sharing a role
Cloud account pools A pool shared with a group, so its members draw from the pool without an allocation step

Who you share with

Every share is addressed to a tenant, and the tenant type decides how the generated policy behaves over time.

Tenant type CLI flag Behaviour
User u One named recipient
Group g Everyone in the group, now and later
Role r Everyone holding the role
Organization o Everyone in the organization, including people who join after the share was made

This is the point of native sharing

A hand-written policy names individuals. It is correct on the day it is written and drifts from then on. When a share names a group or an organization, the underlying policy is regenerated as membership changes: a joiner has access because they are a member, and a leaver loses it when they stop being one. Nobody has to remember to revoke anything.

Sharing a bucket

Sharing object storage generates the bucket policy for you. Two options shape what is exposed:

  • Folder path -- limit the share to a prefix instead of the whole bucket
  • Rights -- what the recipient may do with what they can see
rh bucket share --bucket-uid <uid> --tenant <name> --tenant-type g \
  --folder-path datasets/2026 --rights read

--replace replaces the existing share list rather than adding to it. rh bucket unshare removes a share, and the generated policy is updated to match.

Sharing an identity

Sharing a native IAM user does not hand over the identity. The recipient receives a session issued in that identity's name, and never the underlying credentials.

Option Effect
--allow-sts-console A sign-in to the cloud provider's own console
--allow-sts-keys Short-lived keys for a script, a terminal or an SDK
--sts-policy A policy applied on top, narrowing the session below what the identity itself holds
--sts-duration Session length in seconds 
rh iamuser share --iam-user-uid <uid> --tenant <name> --tenant-type u \
  --allow-sts-console --sts-duration 3600

Sharing a role

Prefer roles for human access

A native IAM user usually carries a long-lived access key that somebody has to rotate, and the keys nobody rotates are the ones that outlive their purpose. Cloud provider guidance is to keep human access on temporary credentials, and a shared role is exactly that: the recipient assumes it, receives a session, and holds nothing in between. If you are choosing today, share a role. Sharing a native IAM user remains supported because most estates still contain them, and sharing one at least stops the permanent key circulating.

A role carries the same four controls as an identity: console access, temporary keys, a narrowing policy and a session duration.

What a role adds is that the recipient needs no cloud account of their own, on your cloud or on RosettaHub. That covers the external collaborator, the auditor, and the supplier who needs to do one thing once, where creating a full account costs more than the work itself.

Roles are created within the perimeter of what their author is already permitted to do, with their own trust policy and permissions, so sharing a role can never grant more access than the person sharing it holds.

Auditing

Every share and unshare is recorded. Who was granted what, by whom, and when is a query against the audit trail rather than a reconstruction from policy history.

See also