Endor Labs comes with a built in attribute based access control system. Attribute-based access control (ABAC) is an authorization model that evaluates attributes (or the characteristics of an identity), rather than roles, to determine access.
Endor Labs uses external identity providers to authenticate all users and the attributes associated with the identity to authorize them.
Configure authorization with Endor Labs
Authorization in Endor Labs is defined by a set of authorization policies. Authorization policies define the permissions provided to an identity authenticated by a supported identity provider when that identity meets specific rule criteria defined as attributes or claims about the identity.
Authorization policies must contain the following information:
- The supported identity provider through which a given identity comes from.
- The permissions provided to an identity when specific rule criteria are met.
- An optional expiration time for the policy
- The rule criteria or claims for which the identity must have to be authorized to access Endor Labs.
- After setting up the authorization policy, you can invite users to Endor Labs
Authorization policy roles
Endor Labs comes with several out-of-the-box authorization policies to enable the principle of least privilege for its users. The out-of-the-box authorization policy roles are:
| Role | Access | Module | Description |
|---|---|---|---|
| Policy Editor | Complete read and write access | Policies and policy templates | Primarily used to allow users to manage policies. |
| Export | Export SBOM and VEX | ||
| Complete read and write access | Notifications | ||
| Read-only | All modules | ||
| Code Scanner | Scan | Projects and repositories | Primarily used for a CI/CD-based service account |
| Complete read and write access | Policies and policy templates | ||
| Complete read and write access | Projects and repositories | ||
| Complete read and write access | Findings | ||
| Complete read and write access | Notifications | ||
| Read-only | All modules | ||
| Read-Only | Read-only | All modules | Primarily used to grant read-only access to all modules in the application |
| Export | Export SBOM and VEX | ||
| Admin | Complete read and write access | All modules | Primarily used to grant complete access to the application |
Supported authentication providers
Authentication through Endor Labs is done through an external identity provider. Some authentication mechanisms are generally designed for human users, while others are designed for machine identities.
Supported authentication mechanisms designed for human users include:
- Google - Authentication is provided through a users Google workspaces or Gmail account.
- GitHub - Authentication is provided through a users GitHub account.
- GitLab - Authentication is provided through a users GitLab account.
- Email - Authentication is provided through an email link sent to a user.
- Custom Identity Providers - An enterprise identity provider such as Okta or VMware One, which uses SAML or OIDC protocol. Learn more at our documentation on setting up a custom identity provider
Authentication mechanisms designed for machine identities, such as continuous integration or automation systems include:
- Google Cloud - With Google Cloud workload identity federation service accounts may be used to federate identity to Endor Labs. Learn more at our documentation on setting up keyless authentication
- GitHub Action OIDC - With GitHub Action OIDC you can federate the identity of your workloads to Endor Labs. Learn more at our documentation on setting up keyless authentication
- AWS Role - With AWS identity federation your can use the AWS ARN of the role acts as the identity of a machine user. Learn more at our documentation on setting up keyless authentication
Set up authorization policies
To set up an authorization policy to your Endor Labs tenant:
- Go to Manage > Access Control on the left-hand navigation.
- Ensure you are on the Auth Policy top navigation tab.
- Click Add Auth Policy.
- Select the identity provider that you would like to set up an authorization policy for.
- Select the permissions that a matching identity is authorized for.
- Select an expiration time for which an authorization rule may exist in the system.
- This may be either No expiration, 24 hours, 72 hours, one week, two weeks, or 30 days.
- Select the claims for which the authorization rule will provide access
- For GitHub and GitLab this may be the user’s platform handle
- For Google, this may be the user’s email address or the domain of the email address.
- For a custom identity provider, this may be set to a key value pair associated with the claims provided by your external identity provider.
- For Email this may be the email address an authentication link is sent to.
- For GitHub Action OIDC this may be the organization or repository for which a workload runs under.
- For AWS Role this may be the AWS ARN of the role the machine is set to impersonate.
- For Google Cloud this may be the principal email of a service account the workload is set to impersonate.
- Under Advanced you may select a set of namespaces for which an authorization policy may apply. If you choose to propagate this policy to all child namespaces then the authorization policy will be applied to any selected namespaces and their children.
- click Add Auth Policy to save your authorization policy.
After adding the authorization policy, a user with the corresponding authorization claims can sign in to Endor Labs with their configured permissions.