Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.endorlabs.com/llms.txt

Use this file to discover all available pages before exploring further.

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 role provided to an identity.
  • An optional expiration time for the policy.
  • The rule criteria or claims required for an identity to access Endor Labs.
After setting up the authorization policy, you can invite users to Endor Labs.

Set up authorization policies

To set up an authorization policy to your Endor Labs tenant:
  1. Select User menu > Settings from the left sidebar.
  2. Select Access Control > Auth Policy.
  3. Select Add Auth Policy.
  4. Select the identity provider for which you want to configure an authorization policy.
  5. Select the role to be granted to a matching identity.
  6. Select an expiration time for the authorization rule. This may be either No expiration, 24 hours, 72 hours, one week, two weeks, 30 days, 60 days, or 90 days.
  7. Select the claims for which the authorization rule will provide access.
  8. Select Add Permission Rule to define granular permissions by specifying resource kinds and allowed methods.
  9. Under Advanced, select a set of namespaces for which the authorization policy applies. If you choose to propagate this policy to all child namespaces, then the authorization policy will apply to any selected namespaces and their children.
  10. 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. See Invite users to Endor Labs.

Claims

Claims are key-value pairs from your identity provider’s JWT or SAML token that Endor Labs evaluates when a user authenticates. Each claim has a:
  • Key: the token attribute name
  • Value: the expected attribute value
When an incoming token’s attributes match all the claims in a policy, Endor Labs grants the policy’s assigned role to that user.
When a policy contains multiple claims, all of them must match for the policy to apply. Claim values are case-sensitive.
The following are the claim keys available for each identity provider and what values to enter.
Use the user key with the user’s platform username as the value. The username is the handle the user signs in with on GitHub or GitLab, not their display name or email address.For example, to grant access to a GitHub user with the handle jsmith, set Key to user and Value to jsmith.
Use the user key to grant access to a specific Gmail address, or the domain key to grant access to all users in an email domain.For example:
  • To grant access to a single user, set Key to user and Value to jsmith@example.com.
  • To grant access to everyone in a domain, set Key to domain and Value to example.com.
Using domain is useful for organizations where all employees share a corporate Google Workspace domain and you want to grant access to the whole group rather than individual users.
Use the email key with the principal email address of your workload’s service account.This is typically a service account address in the format name@project-id.iam.gserviceaccount.com.
Use the user key to restrict access to workflows running in a specific GitHub organization or repository. Set the value to the organization or repository in the format org or org/repo.For example:
  • To allow any workflow in the acme organization, set Value to acme.
  • To restrict access to a specific repository, set Value to acme/payments-service.
This is commonly used to authenticate CI/CD pipelines to Endor Labs without storing credentials.
Use the user key with the full AWS ARN of the IAM role your machine uses to authenticate. For example, arn:aws:iam::123456789012:role/endorlabs-scanner.The ARN must match exactly as it appears in your AWS IAM configuration.
Use the email key with the email address to which Endor Labs sends the authentication link. This is for users who sign in via a one-time link sent to their email address.
Azure authorization policies require three claim keys that together uniquely identify the application identity:
  • tid: The Directory (tenant) ID of your Azure Active Directory tenant.
  • appid: The Application (client) ID of the registered application in Azure.
  • oid: The Object ID assigned to the application or managed identity in the tenant.
The following keys are optional and can be used to further narrow access:
  • az_jwt_sub: The subject claim from the Azure JWT token. Use this to scope the policy to a specific identity within the application.
  • subscriptions: The Azure subscription ID, to restrict access to workloads running under a specific subscription.
Use any key-value pair that your SAML or OIDC identity provider includes in its token. The key must match the claim attribute name exactly as it appears in the token.For example, if your Okta OIDC token includes a groups claim, set Key to groups and Value to the group name you want to match. If your organization maps department information into a custom claim called department, you can use that to scope access to a specific team.

Permission rules

Permission rules control what actions an authenticated identity can perform in Endor Labs. Each rule has two parts:
  • Resource kind: The type of object the rule applies to, such as Project, Finding, AuthorizationPolicy, or ScanProfile. Use * to apply the rule to all resource kinds.
  • Methods: The operations allowed on that resource. The following methods are available:
    • Read: Use this to grant view-only access to a resource without allowing any modifications.
    • Create: Use this to allow an identity to add new resources, such as creating projects or scan profiles.
    • Update: Use this when an identity needs to edit resources it did not necessarily create, such as updating findings or policies.
    • Delete: Assign this only when the identity explicitly needs to delete resources, as it cannot be undone.
    • All: Use this when an identity needs full control over a resource type.
You can add multiple rules to a single policy to compose exactly the access level you need. For example, you could allow Read on all resources using *, then add a separate rule granting Create and Update on Project only, giving a CI service account the ability to run scans without broader write access. Permission rules in an authorization policy

Search authorization policies

You can use the search functionality to find authorization policies based on specific criteria. To search for authorization policies:
  1. Select User menu > Settings > Access Control.
  2. Select Auth Policy.
  3. Use the search bar to find policies by:
    • Rule: Search policies by any text or string patterns within the rule definitions.
    • Created By: Search policies by the email address of the creator.
    • Namespaces: Search policies associated with a specific namespace.
Auth Policy search

Edit authorization policies

To edit an authorization policy:
  1. Select User menu > Settings > Access Control.
  2. Select Auth Policy.
  3. Click the vertical three dots on the right side of the policy you want to edit and click Edit Auth Policy.
  4. You can update the identity provider, permission, expiration time, claims of key and value, and namespaces the policy applies to.
  5. Click Propagate this policy to all child namespaces to apply this policy to all child namespaces within the hierarchy.
  6. Click Update Auth Policy.
Edit Auth Policy

Delete authorization policies

To delete an authorization policy:
  1. Select User menu > Settings from the left sidebar.
  2. Select Access Control > Auth Policy.
  3. Click the vertical three dots on the right side of the policy you want to delete and click Delete Auth Policy.
  4. Click Confirm in Delete Authorization Policy.

Grant support access

You can give the Endor Labs team read-only access to your namespaces for a limited time, allowing them to offer technical support and resolve issues. You can revoke access and delete these policies at any time. See delete authorization policy for more information. To grant support access to your namespace:
  1. Select User menu > Settings from the left sidebar.
  2. Select Access Control > Auth Policy.
  3. Select Grant Support Access.
  4. Select an expiration time for the access from the drop down menu.
  5. Click Grant Access.