You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[![Docker Repository on Quay](https://quay.io/repository/xenitab/azdo-proxy/status"Docker Repository on Quay")](https://quay.io/repository/xenitab/azdo-proxy)
Proxy to allow sharing of a Azure DevOps Personal Access Token in a Kubernetes cluster.
5
+
Proxy to allow multi tenant sharing of GitHub and Azure DevOps credentials in Kubernetes.
7
6
8
-
Azure DevOps allows the use of Personal Access Tokens (PAT) to authenticate access to both its
9
-
API and Git repositories. Sadly it does not provide an API to create new PAT, making the process
10
-
of automation cumbersome if multiple tokens are needed with limited scopes.
7
+
Most Git providers offer mutliple ways of authenticating when cloning repositories and communicating with their API. These authentication methods are usually tied to a specific user and in the best
8
+
case offer the ability to scope the permissions. The lack of organization API keys leads to solutions like GitHubs soltution to [create a machine user](https://docs.github.com/en/developers/overview/managing-deploy-keys#machine-users)
9
+
that has limited permissions. The need for machine user accounts is especially important for GitOps deployment flows with projects like [Flux](https://docs.github.com/en/developers/overview/managing-deploy-keys#machine-users)
10
+
and [ArgoCD](https://github.com/argoproj/argo-cd). These tools need an authentication method that supports accessing multiple repositories, without sharing the global credentials with all users.
11
11
12
12
<palign="center">
13
13
<imgsrc="./assets/architecture.png">
14
14
</p>
15
15
16
-
Azure DevOps Proxy (azdo-proxy) is an attempt to solve this issue by enabling a single PAT
17
-
to be shared by many applications, while at the same time limiting access for each application.
18
-
Tokens are generated automatically and written as a Kubernetes secrets to one or multiple namespaces,
19
-
the application just needs to mount the secret and use it when communicating with the proxy.
20
-
Requests are sent to azdo-proxy together with a token, which gives access to a specific repository.
21
-
The request is checked and if allowed forwarded to Azure DevOps with the PAT appended to the request.
16
+
Git Auth Proxy attemps to solve this problem by implementing its own authentication and authorization layer inbetween the client and the Git provider. It works by generating static tokens that are
17
+
specific to a Git repository. These tokens are then written to a Kubernetes secret in the Kubernetes namespaces which should have access to the repositories. When a repository is cloned through the
18
+
proxy, the token will be checked agains the repository cloned, and if valid it will be replaced with the correct credentials. The request will be denied if a token is used to clone any other
19
+
repository which is does not have access to.
22
20
23
21
## How To
24
22
25
-
Start off by [creating a new PAT](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page) as it has to be given to the proxy.
23
+
The proxy reads its configuration from a JSON file. It contains a list of repositories that can be accessed through the proxy and the Kubernetes namespaces which should receive a Secret.
24
+
25
+
When using Azure DevOps a [PAT](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page) has to be
26
+
configured for Git Auth Proxy to append to authorized requests.
26
27
27
-
The proxy reads its configuration from a JSON file. The file will contain the PAT used to authenticate
28
-
requests with, the Azure DevOps organization, and a list of repositories that can be accessed through
29
-
the froxy from the specified namespaces.
30
28
```json
31
29
{
32
30
"organizations": [
33
31
{
32
+
"provider": "azuredevops",
33
+
"azuredevops": {
34
+
"pat": "<PAT>"
35
+
},
36
+
"host": "dev.azure.com",
34
37
"name": "xenitab",
35
-
"pat": "foobar",
36
38
"repositories": [
37
39
{
38
40
"name": "fleet-infra",
@@ -48,42 +50,81 @@ the froxy from the specified namespaces.
48
50
}
49
51
```
50
52
53
+
When using GitHub a [GitHub Application](https://docs.github.com/en/developers/apps) has to be created and installed. The PEM key needs to be extracted and passed as a base64 endoded string in the
54
+
configuration file. Note that the project field is not required when using GitHub as projects do not exists in GitHub.
55
+
56
+
```json
57
+
{
58
+
"organizations": [
59
+
{
60
+
"provider": "github",
61
+
"github": {
62
+
"appID": 123,
63
+
"installationID: 123,
64
+
"privateKey: "<BASE64>"
65
+
},
66
+
"host": "github.com",
67
+
"name": "xenitab",
68
+
"repositories": [
69
+
{
70
+
"name": "fleet-infra",
71
+
"namespaces": [
72
+
"foo",
73
+
"bar"
74
+
]
75
+
}
76
+
]
77
+
}
78
+
]
79
+
}
80
+
```
81
+
51
82
Add the Helm repository and install the chart, be sure to set the config content.
There should now be a azdo-proxy Pod and Service in the cluster, ready to proxy traffic.
89
+
There should now be a `git-auth-proxy` Deployment and Service in the cluster, ready to proxy traffic.
58
90
59
91
### Git
60
92
61
-
Cloning a repository through the proxy is not too different from doing so directly from Azure DevOps.
62
-
The only limitation is that it is not possible to clone through ssh, as azdo-proxy only proxies HTTP traffic.
63
-
To clone the repository `repo-1`[get the clone URL from the repository page](https://docs.microsoft.com/en-us/azure/devops/repos/git/clone?view=azure-devops&tabs=visual-studio#get-the-clone-url-to-your-repo).
64
-
Then replace the host part of the URL with `azdo-proxy` and add the token as a basic auth parameter. The result should be similar to below.
93
+
Cloning a repository through the proxy is not too different from doing so directly from GitHub or Azure DevOps. The only limitation is that it is not possible to clone through ssh, as Git Auth Proxy
94
+
only proxies HTTP traffic. To clone the repository `repo-1`[get the clone URL from the repository page](https://docs.microsoft.com/en-us/azure/devops/repos/git/clone?view=azure-devops&tabs=visual-studio#get-the-clone-url-to-your-repo).
95
+
Then replace the host part of the URL with `git-auth-proxy` and add the token as a basic auth parameter. The result should be similar to below.
Authenticated API calls can also be done through the proxy. Currently only repository specific
72
-
requests will be permitted. This may change in future releases. As an example execute the
73
-
following command to list all pull requests in the repository `repo-1`.
103
+
API calls can also be done through the proxy. Currently only repository specific requests will be permitted as authorization is done per repository. This may change in future releases.
104
+
105
+
#### GitHub
106
+
107
+
The proxy assumes that the requests sent to it are in a GitHub enterprise format due to the way GitHub clients behave when configured with a host that is not `github.com`. The main difference between
108
+
GitHub Enterprise and non GitHub Enterprise is the API format. The GitHub Enterprise API expects all requests to the API to have the prefix `/api/v3/` while non GitHub Enterprise API requests are sent
109
+
to the host `api.github.com`.
110
+
111
+
#### Azure DevOps
112
+
113
+
Execute the following command to list all pull requests in the repository `repo-1` using the local token to authenticate to the proxy.
> :warning:**If you intend on using a language specific API**: Please read this!
79
120
80
121
Some APIs built by Microsoft, like [azure-devops-go-api](https://github.com/microsoft/azure-devops-go-api), will make a request to the [Resource Areas API](https://docs.microsoft.com/en-us/azure/devops/extend/develop/work-with-urls?view=azure-devops&tabs=http#how-to-get-an-organizations-url)
81
-
which returns a list of location URLs for a specific organization. They will then use those URLs
82
-
when making additional requests, skipping the proxy. To avoid this you need to explicitly create
83
-
your client instead of allowing it to be created automatically.
122
+
which returns a list of location URLs for a specific organization. They will then use those URLs when making additional requests, skipping the proxy. To avoid this you need to explicitly create your
123
+
client instead of allowing it to be created automatically.
84
124
85
125
In the case of Go you should create a client in the following way.
0 commit comments