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

server: require web login if an env var is set #25057

Merged
merged 1 commit into from
Apr 26, 2018

Conversation

vilterp
Copy link
Contributor

@vilterp vilterp commented Apr 24, 2018

This PR introduces the temporary environment variable COCKROACH_EXPERIMENTAL_REQUIRE_WEB_LOGIN to enable testing login functionality before a fully functional login/logout UI is merged. Supersedes #24944, which hardcoded this.

Once we have a functional login/logout UI, we will probably hardcode this variable to true, so that login will always be required when the cluster is in secure mode.

Before this change:

After this change:

  • secure mode
    • with env var COCKROACH_EXPERIMENTAL_REQUIRE_WEB_LOGIN=true:
      • Admin server endpoints require some user to be logged in, although they still run queries (e.g. against crdb_internal) as the root user.
      • /_auth/v1/login is exposed, allowing clients such as the admin UI to log in.
    • else:
      • no auth (same as before)
  • insecure mode
    • no auth (same as before)

@vilterp vilterp requested review from couchand, mrtracy and a team April 24, 2018 20:14
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Contributor

@mrtracy mrtracy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing to consider: there is an interaction with the "insecure" flag which is called out in the RFC for web session logins. Once login is released, it will be on by default for secure servers, but disabled for insecure servers. This is important because, in turn, it allows our frontend to detect whether or not authentication is enabled simply by checking the protocol (HTTP vs HTTPS). Otherwise, you need an additional mechanism to communicate this setting to the frontend so that it knows whether or not to require a login.

In other words: I think the system for enabling/disabling login is more complicated than is expressed here, i'm not sure we should be checking anything in until its fully considered.

@@ -386,7 +386,7 @@ func MakeConfig(ctx context.Context, st *cluster.Settings) Config {
ScanInterval: defaultScanInterval,
ScanMaxIdleTime: defaultScanMaxIdleTime,
EventLogEnabled: defaultEventLogEnabled,
EnableWebSessionAuthentication: defaultEnableWebSessionAuthentication,
EnableWebSessionAuthentication: envutil.EnvOrDefaultBool("COCKROACH_REQUIRE_WEB_LOGIN", false),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this to a top-level var and reference it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@vilterp
Copy link
Contributor Author

vilterp commented Apr 24, 2018

@mrtracy the env var only applies if we're in secure mode. Just updated the description to reflect that.

It's true that this is just to avoid myself, @couchand, and anyone else who is trying to test login having to twiddle a hardcoded boolean over the next couple months, so we can do that if necessary.

@mrtracy
Copy link
Contributor

mrtracy commented Apr 25, 2018

LGTM

Copy link
Contributor

@couchand couchand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I mentioned to you yesterday, I'm not sure this is worth it. It's doesn't seem to make things that much easier for us, and there's a risk involved.

Changing a line of code screams "this really isn't done yet". Adding an env var (even one with EXPERIMENTAL in the name) seems like maybe it's okay to do.

@@ -376,6 +375,8 @@ func MakeConfig(ctx context.Context, st *cluster.Settings) Config {
panic(err)
}

requireWebLogin := envutil.EnvOrDefaultBool("COCKROACH_REQUIRE_WEB_LOGIN", false)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is added it should definitely have EXPERIMENTAL in the name.

Release note (admin ui change): require web login if the environment
variable COCKROACH_REQUIRE_WEB_LOGIN is set to true.
@vilterp vilterp requested a review from a team April 25, 2018 22:22
@vilterp
Copy link
Contributor Author

vilterp commented Apr 25, 2018

Changed to COCKROACH_EXPERIMENTAL_REQUIRE_WEB_LOGIN.

bors r+

@craig
Copy link
Contributor

craig bot commented Apr 25, 2018

Build failed

@vilterp
Copy link
Contributor Author

vilterp commented Apr 26, 2018

bors r+

craig bot pushed a commit that referenced this pull request Apr 26, 2018
25057: server: require web login if an env var is set r=vilterp a=vilterp

This PR introduces the temporary environment variable `COCKROACH_REQUIRE_LOGIN` to enable testing login functionality before a fully functional login/logout UI is merged. Supersedes #24944, which hardcoded this.

Once we have a functional login/logout UI, we will probably hardcode this variable to true, so that login will always be required when the cluster is in secure mode.

Before this change:
- Admin server endpoints don't care whether there is a logged-in user or not, even in secure mode; they always run as the root user (#8767)
- There is no way to log in — the `/_auth/v1/login` endpoint 404s

After this change:
- secure mode
    - with env var `COCKROACH_REQUIRE_LOGIN=true`:
        - Admin server endpoints require _some user_ to be logged in, although they still run queries (e.g. against `crdb_internal`) as the root user.
        - `/_auth/v1/login` is exposed, allowing clients such as the admin UI to log in.
    - else:
        - no auth (same as before)
- insecure mode
    - no auth (same as before)

Co-authored-by: Pete Vilter <vilterp@cockroachlabs.com>
@craig
Copy link
Contributor

craig bot commented Apr 26, 2018

Build succeeded

@craig craig bot merged commit a35b8d3 into cockroachdb:master Apr 26, 2018
Web UI automation moved this from Sprint: In Progress to Sprint: Done Apr 26, 2018
@vilterp vilterp deleted the require-login-env-var branch April 26, 2018 01:57
craig bot pushed a commit that referenced this pull request May 22, 2018
25005: ui: add top-level LoginContainer: require login before rendering anything r=couchand a=vilterp

Depends on #25057 
Touches #24939

![](https://user-images.githubusercontent.com/7341/39150096-38b4cd28-470f-11e8-9d67-e1832d35a211.gif)

Shown above:
1. go to admin UI; see login screen
2. error message when you type in the wrong password
3. you can't hit an authenticated endpoint because you don't have a valid session (this checking is turned on by #24944, only in secure mode)
4. once you login with the right password, you can see the UI (the temporary "connection lost" banner shouldn't be there)
5. now you (and the UI itself) can hit endpoints, because you have a valid session

Todos:
- [ ] redirect to login page instead of current wrapper component switching thing
- [ ] logout
    - [ ] logout button (make API call; redirect to login & blow away redux store)
    - [ ] log out other tabs (if they get a 403, redirect to login & blow away redux store)
- [ ] styling

Release note: None

25628: distsql: support lookup join on secondary index r=solongordon a=solongordon

joinReader now supports lookup joins on secondary indexes. This was a
trivial change for queries where all the output columns are included in
the secondary index. I just modified the physical planner to specify the
secondary index in the JoinReaderSpec and removed checks which prevented
secondary indexes from being used.

The more complicated situation is when we want to do a lookup join
against a non-covering index. In this case, the logical planner plans an
index join before the inner join, but we want to perform the lookup join
first. We now handle this by only planning the lookup join during
physical planning, not the index join. During execution, the joinReader
detects that there are output columns not covered by the secondary
index, and it performs primary index lookups as necessary to retrieve
the additional columns.

Fixes #25431

Co-authored-by: Pete Vilter <vilterp@cockroachlabs.com>
Co-authored-by: Andrew Couch <andrew@cockroachlabs.com>
Co-authored-by: Solon Gordon <solon@cockroachlabs.com>
@piyush-singh piyush-singh moved this from Sprint: Done to 2.1 Release: Done in Web UI Jun 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants