Skip to main content
An integration gives a task access to a service outside its environment.

OpenID Connect (OIDC) tokens

A task can mint a short-lived Niteshift identity token for an audience chosen by the external service. You can ask the agent to generate a token for you or you can run this commend in the task termina, replacing the audience with the one that service expects:
The issuer is https://identity.niteshift.dev (discovery document). Minting a token does not grant access to another service by itself; configure access for the identity on the service side.

AWS

Niteshift’s AWS integration configures AWS tools and libraries to authenticate with Niteshift using an OIDC token. Niteshift handles obtaining and refreshing credentials. The easiest way to set up the configuration is to ask the agent to help you integrate with AWS. It will help you set up configuration both within Niteshift and AWS, and it will help you verify that it’s working. Within Niteshift, the configuration lives within settings.yaml. You can declare each AWS profile that you want to configure:
settings.yaml
You need to have at least one default profile. On the AWS side, you’ll need to configure an OIDC identity provider for identity.niteshift.dev, and a trust policy for each role to trust tokens from that issuer. AWS’s OIDC role guide explains the AWS-side trust and permissions policies. Run ns oidc-token --inspect --audience 'sts.amazonaws.com' in the Niteshift terminal tab to see the trust values without printing the token.

Azure

Niteshift also have a native Azure integration that configures Niteshift environments to integrate with Azure using an OIDC token. Niteshift handles fetching and refreshing credentials. The easiest way to set up the integration is to ask the agent to do it. It will help you with the configuration both within Niteshift and within Azure, and it will verify that it works. For the Niteshift configuration, declare the Microsoft Entra tenant ID and the identity’s client ID in the environment’s committed settings.yaml:
settings.yaml
Within Azure, you’d need to configure a federated credential and assign permissions to Azure resources that it needs. See Microsoft Entra’s federated credential guide for the Azure-side trust setup. Run ns oidc-token --inspect --audience 'api://AzureADTokenExchange' in the Niteshift terminal tab to see the trust values without printing the token.

Environment variable secrets

You can also integrate with systems by having Niteshift store API keys or secrets. You can store secrets as environment variables in Niteshift settings, outside the repository. The Setup script scope is available to .niteshift/setup and .niteshift/resume. The separate Agent scope is available to the agent and its terminal, including commands it runs. Services do not inherit either scope. To give a managed service a secret, store it in Setup script and reference its name with secret in the services.yaml file. Service secret references cannot read Agent scope variables.