Skip to content

Commit e6079e7

Browse files
authored
Merge pull request #44 from XenitAB/readme-improvements
Readme improvements
2 parents 6259984 + 28dca61 commit e6079e7

File tree

1 file changed

+11
-11
lines changed

1 file changed

+11
-11
lines changed

README.md

+11-11
Original file line numberDiff line numberDiff line change
@@ -2,20 +2,20 @@
22

33
[![Go Report Card](https://goreportcard.com/badge/github.com/XenitAB/git-auth-proxy)](https://goreportcard.com/report/github.com/XenitAB/git-auth-proxy)
44

5-
Proxy to allow multi tenant sharing of GitHub and Azure DevOps credentials in Kubernetes.
5+
Proxy to allow multi-tenant sharing of GitHub and Azure DevOps credentials in Kubernetes.
66

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)
7+
Most Git providers offer multiple 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 solution to [create a machine user](https://docs.github.com/en/developers/overview/managing-deploy-keys#machine-users)
99
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)
1010
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.
1111

1212
<p align="center">
1313
<img src="./assets/architecture.png">
1414
</p>
1515

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
16+
Git Auth Proxy attempts to solve this problem by implementing its own authentication and authorization layer in between the client and the Git provider. It works by generating static tokens that are
1717
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
18+
proxy, the token will be checked against 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
1919
repository which is does not have access to.
2020

2121
## How To
@@ -50,7 +50,7 @@ configured for Git Auth Proxy to append to authorized requests. Note that organi
5050
}
5151
```
5252

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
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 encoded string in the
5454
configuration file. Note that the project field is not required when using GitHub as projects do not exists in GitHub.
5555

5656
```json
@@ -60,8 +60,8 @@ configuration file. Note that the project field is not required when using GitHu
6060
"provider": "github",
6161
"github": {
6262
"appID": 123,
63-
"installationID: 123,
64-
"privateKey: "<BASE64>"
63+
"installationID": 123,
64+
"privateKey": "<BASE64>"
6565
},
6666
"host": "github.com",
6767
"name": "xenitab",
@@ -83,15 +83,15 @@ Add the Helm repository and install the chart, be sure to set the config content
8383

8484
```shell
8585
helm repo add https://xenitab.github.io/git-auth-proxy/
86-
helm install git-auth-proxy --set config=<config>
86+
helm install git-auth-proxy --set config=<config-json>
8787
```
8888

8989
There should now be a `git-auth-proxy` Deployment and Service in the cluster, ready to proxy traffic.
9090

9191
### Git
9292

9393
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).
94+
only proxies HTTP(S) 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).
9595
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.
9696

9797
```shell
@@ -113,7 +113,7 @@ to the host `api.github.com`.
113113
Execute the following command to list all pull requests in the repository `repo-1` using the local token to authenticate to the proxy.
114114

115115
```shell
116-
curl http://<token-1>@git-auth-proxy/org/proj/_apis/git/repositories/repo-1/pullrequests?api-version=5.1
116+
curl https://<token-1>@git-auth-proxy/org/proj/_apis/git/repositories/repo-1/pullrequests?api-version=5.1
117117
```
118118

119119
> :warning: **If you intend on using a language specific API**: Please read this!

0 commit comments

Comments
 (0)