Closed atlantisbot closed 2 years ago
Comment by @lkysow Wednesday Feb 07, 2018 at 04:35 GMT
Are you asking about building Atlantis as a GitHub OAuth app (https://developer.github.com/apps/building-oauth-apps/) instead of adding it as a webhook?
Also, can you elaborate on what you mean by using OAuth to authenticate users to Atlantis? Just trying to understand.
Comment by @majormoses Monday Feb 19, 2018 at 03:20 GMT
I think the ask is to make sure that atlantis is only available to specific users. We do the same thing with our Jenkins, you authenticate to Jenkins with your github credentials and if you are not part of the org or users specified you are denied access.
As a temporary solution https://github.com/bitly/oauth2_proxy
@MrSaints thanks that looks promising. When #136 is worked on it should include something like this. Are you doing it yourself?
Yes - we opted for deploying Atlantis using Docker on a single VM (no Kubernetes). We managed to get it working on Kubernetes too, but decided to keep it simple. Everything can be bootstrapped in a relatively small cloudinit script.
For others looking at this, you can also whitelist requests from Github/Gitlab/Bitbucket IP addresses:
Sorry if this is the wrong place to post, but I was wondering if there's a good explanation somewhere of the security concerns / capabilities of the Atlantis UI?
I wasn't able to find anything in the docs about how locked down it should be, or if people are mostly just using basic auth etc. If all you can do dismiss locks it's probably fine to be somewhat public, but just curious if there are other implications!
Thanks, loving Atlantis so far!
Nick
Hi Nick, I've just created https://github.com/runatlantis/atlantis/issues/485 to add some documentation around this.
You're right that all it's used for is to dismiss locks, however given that Atlantis is often deployed with important credentials, I would definitely want to lock it down. This would protect against something like an exploit in the gin http framework Atlantis uses.
Awesome! Thanks a ton for responding so quickly, looking forward to the docs :)
I submit a new issue, it might be quite similar to this, or might involved with more efforts in terms of integration efforts.
Just wondering - have there been any updates on this (ability to lock down the UI)? Even something relatively simple like basic auth would be quite handy.
I would also find it really useful to be able to simply turn on basic auth using a setting in values.yaml
. This is currently a blocker for clients considering adopting Atlantis, as they otherwise have no way of securing the front end.
Why is it a blocker? They (or you) need to front Atlantis with nginx or something to handle the auth. If you're in Kubernetes this should be doable with a sidecar container.
Yes it would be nice to have it built in. PRs are welcome.
@bitfield I implemented a custom docker with nginx but it's a bit messy. I'll try to give oauth2_proxy a test and maybe come back with a dockerfile
Why is it a blocker? They (or you) need to front Atlantis with nginx or something to handle the auth.
It's not that it couldn't be done with some engineering time. But that's exactly what's at a premium. They want something that's built-in, controlled by a setting in a YAML file.
As a matter of fact adding basic auth wasn't as hard as I feared it might be. All I needed to do to add basic auth to the Atlantis front end was to create the required secret, as described here: https://kubernetes.github.io/ingress-nginx/examples/auth/basic/
and add the following to values.yaml
:
ingress:
enabled: true
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: basic-auth
nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"
This seems like it's something that would be great to add to the docs!
Nice! I'd suggest adding it as a PR here: https://github.com/runatlantis/atlantis/blob/master/runatlantis.io/docs/security.md
I think that the correct way to do it should be:
/events
path into the applicationbasic-auth
or oauth2_proxy
protected Ingress to route all the paths /
I'd like to contribute to the Helm chart about this.
I think that the correct way to do it should be:
- define an unauthenticated Ingress routing only the
/events
path into the application- create a separate,
basic-auth
oroauth2_proxy
protected Ingress to route all the paths/
I'd like to contribute to the Helm chart about this.
How would you achieve this with the ingress though? Can you have basic auth limited to specific path or rule?
@ayk33 I think you can, if you narrow down the ingress to a single path. Then you make a second one with the unrestricted paths.
@blacksd ahh okay yeah that makes sense. I was trying to figure out how to do it with 1 ingress. Alright this would definitely require a change to the helm chart.
atalntis now supports basic auth and an oauth proxy can deploy on front if needed.
Is there an example of the oauth proxy sidecar config? Might be worth adding to docs, I would be happy to add it.
https://github.com/runatlantis/atlantis/issues/485
the deployment is dependent on if you use ECS, K8s, EKS, or others but basically, anything that is not /events will need to be sent to the proxy.
Issue by @kiranpraneeth Tuesday Feb 06, 2018 at 22:48 GMT Migrated from https://github.com/hootsuite/atlantis/issues/243 Why was it migrated?
It would be great if we can have Oauth callback ability in Atlantis. That would avoid us from being relying on our own HTTP auth methods and rather just use GitHub OAuth to authenticate users to Atlantis. I looked at closed and open issues but didn't find any issues in regards to OAuth. Can you throw some light on this?
Thanks