[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OpenShift v3 now running in HTTPS mode by default



As of https://github.com/openshift/origin/pull/734 there are some new options to "openshift start" for dealing with internal/external IP situations (as well as several others that may come up). This involves explicitly specifying how to reach the various components at a "public" address (where "public" is relative but in general is intended to imply "actual users outside the cloud infrastructure"), separately from the question of where the services should bind internally (generally the default 0.0.0.0 will be fine, though possibly with varying ports). Public addresses default to private binding address, so if there is no distinction in your infrastructure, you should be able to ignore the public address options.

Given it's entirely possible for ports to be blocked from the public that are bound privately, be conscious of how components must refer to each other:

etcd: masters runs built-in instance or it may be run separately. Only master/kubernetes ever consult this, should be at a private address (which is default).
master: console and clients consult this, needs a public address via --public-master
kubernetes: master, clients, and console consult this, needs a public address via --public-kubernetes (defaults to same as --public-master)

console (AKA asset server): While in many ways this is the simplest service (just a bunch of static files served to your browser), in terms of connections to other components it's the most complex. The browser loads it, and OAuth server must redirect to it once authentication is complete. The JavaScript running in the browser needs to know where to self-refer (for passage through OAuth) and where to refer to master and kubernetes. This is all from the perspective of the browser, so all must be public addresses. The asset server public address currently uses the --public-master address but with the port one higher than the master. Addresses from --public-master and --public-kubernetes are included in allowed CORS origins (JSON is considered JS code and will be blocked if not explicitly allowed).

Public addresses are also now included in the certs generated by "openshift start [master]" so that console and clients can accept them. We will at some point need a "--keep-certs" option (or perhaps this becomes the default and the option is --overwrite-certs) so that administrators can supply their own appropriately customized master and client certificates.

For accessing an EC2 OpenShift v3 all-in-one host (where exotic ports like 8443 are blocked to the public), I now use parameters like this:

# openshift start --listen=https://0.0.0.0:443/ --public-master=https://<external_ip>/

... and then port forward port 444 to localhost

$ vagrant ssh -- -L 8444:localhost:444

... so I can reach the asset server at https://localhost:8444/. To be honest, I don't know enough about our OAuth to try that out; my guess would be this scheme doesn't work with that and at some point we'll need to think about an explicit option for specifying the asset server public address and/or putting it behind a proxy.

----- Original Message -----
From: "Luke Meyer" <lmeyer redhat com>
To: "Cesar Wong" <cewong redhat com>
Cc: "[PUBLIC] Openshift Dev" <dev lists openshift redhat com>
Sent: Friday, January 23, 2015 9:29:30 AM
Subject: Re: OpenShift v3 now running in HTTPS mode by default

There's no really good way for the on-host binary to determine what that will be without an explicit flag. I'm working on a flag to specify an arbitrary external address for clients and have it included in the cert.

----- Original Message -----
From: "Cesar Wong" <cewong redhat com>
To: "Jordan Liggitt" <jliggitt redhat com>
Cc: "[PUBLIC] Openshift Dev" <dev lists openshift redhat com>
Sent: Thursday, January 22, 2015 1:34:21 PM
Subject: Re: OpenShift v3 now running in HTTPS mode by default



When running openshift in a container with boot2docker on my mac (I use my own .kubecfg that points to where the certificates are) 
I get the following: 



$ osc get pods 
F0122 13:28:05.490333 67856 get.go:151] Get https://192.168.59.103:8443/api/v1beta1/pods?namespace=default: x509: certificate is valid for 10.0.2.15, 127.0.0.1, 172.17.42.1, not 192.168.59.103 


Seems that the master is not picking up the boot2docker external ip for the list of valid certificate hosts. Is there a way to tell it which hosts are valid? 




On Jan 22, 2015, at 11:25 AM, Jordan Liggitt < jliggitt redhat com > wrote: 



On 01/22/2015 09:31 AM, Clayton Coleman wrote: 



We should probably default the protocol on master to listen. The original goal was for people not to specify master - instead, to give just enough info to make the right decisions. I've noticed people starting to hardcode those, but we should make the function more intuitive. 


--listen= http://:0.0.0.0:8080 should be all most people need 


That'll be done in https://github.com/openshift/origin/pull/715 

Setting --listen will affect the default scheme and port for --master 

_______________________________________________ 
dev mailing list 
dev lists openshift redhat com 
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev 


_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]