This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Administration

This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Learn about the administrative features to configure and manage important settings of the application, such as authorization policies, user invitations, API keys, and more.

Manage access to Endor Labs

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. See Authorization policies for more information on managing authorization policies.

Endor Labs uses external identity providers to authenticate all users and the attributes associated with the identity to authorize them.

The following sections provide information on authentication providers and how you can configure them.

After you configure authentication and authorization policies, you can invite users. See Invitations for more information.

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.

Endor Labs supports the following authentication mechanisms for human users.

  • Google - Authentication is provided through a user’s Google Workspace account.
  • GitHub - Authentication is provided through a user’s GitHub account.
  • GitLab - Authentication is provided through a user’s 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. See Custom identity providers for more information.

The following authentication mechanisms designed for machine identities, such as continuous integration or automation systems, are supported.

  • Google Cloud - With Google Cloud workload identity federation service accounts may be used to federate identity to Endor Labs. See Keyless authentication for more information.
  • GitHub Action OIDC - With GitHub Action OIDC you can federate the identity of your workloads to Endor Labs. See Keyless authentication for more information.
  • AWS Role - With AWS identity federation your can use the AWS ARN of the role acts as the identity of a machine user. See Keyless authentication for more information.

Session duration

The duration of the session token determines how long a user stays authorized in Endor Labs. At the end of the session duration, the user authentication is invalidated and requires reauthentication.

The following table provides the session duration for various authentication providers.

Authentication provider Session duration
Google 1 hour
GitHub 4 hours
GitLab 2 hours
Email 4 hours
Custom IdP Depends on the session duration set by the IdP
API Keys 4 hours

The default session token duration for Custom Identity Providers (IdPs) is 4 hours, provided no specific session duration is configured in your IdP. Endor Labs respects the session duration defined in your IdP, after which users must reauthenticate.

For SAML-based integrations, you can set the session duration using the SessionNotOnOrAfter attribute. In OIDC, the token expiration claims (exp) control the session duration.

The maximum allowed session duration is 4 hours. If your IdP is configured with a session duration exceeding 4 hours, the session will automatically default to a 4-hour limit.

Authorization roles

Authorization roles define the permissions on accessing and using Endor Labs and its features. Each authorization role has a set of associated permissions that determine the extent of access to Endor Labs. Ensure that you assign the right role for the right situation and follow the principle of least privilege (PoLP).

You need to assign an authorization role when you create authorization policies and API keys.

The following roles are available:

Role Access Module Description API Role Parameter
Policy Editor Complete read and write access Policies and policy templates Primarily used to allow users to manage policies. SYSTEM_ROLE_POLICY_EDITOR
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 SYSTEM_ROLE_CODE_SCANNER
Read-only 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 SYSTEM_ROLE_READ_ONLY
Export Export SBOM and VEX
Admin Complete read and write access All modules Primarily used to grant complete access to the application SYSTEM_ROLE_ADMIN
On-Prem Scheduler Minimal CRUD access All modules Primarily used to manage Outpost and to use monitoring scans across supported platforms when you enable Outpost.

Authorization policies

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 role provided to an identity.
  • 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.

Set up authorization policies

To set up an authorization policy to your Endor Labs tenant:

  1. Sign in to Endor Labs and select Access Control from the left sidebar.
  2. Select Auth Policy and click Add Auth Policy.
  3. Select the identity provider for which you want to configure an authorization policy.
  4. Select the role to be granted to a matching identity.
  5. Select an expiration time for the authorization rule.
    • This may be either No expiration, 24 hours, 72 hours, one week, two weeks, or 30 days.
  6. 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.
    • For Azure these may be the user’s tenant ID, app ID, object ID and subscription ID.
  7. 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.
  8. 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.

Edit authorization policies

To edit an authorization policy:

  1. Navigate to Manage > 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 authorization policy

Delete authorization policies

To delete an authorization policy:

  1. Navigate to Manage > Access Control.
  2. Select 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. Navigate to Manage > Access Control.
  2. Select Auth Policy and click Grant Support Access.
  3. Select an expiration time for the access from the drop down menu.
  4. Click Grant Access.

Manage user invitations

Endor Labs provides attribute based access control to manage users across tenants. Provision User access to Endor Labs through one of the following methods:

  1. Send user invitations - Specifically invite a user through email to sign in using their own selected identity provider.
  2. Configure authorization policies - Define specific identities or attributes for a given identity to provide necessary access to Endor Labs. See Authorization policies for more information.

Invite users to Endor Labs

Invite specific users to access your Endor Labs tenant using their preferred external identity provider. When a user is sent an invitation to your tenant, they receive an invitation to sign in to Endor Labs with the identity provider of their choice. When a user accepts an invitation an authorization policy is created for them using their selected identity provider.

To invite a new user to Endor Labs:

  1. Select Manage > Settings on the left sidebar.
  2. Ensure you are on the Invitations top navigation tab.
  3. Click Invite your team.
  4. Enter the email address of the user that you would like to collaborate with. If you would like to invite multiple users enter their email addresses as a comma separated list.
  5. Click Invite Users.

An email will be sent to the email address inviting the user to your tenant namespace. The email will provide a link for them to access your tenant namespace, and they can start collaborating on your projects.

Invalidate a user invitation

To delete a user invitation:

  1. Select Manage > Settings on the left sidebar.
  2. Ensure you are on the Invitations tab.
  3. Choose an invitation that you would like to delete and click Delete.

AI access

The following features in the Endor Labs application access Artificial Intelligence (AI) services to enhance security analysis, code insights, and developer assistance. You can check whether AI access is currently enabled or disabled for these features.

  • LLM code processing Detects AI models from HuggingFace used in Python projects and lists them as dependencies. See View AI model findings.

  • DroidGPT Retrieves data from third-party AI tools and correlates it with Endor Labs’ proprietary risk data to identify open source software packages. See Use DroidGPT.

  • C/C++ embeddings Enhances detection capabilities of C and C++ software composition analysis (SCA) by using AI-generated embeddings. See Scan C and C++ projects.

Modify AI access

To modify AI feature settings:

  1. Select Settings > AI Access from the left sidebar.
  2. Click Contact us to submit a request to the support team.
  3. The support team will assist you with enabling or disabling AI features based on your organization’s needs.

Manage API keys

Use API keys to engage with Endor Labs services programmatically and enable any automation or integration with other systems in your environment. You can manage API keys with endorctl or from the Endor Labs user interface.

Create an API key

Create an API key to access Endor Labs services programmatically. You can create an API key through the Endor Labs user interface or using the Endor Labs API. You can create API keys with an expiry of up to one year from the Endor Labs user interface. You can use the API to generate API keys with longer expiry.

Create an API key through the Endor Labs user interface

  1. Select Access Control from the left sidebar.

  2. Select API Keys.

  3. Click Generate API Key.

  4. Enter a name to identify the API key.

  5. Select the roles to apply to the API Key.

    You can choose from the following options:

    • Admin
    • Read-only
    • Code Scanner
    • Policy Editor
    • On-Prem Scheduler
  6. Select the expiry of the API key.

    You can set the value as 30, 60, 90 days, or one year.

  7. When you create an API key, it applies to the current namespace and all its child namespaces.

    To prevent the policy from being applied to any child namespace, click Advanced and deselect Propagate this policy to all child namespaces.

Using these credentials, you can configure Endor Labs scans in your CI/CD pipeline, or set up the Endor Labs Visual Studio Code extension. Each session initiated by the API key is valid up to four hours. See scanning with endorctl and use Endor Labs extension in Visual Studio Code for details.

Create an API key through Endor Labs API

Run the following command to generate and API with the create APIKey endpoint.


endorctl api create -r APIKey --data '{
  "meta": {
    "name": "API Key name",
    "description": "API key description"
  },
  "spec": {
    "permissions": {
      "roles": ["SYSTEM_ROLE_ADMIN"]
    },
    "expiration_time": "2025-05-01T00:00:00Z"
  }
}

You can use the following values in spec.permissions.roles:

  • SYSTEM_ROLE_ADMIN
  • SYSTEM_ROLE_READ_ONLY
  • SYSTEM_ROLE_POLICY_EDITOR
  • SYSTEM_ROLE_CODE_SCANNER

See authorization roles for more information.

You can provide a specific value for the expiration date of the token. You can also set an expiry of over one year if required. You cannot edit the expiry after you create the API key. If you want to change the expiry, create a new API key with the required expiry date.

For example, you want to create an API key for a CI/CD pipeline that expires on March 31st 2026.

Run the following command to create an API key with SYSTEM_ROLE_CODE_SCANNER role so that you can use it for endorctl access from a CI/CD pipeline.


endorctl api create -r APIKey --data '{
  "meta": {
    "name": "CI/CD Access API key",
    "description": "API key for use within the CI/CD pipeline"
  },
  "spec": {
    "permissions": {
      "roles": ["SYSTEM_ROLE_CODE_SCANNER"]
    },
    "expiration_time": "2026-03-31T00:00:00Z"
  }
}'

{
  "meta": {
    "create_time": "2025-03-11T16:29:06.127975636Z",
    "created_by": "xxxxxx@endor.ai@google@api-key",
    "description": "API key for use within the CI/CD pipeline",
    "kind": "APIKey",
    "name": "CI/CD Access API key",
    "update_time": "2025-03-11T16:29:06.127975636Z",
    "updated_by": "xxxxxx@endor.ai@google@api-key",
    "version": "v1"
  },
  "spec": {
    "expiration_time": "2026-03-31T00:00:00Z",
    "issuing_user": {
      "meta": {
        "name": "xxxxxx@endor.ai@google@api-key"
      },
      "spec": {
        "email": "",
        "first_name": "",
        "last_login_time": "2025-03-11T16:29:06.114662511Z",
        "last_name": "",
        "user_name": ""
      }
    },
    "key": "endr+WjR4wZ1f5k9y2Odj",
    "permissions": {
      "roles": [
        "SYSTEM_ROLE_CODE_SCANNER"
      ]
    },
    "secret": "endr+LoVG3yYaNaaWlW3v"
  },
  "tenant_meta": {
    "namespace": "demo"
  },
  "uuid": "67dx6x6x6f69xxx777a41cda"
}

Delete an API Key

Delete the API keys that are expired or no longer in use. You can delete API keys using the Endor Labs user interface or using the Endor Labs API.

Delete an API key through the Endor Labs user interface

  1. Select Access Control from the left sidebar.
  2. Select API Keys.
  3. Find the API key that you want to delete and click the trash can icon at the far right.

Delete an API key through Endor Labs API

Run the following command to delete an API key with the delete APIKey endpoint.

endorctl api delete -r=APIKey --name=<API_Key_Name>

The command fails if there are multiple API keys with the same name. You can use the UUID to delete a specific API key.

endorctl api delete -r=APIKey --uuid=<API_Key_UUID>

Configure system settings

Administrators can configure the following settings to customize certain interactions with Endor Labs. These interactions include:

Configure data privacy settings

Use data privacy settings to manage how your scan logs are handled to improve monitoring and visibility.

To configure data privacy settings:

  1. Navigate to Manage > Settings from the left sidebar.
  2. Select SYSTEM SETTINGS > Data Privacy.
  3. Select Remote Logging to send scan logs to a centralized logging system for improved monitoring and debugging.

Data Privacy

Configure Endor patches settings

Use Endor Patches settings to activate auto patching for all your projects in your tenant with the supported ecosystems.

To configure Endor patches settings:

  1. Navigate to Manage > Settings from the left sidebar.
  2. Select SYSTEM SETTINGS > Endor Patches.
  3. Select Auto Patch Vulnerable Dependencies to apply vulnerability fixes to your applications without changing your code
  4. Click Save Patch Settings.

Endor Patches

Configure policy settings

Endor Labs comes with several out-of-the-box policies that help you ensure the security posture of your code repositories, detect secret leaks, discern license risks, and make your code compliant with the CIS benchmark. Endor Labs regularly updates its existing policies and also includes several new policies. Configure policy settings to ensure that you benefit from these regular updates.

To configure policy settings:

  1. Navigate to Manage > Settings from the left sidebar.

  2. Select SYSTEM SETTINGS > Policies & Rules.

  3. Select Enable Policies for New Features to ensure that new policies released by Endor Labs are automatically enabled for your projects.

    This ensures that the policies are automatically applied and you can view the generated findings.

  4. Select Upgrade Policies to Latest Version to ensure that any updates released by Endor Labs to the existing policies are automatically applied for your projects.

  5. Click Save Policy Settings.

policy settings

Configure SBOM settings

You can configure organizational settings that will be included in every one of your organization’s SBOMs. These settings allow you to meet NTIA requirements for minimum SBOM data fields which require supplier contact information for your organization.

To define your organization’s SBOM settings:

  1. Navigate to Manage > Settings from the left sidebar.
  2. Select SYSTEM SETTINGS > SBOM.
  3. Enter the following organizational SBOM settings as appropriate for your organization under SBOM Settings.
    • Organizational Name - The organization that supplied the library or application that the SBOM describes.
    • Contact Name - A contact at the organization for SBOM related inquiries.
    • Contact Email Address - The organizational contact’s email address.
    • Supplier URL - The website URL of the organization supplying the SBOM.
  4. Click Save SBOM Settings.

sbom settings

Set up namespaces

Namespaces in Endor Labs define a way to group projects and create logical partitions in an organization based on organizational units, business units, project requirements, or teams.

Using namespaces, administrators can:

  • Define hierarchy and control access to project resources within a namespace.
  • Establish policy governance by defining the rules of engagement and setting different or same guardrails across namespaces.

Namespaces in an organization

You can partition every tenant in Endor Labs into multiple namespaces and further partition each namespace into sub-namespaces. Every namespace has its own set of authorization rules and integrations.

When you sign in to Endor Labs for the first time, create a tenant for your organization, such as abccorp.

  • Now you can create logical separations in the form of namespaces for different business units in your organization, such as Security Business Unit (security-bu), Datacenter Business Unit (datacenter-bu), and Orchestration Agent Business Unit (orchestration-agent-bu), inside your main tenant abccorp.

  • You can further partition the Security Business Unit into sub-namespaces, such as the Development team (dev-team), Finance Team (finance-team), and Testing Team (testing-team).

Namespaces Example

  • There can be several namespaces within abccorp. For example, the dev-team namespace that hosts projects belonging to the development team of the Security Business Unit and the test-team namespace that hosts projects belonging to the testing team of the Security Business Unit.

Use namespaces for authorization

Large enterprises with multiple business units, teams, or groups can assign different namespaces to different groups and apply authorization policies that restrict access to specific groups. This ensures least privilege access to critical information is available in the organization.

Organizations can also provision namespaces to provide read access to security teams in specific namespaces while they provide write access to AppSec teams for managing policies.

  • Create an authorization policy giving users in the development team of the security business unit permissions to scan their projects. Users from group @developers.abccorp.ai can have code scanner permissions for the namespace dev-team.

  • Users from group @applicationsecurity.abccorp.ai can have policy editor permissions for the namespace dev-team. The developers can scan the code, and the application security professionals can define the policies for code compliance.

  • The application security professionals can also choose to define the policies at the tenant level abccorp and choose to apply the same policies to all the child namespaces. This way, they won’t need to create policies individually for every child namespace. The development team inherits the policies from the organization and won’t be able to modify them. They can, however, add additional policies that are specific to engineering to their namespace dev-team and define specific rules and conditions applicable only to them.

Use namespaces for policy governance

Administrators can use namespaces effectively for policy governance and make sure that teams in their organization adhere to industry-wide policy standards enforcing compliance. Let us assume that the application security team in ABCcorp wants to define organization-wide rules for code compliance, vulnerability management, and secret detection. They also need Jira tickets filed for all cases. The application security engineers can create the following objects at the ABCcorp tenant level and propagate these objects to all the namespaces under abccorp so that it applies to the entire organization.

  • Define action policy to break the build when critical vulnerabilities are detected.
  • Define action policy to warn the user of detected code compliance misconfigurations.
  • Define action policy to break the build when valid secret tokens are detected in their code.
  • Create Jira tickets and notify the appropriate team to take remediation measures.

Create a namespace

To create a namespace in your tenant:

  1. Sign in to Endor Labs.

  2. Select Manage > Namespaces from the left sidebar.

  3. Click New Namespace.

  4. Enter a title and description for the namespace.

    The title can have a maximum of 32 characters and must contain only lowercase letters (a-z), numbers (0-9), and characters (_-).

  5. Enter tags that you want to associate with this namespace.

    Tags can have a maximum of 63 characters and must contain letters (A-Z), numbers (0-9), and characters (=@_.-).

Edit a namespace

You can choose to modify the description of a namespace or include tags for it. You can’t modify its title once a namespace is created. To edit details of a namespace in your tenant:

  1. Sign in to Endor Labs.
  2. Select Manage > Namespaces from the left sidebar.
  3. Choose the namespace and click Edit.
  4. Edit the description or include tags for the namespace.
  5. Click Update Namespace.

Delete a namespace

Deleting a namespace permanently deletes all its child namespaces and its projects. To delete a namespace:

  1. Sign in to Endor Labs.
  2. Select Manage > Namespaces from the left sidebar.
  3. Choose the namespace and click Delete.
  4. Select and confirm the deletion.
  5. Click Delete Namespace.

Data propagation from parent to child namespaces

Data propagation defines how the data is inherited by the child namespace from its parent namespace.

  • Finding Policies - When a new namespace is created, all the finding policies in the parent are inherited by the child namespaces. Any new finding policy you create in the parent, you can choose to apply it to the child namespaces by selecting Propagate this policy to all child namespaces.

  • Action Policies - When a new namespace is created, all the action policies in the parent are inherited by the child namespaces. Any new action policy you create in the parent, you can choose to apply it to the child namespaces by selecting Propagate this policy to all child namespaces.

  • Package Manager Integrations - Package manager integrations of the parent are not inherited by the child namespaces. Any new package manager integration you create in the parent, you can choose to apply them to the child namespaces by selecting Propagate this package manager to all child namespaces.

  • Integrations - Integrations in the parent are not inherited by the child namespaces.

  • Authorization Policies - Authorization policies of the parent are inherited by all its child namespaces. You can choose to group the authorization policies of the child namespaces in their parent namespace and manage them easily.

  • Secret Rules - You can choose to apply custom secret rules created in the parent to its child namespaces by selecting Propagate this rule to all child namespaces.

Tenant and namespace terminologies

Tenant is the top-level entity under which you can create namespaces and child-namespaces.

To denote a namespace, always use its fully qualified name. Fully qualified name for a namespace is in the format tenantname.namespacename, and child namespace is in the format tenantname.namespacename.childnamespacename.

  • In this example, the tenant is abccorp and its child namespaces are abccorp.security-bu, abccorp.datacenter-bu, and abccorp.agent-bu. The child namespaces of abccorp.security-bu are abccorp.security-bu.dev-team, abccorp.security-bu.testing-team, and abccorp.security-bu.finance-team.
  • Consider a tenant named acme with a child namespace dev, which in turn has a child namespace app. The fully qualified namespace for app is acme.dev.app.

When you sign in to Endor Labs, you sign in to the tenant abccorp. To view data in abccorp with all its namespaces, select Include All Children. The data on all pages in Endor Labs includes information from all the child namespaces.

Configure proxy server settings

You must configure proxy settings on machines that need to connect to Endor Labs when Internet access is limited to proxy-only connections. These settings are required for running the endorctl client for scans, for self-hosted runners in CI/CD pipelines, and for using the Endor Labs REST API.

Configure web proxy

Set the following environment variables as system properties if you use Windows.

set HTTP_PROXY=http://username:password@<proxy-host>:<proxy-port>
set HTTPS_PROXY=https://username:password@<proxy-host>:<proxy-port>

You can also set the variables as User Variables in System > About > Advanced System Settings > Environment Variables.

You need to set the following environment variables as system properties if you use Linux or macOS.

export HTTP_PROXY=http://username:password@<proxy-host>:<proxy-port>
export HTTPS_PROXY=https://username:password@<proxy-host>:<proxy-port>

Configure proxy for NTLM authentication

If your proxy server uses NTLM authentication, set the following environment variables on machines that need to connect to Endor Labs when Internet access is limited to NTLM authenticated proxy-only connections.

export ENDOR_INSECURE_NTLM_USERNAME="your_username"
export ENDOR_INSECURE_NTLM_PASSWORD="your_password"
export ENDOR_INSECURE_NTLM_DOMAIN="your_domain"
export ENDOR_INSECURE_NTLM_PROXY_URL="<PROTOCOL>://<IP>:<PORT>"