store untrusted certificate setting for CLI in wskprops

[rabbah]

To use wsk with a local deployment that does not have a properly signed certificate requires using -i on every command. So one workaround is to alias wsk to wsk -i. This setting however should be stored in the wskrpops file so that one can use multiple files and not give up SSL sanity when using a deployment with a valid SSL.

[rabbah]

@csantanapr this is the issue for the pr #1838 - let's have the discussion here instead of the pr?

[csantanapr]

@csantanapr this is the issue for the pr #1838 - let's have the discussion here instead of the pr?

Sure

How is the PR #1838 addressing the problem, and handling concerns with user forgetting if it modifies the ~/.wskprops file to set insecure, and the exposure risk?

[rabbah]

We currently provide a global -i flag for the CLI. We use this flag for all tests and local development because we don't have a trusted certificate installed for local deployment. We can entertain this idea with letsencrypt but I'm not sure it's worth the effort (plus they require renewal every 90 days, so more processes).

So that means for local development either every CLI command you enter must have -i or you have to create an alias wsk=wsk -i.

What the PR does is allow up to configure the CLI and store the setting in .wskprops.

Your concern is that one might use the insecure ssl setting with a trusted domain and that's undesirable. But it's no worse that the alias.

This is primarily for local developers and those who have more than one deployment that they work with. I tend to switch between deployments via WSK_CONFIG_FILE changes which point to different .wskprops. So each would have it's own setting, including insecure ssl (which is off by default).

So what to do about the case where someone sets -i in their property file and forgets and now is using the same property file with a trusted domain? Generating a warning on every CLI command is a non-starter. So if we wanted to be cautious about it, one thought is for the CLI to issue a warning when changing apihost or authkey. I tend to think it's not necessary - as I said this is for local development - and you have to opt into it.

[csantanapr]

why not entertain something with less effort and just expose http on port 80 in open for local dev from nginx?

Would look something like

wsk property set --apihost http://192.168.33.13

The cli will connect over http for dev Then if user wants to use a secure apihost then setting api host with https

wsk property set --apihost https://openwhisk.ng.bluemix.net

In this use case no -i flag to use, no config file to configure.

[csantanapr]

This matches what I'm use to, do when dealing with local web servers and doing dev and local testing. I access the web server on http://localhost:8080 and when access in a secure way when I have my nginx/proxy in front I access using https://carlos.example.com

[rabbah]

why not entertain something with less effort and just expose http on port 80 in open for local dev from nginx?

OK good thought - although by extension the tests in the repo should be using http vs -i (and why do we include self-signed certificates)... but then again this is not fully tested either (although I did add a test to make sure the CLI will allow an http api host)... and then why bother allowing -i at all?

[csantanapr]

OK good thought - although by extension the tests in the repo should be doing this vs -i but then again this is not fully tested either (although I did add a test to make sure the CLI will allow http).

Agree tests using the cli will need adjusting to not use -i anymore, and have tests for the CLI in place that allow for user to configure apihost using protocol http or https or just domain.

I prefer to see effort invested to this solution than a config file insecure option, if I were given the chance to give my 2 cents.

[rabbah]

I think you're asking for a bigger boat - If we add http to the router, then I think all tests will need to run twice: against http and https. No? (This was the reason we settled on https.) Perhaps it's worth revisiting this again.

Note: this could solve some of the problem we have in the catalog where actions that need to use npm openwhisk have to accommodate secure and insecure connections. Going to http in addition to https would get rid of that ugliness.

[csantanapr]

I think the tests should not be run twice. Maybe run all of them with http, and then run one or two tests over https, I think is low risk.

If the tests are to be run let's say in an environment where secure option is available, I would run all tests using https, for example running tests against a staging or production env, or just a VM user setup with proper ssl certificates.

[rabbah]

I think the tests should not be run twice.

Not convinced this flies - how will you know there isn't some protocol hardcoded somewhere and hence will break if you don't test both paths?

We'll have to encode the protocol in ansible for the api host, allow for either deployment, configure the tests accordingly (CLI and REST tests), update all the documentation for each protocol.

[rabbah]

Should we reopen https://github.com/openwhisk/openwhisk/issues/428? It seems the issues you're raising are bigger. This issue and corresponding PR was in response to this https://github.com/openwhisk/openwhisk/issues/428#issuecomment-229201967.

[csantanapr]

Sure re-open #428 it or open a new one.

So back to this issue #1570 and the PR #1838 I have no more to comment.

[markusthoemmes]

FWIW I use multiple aliases locally to overcome this issue:

owsk='WSK_CONFIG_FILE=~/.wskprops-local ~/dev/openwhisk/bin/wsk -i'
pwsk='WSK_CONFIG_FILE=~/.wskprops-prod ~/dev/openwhisk/bin/wsk'
swsk='WSK_CONFIG_FILE=~/.wskprops-stage ~/dev/openwhisk/bin/wsk'
wsk='~/dev/openwhisk/bin/wsk'

Just to throw another datapoint in the ring.

[rabbah]

A reason not to use different aliases and why it breaks down: if you're working with deployment scripts with others, who use wsk, then it breaks. Every app deployment scripts that I've had to work with from others did this, and I've had to change their scripts to use $WSK where I can override it from the command line for example. So I've opted for always using wsk for convenience and just toggling the WSK_CONFIG_FILE through a similar mechanism.

Usually others are working against a production environment (Bluemix) but I'm using a private deployment. Hence the need for a way to change settings.

[rabbah]

since i closed the pr to store this setting, i'm also closing the issue as wont fix. there's a documented workaround for "local" deployments in https://github.com/openwhisk/openwhisk/pull/1989 for Vagrant and will add additional documentation as part of #1908.