Configuring Connections

Azure DevOps

There are two types of Azure DevOps connections in TeamCity:

• Azure DevOps OAuth 2.0 allows signing in to TeamCity via an Azure DevOps Services account and creating TeamCity projects from Azure Git and TFVC repositories.

• Azure DevOps PAT allows creating TeamCity projects from Azure Git and TFVC repositories.

Bitbucket Cloud

A connection to Bitbucket Cloud can be used to:

• Create a project from Bitbucket URL.

• Create a VCS root from URL.

• Create a Mercurial VCS root.

• Integrate with a Bitbucket Cloud issue tracker.

• Enable Bitbucket Cloud authentication.

The Bitbucket Cloud connection form provides multiple parameters. You need to use them for creating a new OAuth consumer in Bitbucket.

After the consumer is created:

1. Copy its key and secret.

2. Go back to the connection form in TeamCity.

3. Paste the key and secret.

4. Save the connection.

A Bitbucket icon will become active in several places where a repository URL can be specified. Click it to authorize TeamCity in your Bitbucket profile. TeamCity will be granted access to your repositories. If you configure multiple Bitbucket connections, the server URL will be displayed next to each icon, so it is easier to distinguish the server in use.

GitHub

There are two types of GitHub connections: GitHub Enterprise and GitHub.com. Choose it depending on your GitHub account type.

A connection to GitHub can be used to:

• Create a project from GitHub URL.

• Create a VCS root from URL.

• Create a Git VCS root.

• Integrate with a GitHub issue tracker.

• Enable GitHub.com authentication.

The GitHub connection form provides multiple parameters. You need to use them to create a new OAuth application in GitHub.

After the app is created:

1. Copy its client ID and secret.

2. Go back to the connection form in TeamCity.

3. Paste the GitHub server URL (only for Enterprise) and the app ID and secret.

4. Save the connection.

If you use a GitHub Enterprise server with HTTPS, you need to also upload its HTTPS certificate as described here.

A GitHub icon will become active in several places where a repository URL can be specified. Click it to authorize TeamCity in your GitHub profile. TeamCity will be granted full control of your private repositories and get the Write repository hooks permission. If you configure multiple GitHub integrations, the server URL will be displayed next to each icon, so it is easier to distinguish the server in use.

GitLab

There are two types of GitLab connections: GitLab CE/EE and GitLab.com. Choose it depending on your GitHub account type.

A connection to GitLab can be used to:

• Create a project from GitLab URL.

• Create a VCS root from URL.

• Integrate with a GitLab issue tracker.

• Enable GitLab.com authentication.

The GitLab connection form provides multiple parameters. You need to use them to create a new OAuth application in GitLab.

After the app is created:

1. Copy its client ID and secret.

2. Go back to the connection form in TeamCity.

3. Paste the GitLab server URL (only for CE/EE) and the app ID and secret.

4. Save the connection.

If you use a GitLab CE/EE server with HTTPS, you need to also upload its HTTPS certificate as described here.

A GitLab icon will become active in several places where a repository URL can be specified. Click it to authorize TeamCity in your GitLab profile. TeamCity will be granted access to your repositories. If you configure multiple GitLab connections, the server URL will be displayed next to each icon, so it is easier to distinguish the server in use.

Google

This type of connection supports Google Services. It uses the OAuth 2.0 protocol.

This connection is used for authentication in TeamCity with a Google account.

Before configuring a Google connection, you need to create a new Google project and register your app if you have not done it before.

To configure a Google connection in TeamCity:

1. In the Administration area, select Root project | Connections, and click Add Connection.

2. Select Google as the connection type.

3. TeamCity will display the redirect URLs required for registering an OAuth client. Copy them.

4. Go to the Credentials page in the Google project and create the OAuth client ID with the Web application type.

5. Paste your Callback URLs to the Authorized redirect URIs section in Google OAuth client ID. When the OAuth client is created, copy the Client ID and Client Secret.

6. Go back to the connection form in TeamCity, and enter the Client ID and Client secret.

7. Save the connection.

Now you can enable the Google authentication module.

Docker Registry

A connection to Docker Registry can be used to:

• Sign in to an authenticated Docker registry before running a build / sign out after the build.

• Clean up published images after the build.

See more information in the dedicated article.

Amazon Web Services (AWS)

The Amazon Web Services (AWS) connection allows defining AWS credentials once and using them in builds via the AWS Credentials build feature. You can use different AWS credential types: access keys, IAM Role, and the Default credential provider chain.

To configure an AWS connection in TeamCity:

1. In Project Administration | Connections, click Add Connection.

2. Select Amazon Web Services (AWS) as the connection type.

3. Provide a name to distinguish this connection from others.

4. The Connection ID field is filled out automatically. You can modify it and provide your own unique ID.

5. Select the AWS region where the target resources are located.

6. From the Type drop-down, select one of the credential types:

   Access keys

   If you selected access keys as the credentials type, get the keys from the AWS console's Identity and Access Management section and provide them to TeamCity. See how to get these keys here.

   In the Access keys section in the TeamCity UI, do the following:

   1. Specify permanent Access keys:

      • Access key ID. Enter the access key ID.

      • Secret access Key. Enter the secret access key.

      It is recommended to change access keys regularly for security reasons. You will be able to do this after the connection is created via the Rotate key button.

      TeamCity will not revoke old keys immediately. After a new key is generated, TeamCity will preserve the old inactive key for 24 hours and then remove it. The lifetime of old keys can be changed via the following properties: teamcity.internal.cloud.aws.keyRotation.old.key.preserve.time.min or teamcity.internal.cloud.aws.keyRotation.old.key.preserve.time.days.

      To be able to successfully rotate access keys, TeamCity requires the iam:GetUser, iam:CreateAccessKey, and iam:DeleteAccessKey permissions.

   2. Configure temporary Session Settings:

      • Use session credentials. Check the box to use an endpoint that provides temporary access keys via AWS STS. Such credentials are short-term (the default session duration is 60 minutes). You can override the default session duration in the AWS Credentials build feature. These credentials do not belong to a specific user and can be provided on demand to grant temporary access to specific resources. We recommend using temporary credentials since they provide better security.

      • STS endpoint.

        • TeamCity generates this field automatically when changing the AWS region. The regional endpoint is recommended because it is faster and has lower latency. In addition, all calls to the regional endpoint are logged in AWS Cloud Trail as any regional service call.

        • Use the global endpoint if the selected regional endpoint is disabled on the Amazon account and you do not want to enable it.

        • Contact the TeamCity support team if you need to specify a custom endpoint for Amazon alternatives like MinIO.

   IAM Role

   Using IAM roles, you can delegate access to your AWS resources to users, applications, or services that usually don't have these permissions. These entities will assume this role to get such access.

   You can use the IAM Role as the credentials type only if you already have at least one AWS connection with access keys or default credential provider chain configured in this TeamCity project.

   1. Specify IAM Role:

      • AWS Connection. Select the AWS connection that will grant the specified IAM Role.

      • Role ARN. Specify the ARN of the role to assume by the connection you are creating.

   2. Configure Session settings:

      • Session tag. The session tag is required by Amazon. It is useful to locate sessions created by the TeamCity connection in AWS logs. TeamCity generates the tag automatically, but you can specify your own value.

      • STS endpoint.

        • TeamCity generates this field automatically when changing the AWS region. The regional endpoint is recommended because it is faster and has lower latency. In addition, all calls to the regional endpoint are logged in AWS Cloud Trail as any regional service call.

        • Use the global endpoint if the selected regional endpoint is disabled on the Amazon account and you do not want to enable it.

        • Contact the TeamCity support team if you need to specify a custom endpoint for Amazon alternatives like MinIO.

   After the connection is created, you can view and copy the automatically generated external connection ID. We strongly recommend that you always add it to the trust policy in AWS to prevent the confused deputy problem. This ensures that only authorized TeamCity AWS connections will be able to use the specified IAM Role.

   Default credential provider chain

   Select this type to provide access credentials according to the default chain. This approach provides an alternatives to storing credentials in plain text.

   To mitigate this risk, the Default credential provider chain credentials type is disabled by default. To enable it, set the internal property teamcity.internal.aws.connection.defaultCredentialsProviderEnabled=true. (The default value is false.) No server restart is required after the property is set. When this credentials type is used, TeamCity searches for credentials in the following order:

   1. Java System Properties: aws.accessKeyId and aws.secretAccessKey.

   2. Environment Variables: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

   3. Web Identity Token credentials from system properties or environment variables.

   4. Credential profiles file in the default location (~/.aws/credentials) shared by all AWS SDKs and the AWS CLI. The default location can be overridden via the AWS_SHARED_CREDENTIALS_FILE environment variable.

   5. Credentials delivered via the Amazon EC2 container service if the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable is set and the security manager has access to it.

   6. Instance profile credentials delivered through the Amazon EC2 metadata service.

7. Test and save the connection.

Now you can use the credentials provided by this connection in your builds. To do that, configure the AWS Credentials build feature.

Amazon ECR

An Amazon ECR (Elastic Container Registry) connection allows accessing private and public AWS registries. With its help, the Docker Support build feature can store Docker images produced by a build to AWS.

Connection settings:

Slack

This type of connection is used to enable notifications via Slack.

Before configuring a Slack connection, you need to create a Slack app with the following bot token scopes: channels:read, chat:write, im:read, im:write, users:read, team:read, groups:read. You can add these in Features | OAuth & Permissions | Scopes of your Slack app.

To ensure your TeamCity server can connect to Slack, specify all the possible endpoint addresses of the server as Redirect URLs in Features | OAuth & Permissions. In most cases, it would be enough to specify the Server URL set in Global Settings in TeamCity. However, if you use a proxy for your TeamCity server but access this server directly, the authentication in Slack might not work unless the server's IP address is also specified in Redirect URLs.

Now you can return to TeamCity, add a new Slack connection, and enter the following connection parameters:

• Client ID and secret from the app's Basic Information page

• A bot user token of your app

Save the connection and proceed with adding a Notifier build feature.

JetBrains Space

This type of connection can be used for:

• Publishing build statuses in JetBrains Space with the help of Commit Status Publisher.

• Authenticating in TeamCity with a JetBrains Space account.

• Creating projects, build configurations, and VCS roots from a JetBrains Space repository.

• Starting builds on merge requests created in a JetBrains Space repository.

Before configuring this connection, you need to create a dedicated application in JetBrains Space:

1. Go to Administration | Applications and click New application.

2. Enter a convenient name and save the application.

3. Go to the app's Authorization tab and click Configure requirements under the In-context Authorization section. Enter the name of the Space project you are about to access from TeamCity.

4. Now, you need to set permissions that will be granted to the app in this project. Click Configure and enable the following permissions:

   • Required for authentication and Pull Requests:

     • Members | View member profile

   • Required for Commit Status Publisher:

     • Git Repositories | Report external check status

   • Required for Pull Requests:

     • Code Review | View code reviews

   You can approve project-level permissions right in this Authorization tab if you are the project's administrator. Global permissions like viewing a member profile require a server administrator's approval.

5. Go back to the app's Overview and open the Authentication tab.

6. Enable Client Credentials Flow.

7. To be able to use authentication via Space in TeamCity or/and to create projects/configurations from Space repositories, enable Authorization Code Flow as well. Enter your TeamCity server's URL as the redirect URI.
   To ensure that your TeamCity server can always connect to JetBrains Space, specify all the other possible endpoint addresses of the server. In most cases, it would be enough to specify the Server URL set in Global Settings in TeamCity. However, if you use a proxy for your TeamCity server but access this server directly, the authentication might not work unless the server's IP address is also specified here.

8. Copy the app's Client ID and Client secret.

Note: When you create a project in JetBrains Space, it does not automatically add you to this project as a member — this needs to be done manually. TeamCity will be able to see only those projects where you are listed as a member.

Now you can return to TeamCity, add a new JetBrains Space connection, and enter the following connection parameters:

• URL of the Space server

• Client ID and secret of your Space application

Save the connection and proceed with adding a Commit Status Publisher or Pull Requests feature, enabling Space authentication, or creating a project / build configuration / VCS root.

NPM Registry

This type of connection allows accessing a private npm registry during a build.

Connection settings:

Save the connection and proceed with adding an NPM Registry Connection build feature.

Perforce Administrator Access

This type of connection allows processing task streams on your Perforce server. In the connection settings, enter the host and user credentials for accessing the Perforce server (the user must have the admin permission).