Concourse

Configuring Team Auth

Continuous Integration servers often contain a considerable number of secrets to let them access source code and deploy applications. It is important that those secrets remain well guarded. Concourse provides options for both authentication and authorization to give you control over who can access your server and how much they can see.

If you access your Concourse server over the public internet then all of the options below are useless without using TLS to secure your connection.

The authentication methods for teams are determined by flags passed to fly set-team, except for the main team, which is configured as part of the deployment.

Any number of the following providers can be enabled at any one time. Users will be given a choice when logging in as to which one they would like to use.

In order to use any of the auth providers listed below, you must first enable the provider by configuring any required information at deployment time as per the Configuring Auth Providers guide.

Local Auth

You can grant local users access to a team via the --local-user flag.

For example:

$ fly set-team -n my-team \
    --local-user some_username

GitHub Auth

You can configure which organizations, teams, and individual users should have access to your team.

This is done by passing the following flags:

--github-user=LOGIN

Authorize an individual user.

--github-org=ORG_NAME

Authorize an entire organization's members.

--github-team=ORG_NAME:TEAM_NAME

Authorize a team's members within an organization.

For example:

$ fly set-team -n my-team \
    --github-user my-github-login \
    --github-org my-org \
    --github-team my-other-org:my-team

GitLab Auth

You can configure which groups and individual users should have access to your team.

This is done by passing the following flags:

--gitlab-user=USERNAME

Authorize an individual user.

--gitlab-group=GROUP_NAME

Authorize an entire groups's members.

For example:

$ fly set-team -n my-team \
    --gitlab-user my-gitlab-user \
    --gitlab-team my-team

CF Auth

You can configure which org/space members from a CF deployment should have access to your team.

--cf-user=USERNAME

Authorize an individual user.

--cf-org=ORG_NAME

Authorize an entire organization's members.

--cf-space=ORG_NAME:SPACE_NAME

Authorize the members of a space within an organization.

For example:

$ fly set-team -n my-team \
    --cf-user my-username \
    --cf-org my-org \
    --cf-space my-other-org:my-space

Generic oAuth

You can configure users and groups from a generic oAuth provider.

You may only configure groups if the auth provider exposes this information in either the token itself, or in the contents of the userinfo endpoint. You can configure which claim points to the groups information by specifying the groups-key at startup.

--oauth-user=USERNAME

Authorize an individual user.

--oauth-group=GROUP_NAME

Authorize anyone from the group.

For example:

$ fly set-team -n my-team \
    --oauth-user my-username \
    --oauth-group my-group

Generic OIDC

You can configure users and groups from a generic OIDC provider. This is very similar to the oAuth connector. The main difference being that OIDC providers must adhere to the OIDC specification, whereas generic oAuth providers can be a little more flexible.

You may only configure groups if the auth provider exposes this information in the contents of the userinfo endpoint. You can configure which claim points to the groups information by specifying the groups-key at startup.

--oidc-user=USERNAME

Authorize an individual user.

--oidc-group=GROUP_NAME

Authorize anyone from the group.

For example:

$ fly set-team -n my-team \
    --oidc-user my-username \
    --oidc-group my-group

Debugging Team Auth Configuration

You can list users and groups for all teams pertaining how the team is created based on group or individual user. Helpful for troubleshooting.

For example:

$ fly -t target teams -d

When authentication errors occur look at concourse TSA logs.

Also, make sure workers and web UI are restarted when fundamental changes occur to the auth configurations (i.e. changing the callback URL.)