Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atlantis UI protected by GitHub OAuth #49

Closed
atlantisbot opened this issue Mar 6, 2018 · 23 comments
Closed

Atlantis UI protected by GitHub OAuth #49

atlantisbot opened this issue Mar 6, 2018 · 23 comments
Labels
feature New functionality/enhancement

Comments

@atlantisbot
Copy link

Issue by @kiranpraneeth
Tuesday Feb 06, 2018 at 22:48 GMT
Migrated from hootsuite/atlantis#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

@atlantisbot
Copy link
Author

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.

@atlantisbot
Copy link
Author

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.

@lkysow lkysow changed the title Atlantis support for github Oauth Atlantis UI protected by GitHub OAuth Mar 16, 2018
@MrSaints
Copy link

As a temporary solution https://github.com/bitly/oauth2_proxy

@lkysow
Copy link
Member

lkysow commented Jun 19, 2018

@MrSaints thanks that looks promising. When #136 is worked on it should include something like this. Are you doing it yourself?

@MrSaints
Copy link

MrSaints commented Jun 19, 2018

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.

@lkysow
Copy link
Member

lkysow commented Jul 23, 2018

@NicholasGWK
Copy link

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

@lkysow
Copy link
Member

lkysow commented Feb 20, 2019

Hi Nick, I've just created #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.

@NicholasGWK
Copy link

Awesome! Thanks a ton for responding so quickly, looking forward to the docs :)

@lkysow lkysow added the feature New functionality/enhancement label Apr 4, 2019
@chenrui333
Copy link
Member

I submit a new issue, it might be quite similar to this, or might involved with more efforts in terms of integration efforts.

@jimmyjamesbaldwin
Copy link

jimmyjamesbaldwin commented Nov 25, 2019

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.

@bitfield
Copy link

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.

@lkysow
Copy link
Member

lkysow commented Jan 21, 2020

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.

@crisp2u
Copy link

crisp2u commented Jan 22, 2020

@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

@bitfield
Copy link

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!

@lkysow
Copy link
Member

lkysow commented Jan 22, 2020

@blacksd
Copy link

blacksd commented Apr 1, 2021

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 or oauth2_proxy protected Ingress to route all the paths /

I'd like to contribute to the Helm chart about this.

msarvar added a commit that referenced this issue Apr 1, 2021
* Orca 679 global atlantis lock new release branch (#49)

* Adding CommandLocker to boltDB and exposing it through locker interface

* Apply lock ui and apply command lock controller

* Minor comments

* Adding more tests and refactorinng

* Linting fixes

* creating applyLockingClient variable to fix interface error

* nullsink for stats

* Addressing PR comments

* fixing e2e tests

* linting fix fml

* Update outdated function descriptions

Address PR comments

* revert stats sink changes

* remove unnecessary dependencies
@ayk33
Copy link

ayk33 commented Jul 19, 2021

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 or oauth2_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?

@blacksd
Copy link

blacksd commented Jul 19, 2021

@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.

@ayk33
Copy link

ayk33 commented Jul 19, 2021

@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.

msarvar added a commit that referenced this issue Aug 20, 2021
* Adding CommandLocker to boltDB and exposing it through locker interface

* Apply lock ui and apply command lock controller

* Minor comments

* Adding more tests and refactorinng

* Linting fixes

* creating applyLockingClient variable to fix interface error

* nullsink for stats

* Addressing PR comments

* fixing e2e tests

* linting fix fml

* Update outdated function descriptions

Address PR comments

* revert stats sink changes
@jamengual
Copy link
Contributor

atalntis now supports basic auth and an oauth proxy can deploy on front if needed.

jamengual pushed a commit that referenced this issue Nov 23, 2022
* Adding CommandLocker to boltDB and exposing it through locker interface

* Apply lock ui and apply command lock controller

* Minor comments

* Adding more tests and refactorinng

* Linting fixes

* creating applyLockingClient variable to fix interface error

* nullsink for stats

* Addressing PR comments

* fixing e2e tests

* linting fix fml

* Update outdated function descriptions

Address PR comments

* revert stats sink changes
@jmreicha
Copy link
Contributor

Is there an example of the oauth proxy sidecar config? Might be worth adding to docs, I would be happy to add it.

@jamengual
Copy link
Contributor

#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement
Projects
None yet
Development

No branches or pull requests