See the Cyral just-in-time access documentation to learn how to set up and use ephemeral access.
In a Cyral-managed data environment, users' access to data can be granted through Cyral policies or through Cyral's just-in-time access grants. In general, the just-in-time grant overrides your standing policy. This article explains the interaction of just-in-time grants and standing policies.
just-in-time access or ephemeral access: Permission (typically for a limited time) to read data. Users request this permission by chatting with the Cyral chatbot in Slack. Ephemeral access is read-only; it cannot be used to grant users insert, update, or delete privileges.
ephemeral policy: When a user asks the chatbot for access to specific sensitive resources, and that request is approved, an ephemeral policy is created to grant the user read access to data. These policies work along with your standing policies in Cyral, and, for data read operations only, the ephemeral policy overrides conflicting read limits from your standing policies. For chatbot requests that don't specify sensitive resources (requests to access the repository as a whole), no ephemeral policy is needed, and the standing policy determines access.
standing policy: These are the existing (typically long-term) sets of data access rules you've specified in the Policy tab of Cyral. They can be used to grant users read, insert, update, and delete privileges.
datamap and sensitive resources: When you give users the ability to request ephemeral access to a repo, you have the option of declaring specific data locations in the repository (for example, tables and columns) as sensitive resources. You specify sensitive resources by including them in your datamap. The user can request access to these sensitive resources by name, and if approved, will have read access only to those resources listed in the approved request.
Types of just-in-time requests
Once ChatOps ephemeral access has been set up for a repository, users can chat with the Cyral Slack app (/cyral) to find repositories, request read access, and be alerted when their request is approved. Admins can approve data access requests and find repositories and sidecars.
The request types are
request access to specific sensitive resources (for example tables and columns) in the repository; or
request access to the repository without specifying tables or other specific resources in the repository. In this case, if the request is approved, your standing policies determine the user's access. For requests of this type, you as administrator can also set up automatic approvals for requests whose requested access duration fits within the limit you've specified.
Your standing policies remain in effect when you use ephemeral access, but ephemeral access grants can override parts of them. Let's look at how policies interact:
If the approved request did not specify any sensitive resources, access to sensitive resources is governed by standing policies as usual.
If the approved request did specify sensitive resources (say R1 and R2), then for the duration of the grant:
the user can read resources R1 and R2, even if access to these resources is prohibited by standing policies.
the user cannot read any sensitive resources other than R1 and R2, even if access to these resources is permitted by standing policies.
write access (insert, update, delete) to all sensitive resources (including R1, R2, ...) is governed by standing policies. This is unaffected by the resources specified in the request.
If a user already has ephemeral access to sensitive data and generates a new request, once the new request is approved, it will overwrite that user's existing ephemeral access with the new sensitive data requested and with the new duration, running from when it was approved
What happens when a request is approved?
An ephemeral policy is generated when a grant request with sensitive resources is approved. This policy permits reading only the specified sensitive resources and no other. For the duration of the grant (and for this user), this ephemeral policy overrides standing policies with respect to read access to sensitive data. If the request does not specify any sensitive resources, this ephemeral policy is not generated, and access is governed by standing policies as usual.
Write access to sensitive resources and all resources in the repository continues to be governed by standing policies.
For any repository where you'll offer access via the Slackbot, make sure your standing policy doesn't grant more default access rights than you want to offer. For example, make sure your policy does not have a default rule providing open access to the repository.
Learn more in the just-in-time access documentation.