Programmatic access with machine users

All access to Anaconda Platform is centrally authenticated and authorized. Human users authenticate through your SSO system. External systems that do not correspond to a human user, such as a CI/CD pipeline, authenticate as machine users. A machine user is a service account: a platform managed identity that authenticates with credentials issued by an external provider, such as GitHub Actions, CircleCI, GitLab, or AWS IAM, instead of a person’s SSO login. Like human users, machine users receive per-perimeter privileges, so you control exactly what each automated system can do. For more information, see What is a user? and Roles and privileges. Admin only

Creating a machine user

Select Users in the left-hand navigation, then select the Machines tab.
Click Create New.
Select the machine user type that matches the system you are connecting, then enter a Name and Description.
Enter the claim values for the selected type, as described in the sections below.
Click Submit.

After you create the machine user, click it in the list to view a generated sample configuration for that type, such as a GitHub Actions workflow or a CircleCI config, that shows how to authenticate as the machine user and trigger flows.

Choosing an identity provider

For OIDC-based types, the Attributes to validate section of the form lists the claims from the provider’s OIDC token that the platform validates during authentication. A machine user can only be used by jobs whose token claims match the values you enter. The available claims depend on the system you are connecting. Select your provider for details:

GitHub Actions jobs authenticate as machine users with OIDC tokens (JWTs) issued by GitHub. A job requests a token and uses it to authenticate to the platform to run, deploy, and trigger flows.The form asks for the claims that appear in GitHub’s OIDC token:

Organization: The GitHub organization that owns the repository.
Repository: The repository that runs the jobs.
Branch: Optional. If set, only jobs triggered from this branch can use the machine user.
Environment: Optional. If set, only jobs running within this environment can use the machine user.
Workflow: Optional. If set, only jobs running with this workflow name can use the machine user.

The generated sample workflow shown after creation includes the token request and authentication commands.

CircleCI jobs authenticate as machine users with OIDC tokens (JWTs) issued by CircleCI. CircleCI exposes these tokens to jobs as the $CIRCLE_OIDC_TOKEN and $CIRCLE_OIDC_TOKEN_V2 environment variables, and either token can authenticate to the platform.The form asks for the claims that appear in CircleCI’s OIDC token:

Organization ID: The UUID of the CircleCI organization. Find it on the Overview page of Organization Settings in CircleCI.
Project ID: The UUID of the CircleCI project. Find it on the Overview page of Project Settings in CircleCI.
Source Control Repository: The URL of the source control repository without the protocol, such as github.com/<ORGANIZATION>/<REPOSITORY>.
Branch: Optional. If set, only jobs triggered from this branch can use the machine user.

GitLab CI/CD jobs authenticate as machine users with OIDC tokens (JWTs) issued by GitLab through the id_tokens keyword. GitLab exposes the token to your pipeline as a CI variable, which the pipeline uses to authenticate to the platform.The form asks for the claims that appear in GitLab’s OIDC token:

Project ID: The GitLab project’s identification number. Find it in General Settings in your repository on GitLab.
Project Name: The name of the GitLab project. For https://gitlab.com/<NAMESPACE>/my-project, the project name is my-project.
Project Namespace Path: The namespace path of the GitLab project. For https://gitlab.com/<NAMESPACE>/my-project, the namespace path is <NAMESPACE>.
Branch: Optional. The branch from which GitLab jobs authenticate as this machine user.
Environment: Optional. The environment from which GitLab jobs authenticate as this machine user.
Pipeline Source: Optional. The source type that triggered the pipeline, such as push.
GitLab JWKS URL: Set this if you host your own GitLab instance. The form pre-fills https://gitlab.com/oauth/discovery/keys for gitlab.com.

The aud value is not set automatically.GitLab evaluates id_tokens when the pipeline is created, before any scripts run. Set the aud: value in your .gitlab-ci.yml to your Anaconda Platform URL. The value cannot be templated from obproject.toml. For the YAML pattern, see CI/CD integration.

Systems that can assume an AWS IAM role authenticate as machine users through that role. Most CI/CD systems, microservices, and cloud environments have established, secure ways to provide AWS credentials, so the platform can rely on the same mechanism to authenticate machine users.Enter the role’s ARN in the IAM Role ARN field. The platform links the role ARN to the machine user for authentication.

Preparing the role

The role needs a permission policy that lets it read the platform’s authentication secrets. The policy references the platform’s control plane account ID, which Anaconda provides. If the role resides in a different AWS account than your deployment, Anaconda must also register that account. Contact Anaconda support to get the control plane account ID and register your account. Registering an account is a one-time operation; machine users you add later in the same account do not need further registration.To prepare the role:

In the AWS Console, create or choose an IAM role in the account where your external system runs.
Navigate to IAM, then Policies, and click Create policy.

In the policy editor, select the JSON view and add the following statements:

{
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:<REGION>:<CONTROL_PLANE_ACCOUNT_ID>:secret:*"
},
{
    "Effect": "Allow",
    "Action": "kms:Decrypt",
    "Resource": "arn:aws:kms:<REGION>:<CONTROL_PLANE_ACCOUNT_ID>:key/*"
}

Name the policy and create it, then attach it to the role from the role’s Add permissions menu.

The role is now ready to use with machine users.

Azure DevOps Pipelines authenticate as machine users with OIDC tokens issued through Microsoft Entra workload identity federation. The pipeline’s AzureCLI@2 task obtains the token when addSpnToEnvironment: true is set against a configured Azure service connection, and passes it to outerbounds service-principal-configure with --jwt-token.The auth chain involves two objects you set up together:

An Azure DevOps service connection in your Azure DevOps project, federated to a Microsoft Entra app registration. Set this up in your Azure DevOps Project Settings under Service Connections.
An Azure DevOps machine user on the platform. When you create the machine user, the form lists the claim fields the OIDC token carries, such as the Microsoft Entra tenant ID, the app (client) ID, the Azure DevOps organization URL, and the project name.

The platform validates the Microsoft Entra claims when the pipeline attempts to authenticate. The service connection on the Azure DevOps side makes those claims available to the pipeline in the first place.For the corresponding YAML pattern, see Using Anaconda Platform with Azure DevOps.

Using a machine user

After you create a machine user, open it from the list on the Machines tab and select a machine user from the list. The page shows an example configuration specific to that machine user, such as a GitHub Actions workflow or a GitLab CI configuration, that you can copy into your repository and adapt to your use case. The example handles installation and configuration of the outerbounds package for the CI/CD workflow environment, authenticating as the machine user with the credential for its type. For example, GitHub Actions machine users authenticate with GitHub’s OIDC token, and GitLab machine users authenticate with GitLab’s OIDC token. Once configured, the CI/CD environment can run Metaflow flows, access artifacts, and deploy workflows programmatically as the machine user, within the privileges you granted.

Anaconda Platform

Getting Started

Platform Guides

Programmatic access with machine users

Creating a machine user

Choosing an identity provider

Preparing the role

Using a machine user

​Creating a machine user

​Choosing an identity provider

​Preparing the role

​Using a machine user

Creating a machine user

Choosing an identity provider

Preparing the role

Using a machine user