Governance
Access with an approver and an end date.
Halo grants access through group membership. Governance decides how people get into groups and how long they stay: access packages, access reviews and lifecycle rules, with every decision in the audit log.
Animation: Luna requests the Kubernetes cluster admins package for two days. Priya Raman approves it, Luna is added to the group, and two days later Halo removes her automatically.
Access packages
Access people ask for, instead of chasing someone in chat.
People request a package from the Access page of their account portal. Approvers decide from the email, the account portal or the console, and applications see the new groups the next time the person signs in.
- Bundles of groupsA package grants one or more assigned groups. An approved request adds the person to all of them.
- ApproversHalo emails every approver other than the requester. Nobody can decide their own request, administrators included.
- Time limitsA maximum duration between 1 and 365 days. People pick a duration up to it, and access ends when it runs out.
- JustificationOptionally required. Approvers read it before they decide, and it stays in the request history.
Expiry
Ending access is the default, not a chore.
A grant ends when its duration runs out or when a user administrator revokes it. Halo checks for expired grants every minute and removes the person from the groups the grant added.
Memberships that stay
- A membership the person had before the grant is left alone.
- If another active grant covers the same group, it takes over the membership and removes it when it ends.
- Each expiry and revocation writes an audit event that lists the memberships removed.
Access reviews
Confirm who still needs access.
A review asks reviewers to keep or remove every member of an assigned group by a due date. Reviewers don't need an administrator role. A review that isn't completed by its due date becomes overdue, and Halo records it in the audit log.
| Decision | Automatic removal on | Automatic removal off |
|---|---|---|
| Keep | Kept | Kept |
| Remove | Removed from the group | Marked for removal, left in place |
| No decision | Keeps access | Keeps access |
Lifecycle rules
Joiners, movers and leavers, handled by rules.
A lifecycle rule runs when someone joins, moves or leaves, and only for people whose profile matches its condition. Service accounts never trigger rules.
| Trigger | Fires when |
|---|---|
| Joiner | An account is created: invited in the console, provisioned over SCIM, or created on first sign-in with an identity provider. |
| Mover | The person's department, title or location changes. |
| Leaver | The account is suspended or deprovisioned. |
Conditions and actions
A condition compares one profile field with one value. Each rule runs up to 10 actions in order: add to a group, remove from a group, revoke every session, or suspend the account.
Halo checks for changes every minute and keeps a run history with each step and its result.
user.department == "Engineering"The same syntax defines rule-based groups, whose members follow their profiles. Comparisons ignore case.
API
Every governance action has an endpoint.
Administrators automate packages, requests, reviews and rules. People use the same requests and approvals through their own routes.
/api/v1/access-packages /api/v1/me/access-packages/api/v1/access-requests /api/v1/me/access-requests/api/v1/access-reviews /api/v1/me/access-grants/api/v1/lifecycle/rules /api/v1/me/approvals/api/v1/lifecycle/runs /api/v1/me/reviewsRun Halo on your own infrastructure.
One command on a Linux host with Docker. Then create your administrator and register a passkey.
curl -fsSL https://halo.scala.gg/install.sh | sh