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

Specifying public addresses on openshift start [was: Re: OpenShift v3 now running in HTTPS mode by default]



It occurred to me I might want to break this out from the original thread.

Also, one small fix to what I said below:

----- Original Message -----
> From: "Luke Meyer" <lmeyer redhat com>
> Sent: Monday, January 26, 2015 10:16:07 AM
> Subject: 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>/

You have to be explicit about the external port if you don't want it to be 8443. So:

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


> 
> ... 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
> 
> _______________________________________________
> 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]