contiv / auth_proxy

A proxy + UI server for Contiv which handles authentication (local users/LDAP/AD) + authorization (RBAC)

Auth Proxy

auth_proxy provides authentication (local users/LDAP/AD) and authorization (RBAC) before forwarding requests to an upstream netmaster. It is TLS-only, and it will only talk to a non-TLS netmaster. Future versions will allow or potentially require TLS-only communication with netmaster.

auth_proxy also hosts the Contiv UI (see the contiv-ui repo). The UI is baked into the container and lives at the /ui directory. It is served from the root of the proxy, e.g., if you run with --listen-address=localhost:10000, you can see the UI at https://localhost:10000

A custom version of the UI can be bindmounted over the baked-in version. Note that you need to bind in the /app directory under the contiv-ui repo, not the base directory (e.g., -v /your/contiv-ui/repo/app:/ui:ro)

Building

Running make will generate a contiv/auth_proxy:devbuild image using the current code you have checked out and HEAD from the master branch in the contiv-ui repo.

You can also specify a version, e.g., BUILD_VERSION=0.1 make. This will generate a contiv/auth_proxy:0.1 image using current code you have checked out and whatever commit is tagged as 0.1 in the contiv-ui repo.

Version Checking

auth_proxy will check the version of the netmaster it's pointed to at startup. We require that the major versions are the same and that the minor version of netmaster is >= the minor version of auth_proxy.

For example, version 1.2.3 of auth_proxy will only talk to a netmaster build version of 1.x.y where x is >= 2 and y can be anything.

Running Tests

Tests currently run against the contiv/auth_proxy:devbuild image. Make sure you have built this image before running tests.

Just run make test to run the systemtests and unit tests. The tests are fully containerized and will spawn everything they require as part of the test run (note that this does NOT currently include an AD server, and we are still using a hardcoded one).

There is also a MockServer available in the systemtests directory which can pretend to be netmaster for the purposes of testing. This allows us to mock the parts of netmaster we need (mainly that a given endpoint returns some expected JSON response) without the burden of actually compiling and running a full netmaster binary and all of its dependencies plus creating the necessary networks, tenants, etc. to get realistic responses from it.

For a complete e2e setup involving auth_proxy + UI + netmaster, please see contiv/install.

Local Development

You will need a certificate and key to start auth_proxy. You can run make generate-certificate to generate a self-signed certificate and key under ./local_certs if you don't already have them.

To test auth_proxy in isolation, use make run to start it using the compose file.

Architecture Overview

Before anything else, a prospective user must authenticate and get a token. Authentication requires passing a username and password to the /api/v1/auth_proxy/login/ endpoint:

login request ---> auth_proxy ---> authentication
                                                \
                                                 local user *or* LDAP / Active Directory
                                                /
<---- token sent to client <---- auth_proxy ----

Subsequent requests must pass this token along in a X-Auth-Token request header. All non-login requests are simply passed on to the netmaster if authentication and authorization are both successful.

Example of a full request cycle:

1. A request for /api/v1/networks/ is sent in with a token in the X-Auth-Token header
2. The user represented by the token is authenticated against a local DB or LDAP / Active Directory
3. An authorization check is performed to see if the user is allowed to access the resource in question (networks)
4. If both authentication and authorization are successful, the request is proxied to netmaster
5. If the user is not an admin and the endpoint returns data for multiple tenants, the response from netmaster will be filtered to only return what the current user is allowed to see

request w. token ---> auth_proxy ---> authorization ----> request forwarded to netmaster
                                                                                        \
                                                                                         netmaster
                                                                                        /
<----- results filtered based on token and returned to client <----- auth_proxy --------

auth_proxy's Issues

Add system tests for CRUD operations on Authorizations

Systems tests for PR #28

make on this repo expects selinux to be disabled

Removing intermediate container 6b502ffc9852
Successfully built 64510ee4cdbf
Running gofmt...
Running ineffassign...
Running golint...
Running govet...
Running gocyclo...
Running misspell...
Running deadcode...
SELinux is currently in enforcing mode.  This build script will not successfully execute.
You can temporarily disable SELinux via `setenforce 0` and reenable it with `setenforce 1`.
Exiting.

Is it really required ?

Built-in users password update

Follow up for #27.

Users should be able to change built-in user's (admin, ops) password. Only password should be changed not other fields (disable).

rename NO_NETMASTER_STARTUP_CHECK to SKIP_NETMASTER_STARTUP_CHECK

The current name is bad and I feel bad about it.

Proposal: Support Casbin as the authorization module

Hi, Casbin is an authorization library that supports models like ACL, RBAC, ABAC.

Related to RBAC, Casbin has several advantages:

1. roles can be cascaded, aka roles can have roles.
2. support resource roles, so users have their roles and resource have their roles too. role = group here.
3. the permission assignments (or policy in Casbin's language) can be persisted in files or database (MySQL and Cassandra).

And you can even customize your own access control model, for example, mix RBAC and ABAC together by using roles and attributes at the same time. It's very flexible.

Casbin can provide more flexibility and security than the current RBAC. I can make PR if needed. Let me know if there's any question:) Thanks.

All responses should be JSON

And they should have a Content-Type: application/json; charset=utf-8 response header

Errors in API responses should be in JSON

#28 (diff)

Technically, everything we return from the API should be JSON... we might want to make a generic errorJSON(w, "foo") that returns a response like the following if we don't already have one:

{
    "error":"foo"
}

Reset login password

Hi there,

I would like to know if it's possible to reset the password of the admin user account?

I saw that in the ETCD there is a password hash:

[root@node1 contiv]# etcdctl get /auth_proxy/local_users/admin
{"username":"admin","first_name":"","last_name":"","disable":false,"password_hash":"JDJhJDEzJGY2ZkhSU2E5NTg2bTRDTV......TmZhR0dJS1VFdm1WTnFzYTR6UTZH"}

What kind of hash is this? SHA256? If so it should be no problem to reset the password, right?

etcdctl set /auth_proxy/local_users/admin <JSON with new PW hash>

Perhaps this could be added to the documentation.

Thanks.

Regards,
Philip

/login endpoint should return the token in the body of the response

Rather than in a response header

LDAP / AD host and port should be configurable by a command-line flag

test network & containers get left behind on build failure

My changes couldn't be compiled. The test setup started by make test got left behind on my Docker daemon. I had to remove the containers and the Docker network to get rid of them.

Perhaps we could do something to ensure we only spin up the test environment after we're sure we can run the auth_proxy:devbuild image?

UT for auth flow prototype

Unit testing for #7

UT suites

#13 (comment)

Need way to install auth_proxy to run on a different port

auth_proxy runs on port 10000.

Problem is, my corporate network (aka. Cisco Lab) blocks port 10000. This makes it rather difficult to get to the Contiv GUI with a web browser.

Instead I'd like to use a more standard port, such as 443.

The work around I was given was to modify install/ansible/env.json and insert the following entry:
"auth_proxy_port" : "443"

Then run the installer as normal.

However when auth_proxy comes up, it's still on port 10000. I verified this by using my Mac (on Blizzard, not Cisco Lab) to load the webpage.

Here is my modified env.json:

{
  "auth_proxy_port":"443",  "docker_version":"1.12.6",
  "aci_gw_image":"contiv/aci-gw:latest",
  "contiv_network_version":"v1.0.0-alpha-01-28-2017.10-23-11.UTC",
  "env":{ "http_proxy":"", "HTTP_PROXY":"", "https_proxy":"", "no_proxy":",127.0.0.1,localhost,netmaster" },
  "etcd_peers_group": "netplugin-master",
  "service_vip": "172.31.6.66",
  "validate_certs": "no",
  "cluster_store": "etcd://54.219.167.152:2379",
  "auth_proxy_image": "contiv/auth_proxy:1.0.0-beta.2",
  "docker_reset_container_state": __RESET__,
  "docker_reset_image_state": __RESET_IMAGES__,
  "etcd_cleanup_state": __RESET__,
  "auth_proxy_local_install": False,
  "contiv_network_local_install": False
}

The original env.json isn't a valid json file, so my script simply opens this as a text file, and inserts the new entry at the top.

Add system tests for local user management CRUD operations

ST for #27

Plug state store into ccn_proxy

Plug state store initialization into ccn_proxy. #13 (comment)

Add documentation about how it can be used on an existing application

Looks like it is a proxy for a netmaster only application