Cette page n'est pas encore disponible en français, sa traduction est en cours. Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.
Overview
Private actions allow your Datadog workflows and apps to interact with services hosted on your private network without exposing your services to the public internet. To use private actions, you must install a private action runner on a host in your network and pair the runner with a Datadog Connection. For more information on setting up a runner and pairing it with a connection, see Private Actions.
Some private actions, such as Jenkins and PostgreSQL, require credentials to function. To configure credentials for a private action, you must:
Navigate to the directory where you stored your runner’s configuration (default: config/credentials/).
In this directory, create a JSON file using the JSON structure provided in Credential files. Alternatively, edit the default JSON file automatically generated during runner bootstrap.
Note: These files are available to the runner in its /etc/dd-action-runner/credentials/ directory.
Specify the path to the credential in the runner’s connection. Use the path to the file on the container. For example: /etc/dd-action-runner/credentials/jenkins_token.json.
Credential files
HTTP supports three authentication methods:
Basic authentication: Use when your HTTP server requires username and password authentication.
Token authentication: Use when your HTTP server requires one or more custom tokens in headers or query parameters.
No authentication: Use when your HTTP server does not require authentication.
Basic authentication
Basic authentication requires a credential file with a username and a password:
Replace USERNAME and PASSWORD with your username and password.
In the runner’s connection, specify the location of the credential file on the private action runner’s container. In this example, the credential file is stored at /etc/dd-action-runner/credentials/http_basic.json.
Token authentication
Token authentication requires a credential file with an array of token names and values:
Replace TOKEN1, TOKEN2, VALUE1, and VALUE2 with your token names and values.
In the runner’s connection, specify the location of the credential file on the private action runner’s container. In this example, the credential file is stored at /etc/dd-action-runner/credentials/http_token.json.
No authentication
This connection type is suitable for HTTP endpoints that do not require authentication.
To configure this connection, specify the endpoint URL:
The GitLab connection accepts the following credentials:
Credential
Required
Description
baseURL
Yes
The URL of your self-managed GitLab instance. For more information, see GitLab API documentation.
gitlabApiToken
Yes
The API token to authenticate with your GitLab instance. Generate this token in your GitLab user settings.
Replace GITLAB_API_TOKEN and GITLAB_URL with your credentials.
In the runner’s connection, specify the location of the credential file on the private action runner’s container. In this example, the credential file is stored at /etc/dd-action-runner/credentials/gitlab_token.json.
The Jenkins connection accepts the following credentials:
Credential
Required
Description
domain
Yes
The domain of the Jenkins server that you want to connect to.
username
Yes
The username of the Jenkins user that you want to use to authenticate with the Jenkins server. This user must have the necessary permissions to perform the actions you want your runner to perform.
token
Yes
The API token of the Jenkins user that you want to use to authenticate with the Jenkins server. This user must have the necessary permissions to perform the actions you want to perform. You can generate an API token in the Jenkins user settings.
Replace USERNAME, API_TOKEN, and DOMAIN with your credentials.
In the runner’s connection, specify the location of the credential file on the private action runner’s container. In this example, the credential file is stored at /etc/dd-action-runner/credentials/jenkins_token.json.
MongoDB supports two authentication methods:
SRV authentication: Use when connecting to MongoDB Atlas or when you need automatic replica set discovery and failover. This method uses a DNS SRV record to automatically discover all members of a replica set.
Standard authentication: Use when connecting directly to a MongoDB server or when you need to specify the exact host and port.
SRV authentication
The MongoDB SRV authentication requires the following credentials:
Credential
Required
Description
username
Yes
The MongoDB username for authentication.
password
Yes
The MongoDB password for authentication.
srvHost
Yes
The SRV host for MongoDB Atlas or replica set discovery.
Replace USERNAME, PASSWORD, SRV_HOST, and DATABASE with your credentials.
In the runner’s connection, specify the location of the credential file on the private action runner’s container. In this example, the credential file is stored at /etc/dd-action-runner/credentials/mongodb_srv_token.json.
Standard authentication
The MongoDB Standard authentication accepts the following credentials:
Credential
Required
Description
username
Yes
The MongoDB username for authentication.
password
Yes
The MongoDB password for authentication.
host
Yes
The hostname of the MongoDB server.
port
Yes
The port number of the MongoDB server.
database
No
The name of the database to connect to.
authSource
No
The database containing the user’s credentials. Specify if the user is created in a different database than admin.
authMechanism
No
The authentication mechanism to use. Specify if a specific authentication mechanism is required.
Replace USERNAME, PASSWORD, HOST, PORT, DATABASE, AUTH_SOURCE, and AUTH_MECHANISM with your credentials.
In the runner’s connection, specify the location of the credential file on the private action runner’s container. In this example, the credential file is stored at /etc/dd-action-runner/credentials/mongodb_standard_token.json.
The PostgreSQL connection accepts the following credentials:
The port number to connect to at the server host, or socket filename extension for UNIX-domain connections. For more information, see the official PostGreSQL documentation.
In the runner’s connection, specify the location of the credential file on the private action runner’s container. In this example, the credential file is stored at /etc/dd-action-runner/credentials/postgresql_token.json.
The Temporal supports three authentication methods:
mTLS authentication: Use for the most secure communication with two-way server to client certificate authentication.
TLS authentication: Use for secure communication with server certificate authentication.
No authentication: Use for unencrypted communication (not recommended for production environments).
mTLS authentication
The Temporal mTLS authentication requires the following credentials:
Credential
Required
Description
serverAddress
Yes
The server address (hostname and optional port). If undefined, port defaults to 7233.
serverNameOverride
Yes
The server name that overrides the target name (SNI) used for TLS host name checking. This can be useful when you have a reverse proxy in front of a temporal server and want to override the SNI to route traffic to the appropriate backend based on custom rules.
serverRootCACertificate
Yes
The root CA certificate used by the server. If not set, and if the server’s certificate is issued by a trusted authority, verification will still succeed (for example, if using a cloud provider like AWS, Google Cloud, or Azure, which issue server certificates through trusted, recognized CAs).
Replace SERVER_ADDRESS, SERVER_NAME_OVERRIDE, SERVER_ROOT_CA_CERTIFICATE, CLIENT_CERTIFICATE, and CLIENT_KEY with your credentials.
In the runner’s connection, specify the location of the credential file on the private action runner’s container. In this example, the credential file is stored at /etc/dd-action-runner/credentials/temporal_mTLS_token.json.
TLS authentication
The Temporal TLS authentication requires the following credentials:
Credential
Required
Description
serverAddress
Yes
The server address (hostname and optional port). If undefined, port defaults to 7233.
serverNameOverride
Yes
The server name that overrides the target name (SNI) used for TLS host name checking. This can be useful when you have a reverse proxy in front of a temporal server and want to override the SNI to route traffic to the appropriate backend based on custom rules.
serverRootCACertificate
Yes
The root CA certificate used by the server. If not set, and if the server’s certificate is issued by a trusted authority, verification will still succeed (for example, if using a cloud provider like AWS, Google Cloud, or Azure, which issue server certificates through trusted, recognized CAs).
Replace SERVER_ADDRESS, SERVER_NAME_OVERRIDE, and SERVER_ROOT_CA_CERTIFICATE with your credentials.
In the runner’s connection, specify the location of the credential file on the private action runner’s container. In this example, the credential file is stored at /etc/dd-action-runner/credentials/temporal_TLS_token.json.
No authentication
This connection type uses unencrypted communication and is not recommended for production environments. It should only be used in development environments or for testing connections. For production use, consider using either the TLS or mTLS authentication types.
The connection type requires the following credentials:
Credential
Required
Description
address
Yes
The server hostname and optional port. Port defaults to 7233 if address contains only host.
For this connection type, you do not need to create a credential file since the address is not a secret and is stored directly in Datadog. To configure, provide the server address: