Using Rancher Authentication as a openvpn backend

Rancher 1.x
1

Hello Rancheros,

I was trying to setup the catalog entry “openvpn HTTP Basic” and i was wondering if there is any way to use rancher authentication mechanism to authentify against ?

Using the api we were able to authenticate in a given environment using APIs keys, but this is not very handy and i would like to recycle the usernames and password used in rancher. Thus, if you give a user access to the rancher UI, you give it access to the internal VPN. That makes sense (at least for my needs).

If possible then what happen if you have setup a github authentication ? an ldap authentication ?

Cheers
Frederic

2

I’ve submitted a pull request that enables this feature against a Rancher server running in local user mode.

3

Hi Scott,

Thanxs for that. We also discussed it with Alexis (who commited the openvpn catalog entry) and we agreed it could be a nice feature.

Will definitly try it out.

Cheers

4

If you just want to check it out before it is merged you can install an openvpn-httpbasic stack then upgrade using the gui and change to docker hub image missionmode/rancher-openvpn:latest and change the AUTH_METHOD variable:

AUTH_RANCHERLOCAL_URL: https://rancher.example.com/v1/token
AUTH_METHOD: rancherlocal

I also found that adding:

OPENVPN_EXTRACONF: push "route 10.x.0.0 255.255.0.0"

To the environment causes the extra route to get added (the 10.x.0.0 would be from the AWS vpc or something)

5

Hi there !

Thanks to sra, and as asked by webofmars, i pushed a new catalog entry in community catalog : openvpn-rancherlocal (OpenVPN Rancher)

Let me know if you encounter some problems.

Cheers

6

It looks like this is only authenticating that you have an account, not that your account is a member of the particular Environment (project in the API) that the VPN stack is running in.

7

Yes ! It would be nice indeed to have the choice of restricting users that have an access to current env (and why not with a minimal role like user/operator/owner …)

I’ll check it out asap.

Thanks !

8

Hi,

Thanxs all for the work. The restriction feature could be very interresting indeed but for our needs the 1st step is already a big one.

Another idea could be to check if it’s possible to leverage on rancher SSO with github or Active Directory (but if you go AD you already have another backend so maybe not usefull).

I will try to look through the code for that point.

Cheers
frederic @ webofmars

9

Oh, yes. I didn’t even think about that :smiley:

@AlexisDucastel, if you push a new version for the catalog, could you make the text hint for the URL have the /v1/token postfix? Right now if someone uses that catalog entry they will likely leave that part off.

Even better, I suppose making the localrancher function in the python code deal with either case would be even better user experience. If you think so, I can add that bit. Let me know.

10

@sra , in fact, the hint doesn’t expose the /v1/token postfix because i’ve written it the hard way in the docker-compose.yml (docker-compose on github at line 15)

It would be great to get the ability to choose a right level for accessing vpn, like :

  • account = user must have a valid account in Rancher API
  • readonly = user must have a valid account and a role “readonly” or greater in current VPN environment
  • restricted =user must have a valid account and a role “restricted” or greater in current VPN environment
  • member = user must have a valid account and a role “member” or greater in current VPN environment
  • owner = user must have a valid account and a role “owner” in current VPN environment

Does it make sense ?

Furthermode, @vincent is there a way to discover current VPN environment identifier via metadata api ? (169.254.169.250)
And finally, is there a way to hit the rancher api through the rancher managed network (like metadata api), in order to remove the need to declare rancher api URL ?

Yes, I know, it’s a lot of questions in one post !! sorry about that :wink:

11

Oh! Clever. I didn’t notice that the URL was completed in the compose file - that is a better way of doing it.

I think that the different types of account could be done fairly easily - the return value of the POST to /v1/token has a JSON object that has a bunch of information about the account. This stuff might have what is needed. I only have access to a localauthconfig version of rancher, but you can check it out with your own.

curl -XPOST -d authProvider=localauthconfig -d code=user:pw https://rancher.example.com/v1/token | json_pp

I think providing the functionality other than “account” will require further API requests against the server. You can get the environment key via

curl rancher-metadata/latest/self/stack/environment_uuid

I looked through the metadata available using curl rancher-metadata/latest and there isn’t any entry that shows the URL of the server that is managing it.

12

If you add this to the service:

labels:
  io.rancher.container.create_agent: true
  io.rancher.container.agent.role: environment

Then you will get CATTLE_URL, CATTLE_ACCESS_KEY, and CATTLE_SECRET_KEY environment variables inside the container(s) which you can use to hit the API (as the environment you are running in, and with access to only it) to make any calls you want.

1 Like
13

@vincent Awesome !! That removes a configuration process ! Thanks for the hint !