Access Model

Understanding how Cloudalus evaluates access requests helps when setting up permissions or troubleshooting why a principal can or cannot perform an action.

Cloudalus distinguishes between machine actors and machine credentials. A programmatic identity is a non-human actor in IAM. An access key is a credential that authenticates as that programmatic identity.

The two-policy check

Every action in Cloudalus is evaluated against two policies simultaneously:

1. Trust policy — attached to each trust in the chain. Scopes what the trustee is permitted to do when acting as the trusting identity. Every step in the chain must allow the action.
2. Resource policy — attached to the resource (a database, programmatic identity, organisation, etc.). Defines which identities are allowed to perform which actions on it.

Both must independently allow the action. If either denies it, the request is rejected. Deny always wins: a deny statement in any applicable policy overrides any allow.

Resource ownership

Every resource in Cloudalus has an owner. Resources automatically and fully trust their owner, meaning the owner always passes the resource policy check regardless of any explicit policy statements. Ownership works as follows:

• Databases (kvdb/*) are owned by the organisation that created them.
• Programmatic identities and their access keys are owned by the organisation that created them.
• Organisations (org/*) are owned by the user who created them (the org owner).

This means that as the owner, you don't need any explicit policy to access your own databases, programmatic identities, or their credentials. Ownership grants that implicitly.

Trust chains

The trust-policy check doesn't just ask whether this principal has a policy allowing the action. It asks whether the principal can prove a valid chain of trust to an identity that the resource trusts.

This is best illustrated with an example. Suppose a database is owned by an organisation. The database's resource policy therefore trusts the organisation. Now suppose a user is a member of that organisation. The question becomes: can that user prove they are trusted by the organisation?

When the user was added to the organisation, a trust was established from the organisation to the user, with their trust policy attached to it. When the user makes a request against the database, Cloudalus walks the trust graph:

1. The database resource policy trusts the organisation
2. The organisation has a trust to the user, with the user's trust policy
3. The user's trust policy allows the action
4. Access is granted

The chain user → org → database is resolved automatically. You don't configure it explicitly; it is the natural consequence of the user being a member of the org that owns the database.

Programmatic identities and trust chains

Programmatic identities work the same way. A programmatic identity may be trusted by an organisation, so when it makes a request against a database owned by that organisation, the chain is:

1. The database resource policy trusts the organisation
2. The organisation has a trust to the programmatic identity, with the programmatic identity's trust policy
3. The programmatic identity's trust policy allows the action
4. Access is granted

Programmatic identities can only appear as the final step in a trust chain. They cannot themselves be an intermediate trustor, meaning a programmatic identity cannot delegate trust further.

Access keys are credentials for those programmatic identities. Creating or rotating a credential does not change the trust relationships of the underlying identity.

Multiple trust chains

A principal may have more than one valid trust chain to an identity. For example, a user might be trusted directly by an org, and also trusted via another user who is themselves trusted by the org. In this case, any one valid chain is sufficient: if at least one chain fully allows the action, access is granted.

Within a single chain, however, every step must allow the action. A chain that is partially allowed is not sufficient on its own.