Singularity Webhook Auth
Singularity contains a few options for authentication andautorization. The most reliable of these is webhook auth. The setup for Singularity's webhook auth is based on the webhook token auth provided in kubernetes.
Webhook Authentication Flow
When webhook atuh is configured, Singularity will look for an Authorization header on each api call. Singularity will then make a GET call to the configured webhookAuth.authVerificationUrl with the same Authorization header send. The system expects a response which describes the user as JSON in a format like:
{
"user": {
"id": "required-user-id",
"name": "Optional User Name",
"email": "useremail@example.com",
"groups": [
"engineering",
"singularity-admin"
],
"authenticated": true
},
"error": "Optional exception message"
}
The authenticating system should return "authenticated": true for the user if the user was successfully authenticated, as well as any groups the user is part of (for later use with authorization). If there was an exception/error while authenticating, Singularity can display that to the user if it is returned in the error field.
Configuring Webhook Authentication and Authorization Groups
To enable webhook auth in Singularity, there are two main sections of the configuration yaml to update. An example is shown below with explanations
auth:
enabled: true
authenticators:
- WEBHOOK
adminGroups:
- singularity-admin
requiredGroups:
- engineering
jitaGroups:
- engineering-jita
defaultReadOnlyGroups:
- engineering-ro
globalReadOnlyGroups:
- engineering-leaders-ro
webhookAuth:
authVerificationUrl: https://my-auth-domain.com/singularity
Verification URL
The webhookAuth.authVerificationUrl will be sent a GET with the Authorization header provided as described in the section above
Auth Config
enabled- defaults tofalse. If set totrue, auth will be enforcedauthenticators- a list of authentication types to use. For webhook auth, this is simply- WEBHOOKadminGroups- If a user is part of these groups they are allowed admin actions in Singularity (actions on agents, view all requests, etc)requiredGroups- A user must be part of one at least of these groups in order to access SingularityjitaGroups- Groups that can be allowed access to any SingularityRequest (but not admin actions)defaultReadOnlyGroups- If read only groups are not set for a SingularityRequest, these groups are used for read accessglobalReadOnlyGroups- These groups are allowed read access to requests regardless of what groups are set on the SingularityRequest
SingularityRequest Fields
You can configure access to individual SingularityRequests using the group, readWriteGroups, and readOnlyGroups fields.
group- The primary group for this request. A user in this group is allowed read/write accessreadWriteGroups- alternate groups that are also allowed read-write accessreadOnlyGroups- alternative groups that are only allowed read access