-
Notifications
You must be signed in to change notification settings - Fork 847
/
restricting-access.any
140 lines (116 loc) · 5.92 KB
/
restricting-access.any
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
#language anatomy
\use{\load{concourse/docs}}
\template{\load{concourse/docs-template}}
\title{Restricting Access}{authentication}
\warn{
This topic isn't crucial to understanding Concourse; if you're just getting
started and have finished the \reference{installing} section, you may want to
first move on to \reference{using-concourse}.
}
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.
\section{Logging In}{
\section{Basic Authentication}{
HTTP Basic authentication is the simplest of the authentication mechanisms.
It has good support in both browsers and command line tools. It provides a
single set of credentials for all users of the system.
You can enable HTTP Basic authentication by setting the
\code{atc.basic_auth_username} and \code{atc.basic_auth_password}
properties (or their corresponding flags if you're not using BOSH,
\code{--basic-auth-username} and \code{--basic-auth-password}). If you're
using the \code{tsa} component too then make sure that you update its
properties to allow it to talk to the \code{atc} too.
}
\section{OAuth}{
\section{GitHub}{github-auth}{
A Concourse server can authenticate against GitHub to take advantage of
their permission model and other security improvements in their
infrastructure. There are a number of steps you need to take to enable
this.
\ordered-list{
First you need to
\hyperlink{https://github.com/settings/applications/new}{create an OAuth
application on GitHub}.
The name, home page, and description don't
matter but should be set to something that lets users trust their
origin. The \italic{Authorization callback URL} should be the external
URL of your Concourse server with \code{/auth/github/callback} appended.
e.g. For Concourse's own CI server this would be
\code{https://ci.concourse.ci/auth/github/callback}.
}{
You will be given a Client ID and a Client Secret for your new
application. You need to pass these to Concourse
(\code{atc.github_auth.client_id}, \code{atc.github_auth.client_secret}
or appropriate command line flags) along with setting the external URL
of the Concourse server (\code{atc.external_url} or command line flag).
}{
You're now able to set the organizations, teams, and individual users
who should have access to your server.
In BOSH you would set the \code{atc.github_auth.authorize} property with
something like the following:
\codeblock{yaml}{
- organization: org1
teams: all
- organization: org2
teams: [team1, team2]
- user: user1
- user: user2
}
This allows any member of \code{org1}, members of \code{team1} or
\code{team2} from \code{org2}, or users \code{user1} or \code{user2} to
authenticate with the server.
To do the same without BOSH you would provide the equivalent
\code{--github-auth-organization=ORG},
\code{--github-auth-team=ORG/TEAM}, and \code{--github-auth-user=LOGIN}
multiple times to achieve the same effect.
When using Github Enterprise as an authentication provider, specify the
following properties:
\code{--github-auth-auth-url=https://github.example.com/login/oauth/authorize},
\code{--github-auth-token-url=https://github.example.com/login/oauth/access_token},
\code{--github-auth-api-url=https://github.example.com/api/v3/}. Make sure the API URL ends with a slash!
}
}
\section{Future Providers}{
An integration with a Cloud Foundry deployment and the UAA backing it will
probably be next.
We've written the authentication layer of Concourse to be easily
extendable. Adding a new OAuth provider is as simple as adding a few
interface implementations and feeding them any information they need from
the command line.
We'd be interested in hearing about any providers with which you'd like to
integrate.
}
}
Any number of the above 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.
}
\section{Permissions}{
\section{Publicly Viewable}{
If you enable \code{atc.publicly_viewable} (or the flag
\code{--publicly-viewable}) then unauthenticated users are able to see a
safe, read-only view of your Concourse server. They are able to see the main
pipeline overviews, the list of pipelines, the status of builds, and
resource information. They are not able to see build output.
This feature is useful if you're using Concourse for an open source project
and you'd like your community to be able to see into your build pipeline.
}
\section{Public Builds}{
If you have builds that you \italic{do} want unauthenticated users to be
able to see the build logs of a job then you can set \code{public: true} on
a job in your pipeline definition. This will always default to \code{false}
and require you to opt-in to making the potentially sensitive output public.
If you have a build that contains no secrets then consider letting people
see your build logs.
}
}
\section{Development Mode}{
To disable all authentication and authorization the \code{--development-mode}
flag can be passed to \code{atc}. This is useful when developing Concourse
locally or when using Concourse as a simple build worker locally. It should
never be used in production!
}