Access Policies
Access policies in Oystehr are a description of actions an Actor can take on resources. A policy is composed of rule
s, each containing 3 required fields: resource
, action
, and effect
.
A resource
is a Oystehr item that is prefixed by the service the item is in. For example, a resource IAM:Developer:*
is all Developers in a project.
An action
is an activity within a resource that is prefixed by the service the permission is in. For example, an action is IAM:GetDeveloper
.
An effect is whether a policy is allowed or denied, and can be Allow
or Deny
.
Simply put, a rule allows or denies permission to take a set of actions on a set of resources. An access policy grants or denies the set of permissions enacted by its rules.
Examples
This policy's rule grants the Zambda:InvokeFunction
and Zambda:CreateFunction
actions over all Zambda:Function
resources:
{
"rule": [
{
"resource": "Zambda:Function:*",
"action": ["Zambda:InvokeFunction", "Zambda:CreateFunction"],
"effect": "Allow"
}
]
}
This policy's rule denies the FHIR:Delete
action over all FHIR:Patient
resources:
{
"rule": {
"resource": ["FHIR:Patient:*"],
"action": "FHIR:Delete",
"effect": "Deny"
}
}
This policy consolidates the effects of the previous two policies in a single rule field Zambda:InvokeFunction
and Zambda:CreateFunction
actions over all Zambda:Function
resources:
{
"rule": [
{
"resource": "Zambda:Function:*",
"action": ["Zambda:InvokeFunction", "Zambda:CreateFunction"],
"effect": "Allow"
},
{
"resource": ["FHIR:Patient:*"],
"action": "FHIR:Delete",
"effect": "Deny"
}
]
}
Optional Fields
In addition to the required fields, the FHIR service makes use of an optional condition field to facilitate granular control over the scope of a rule. By specifying a FHIR query (or list of FHIR queries) in the condition field, a rule may restrict the scope of permissions it grants to the set of resources returned when the query is executed. For example, this rule grants the FHIR:Read
action over FHIR:Patient
s whose email is "[email protected]":
{
"rule": [
{
"resource": "FHIR:Patient:*",
"action": ["FHIR:Read"],
"effect": "Allow",
"condition": "[email protected]"
}
]
}
For more information on the condition rule please check out the conditions documentation.
Evaluation Logic
Those familiar with AWS access policy evaluation logic (opens in a new tab) will be familiar with the evaluation logic of Oystehr's access policies. Using "permission" to mean the combination of an effect with some action and some resource of any scope, the evaluation follows these steps:
- Check all explicitly granted ("Allow rules") and explicitly denied ("Deny rules") permissions in an access policy's rules
- Remove from the list of granted permissions any which are explicitly denied; a "Deny" takes precedence over an "Allow" on the same resource scope
- The policy is determined to grant only those permissions which remain
- Grant permission to the resource if allowed by the access policy
More Examples
All valid actions are allowed on all resources
{
"rule": [
{
"resource": ["*"],
"action": ["*"],
"effect": "Allow"
}
]
}
Everything except updating FHIR resources is allowed
{
"rule": [
{
"resource": ["*"],
"action": ["*"],
"effect": "Allow"
},
{
"resource": ["FHIR:*"],
"action": ["FHIR:Update"],
"effect": "Deny"
}
]
}
Reading and updating is allowed for a specific Zambda function
{
"rule": [
{
"resource": ["Zambda:Function:461e2e11-cf82-4ab8-b2a0-41a73b0dda6a"],
"action": ["Zambda:ReadFunction", "Zambda:UpdateFunction"],
"effect": "Allow"
}
]
}
Allow reading a Zambda function and rotating a M2M client secret
{
"rule": [
{
"resource": ["Zambda:Function:461e2e11-cf82-4ab8-b2a0-41a73b0dda6a"],
"action": ["Zambda:ReadFunction"],
"effect": "Allow"
},
{
"resource": ["IAM:M2MClient:362d928a-ac71-40dc-a62b-d7e6b925c0b6"],
"action": ["IAM:RotateM2MClientSecret"],
"effect": "Allow"
}
]
}
Read only FHIR Patients
{
"rule": [
{
"resource": ["FHIR:Patient:*"],
"action": ["FHIR:Read"],
"effect": "Allow"
}
]
}