Re: How to use extra trusted CA certs when pulling images for a builder

[Joel Pearson]

On Mon, 18 Nov 2019 at 13:05, Clayton Coleman  wrote:

> Raise a bug to the installler component, yes
>

Ok thanks, I raised a bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1773419


> On Nov 17, 2019, at 6:03 PM, Joel Pearson 
> wrote:
>
> On Mon, 18 Nov 2019 at 12:37, Ben Parees  wrote:
>
>>
>>
>> On Sun, Nov 17, 2019 at 7:24 PM Joel Pearson <
>> japear...@agiledigital.com.au> wrote:
>>
>>>
>>>
>>> On Wed, 13 Nov 2019 at 02:43, Ben Parees  wrote:
>>>


 On Mon, Nov 11, 2019 at 11:27 PM Ben Parees  wrote:

>
>
> On Mon, Nov 11, 2019 at 10:47 PM Joel Pearson <
> japear...@agiledigital.com.au> wrote:
>
>>
>>
>> On Tue, 12 Nov 2019 at 06:56, Ben Parees  wrote:
>>
>>>
>>>

 Can I use the “trustedCA” part of the proxy configuration without
 actually specifying an explicit proxy?

>>>
>>> you should be able to.  Daneyon can you confirm?  (if you can't i'd
>>> consider it a bug).
>>>
>>> It does work! Thanks for that. user-ca-bundle already existed and
>> had my certificate in there, I just needed to reference user-ca-bundle in
>> the proxy config.
>>
>
> cool, given that you supplied the CAs during install, and the
> user-ca-bundle CM was created, i'm a little surprised the install didn't
> automatically setup the reference in the proxyconfig resource for you.  
> I'm
> guessing it did not because there was no actual proxy hostname configured.
> I think that's a gap we should close..would you mind filing a bug?  (
> bugzilla.redhat.com).  You can submit it against the install
> component.
>

 fyi I've filed a bug for this aspect of the issues you ran into:
 https://bugzilla.redhat.com/show_bug.cgi?id=1771564


>>> Thanks for raising this, reading through the related github tickets it
>>> looks like I've opened a can of worms to some degree.
>>>
>>
>> Yes there's some difference of opinion on what the out of box desired
>> behavior is, but at a minimum you've exposed a gap in our documentation
>> that we will get fixed.
>>
>>
>> I also just discovered that the openshift cluster version operator (CVO),
> isn't quite configured correctly out of the box to use the correct trusted
> CA certs (which means it can't download cluster updates).
>
> It correctly mounts /etc/ssl/certs from the host (the masters), but it
> fails to also mount /etc/pki, because the certs are a symlink
> /etc/ssl/certs/ca-bundle.crt ->
> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
>
> I couldn't find where the installer sets up the CVO but an example of what
> is missing is here.
>
> https://github.com/openshift/cluster-version-operator/blob/01a7825179246fa708ac64de96e6675c0bf9a930/bootstrap/bootstrap-pod.yaml#L44-L46
>
>
> Is there an existing bug for this? Or should I raise a bugzilla for this?
> Would it be part of the installer?
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

How to recover from failed update in OpenShift 4.2.x?

[Joel Pearson]

So, I'm running OpenShift 4.2 on Azure UPI following this blog article:
https://blog.openshift.com/openshift-4-1-upi-environment-deployment-on-microsoft-azure-cloud/
with
a few customisations on the terraform side.

One of the main differences it seems, is how the router/ingress is handled.
Normal Azure uses load balancers, but UPI Azure uses a regular router (that
I'm used to seeing the 3.x version) which is configured by setting the
"HostNetwork"
for the endpoint publishing strategy


It was all working fine in OpenShift 4.2.0 and 4.2.2, but when I upgraded
to OpenShift 4.2.4, the router stopped listening on ports 80 and 443, I
could see the pod running with "crictl ps", but a "netstat -tpln" didn't
show anything listening.

I tried updating the version back from 4.2.4 to 4.2.2, but I
accidentally used 4.1.22 image digest value, so I quickly reverted back to
4.2.4 once I saw the apiservers coming up as 4.1.22.  I then noticed that
there was a 4.2.7 release on the candidate-4.2 channel, so I switched to
that, and ingress started working properly again.

So my question is, what is the strategy for recovering from a failed
update? Do I need to have etcd backups and then restore the cluster by
restoring etcd? Ie.
https://docs.openshift.com/container-platform/4.2/backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.html

The upgrade page

specifically says "Reverting your cluster to a previous version, or a
rollback, is not supported. Only upgrading to a newer version is
supported." so is it an expectation for a production cluster that you would
restore from backup if the cluster isn't usable?

Maybe the upgrade page should mention taking backups? Especially if there
is no rollback option.
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: connection to CRC from CRS

[Gerard Braad]

Hi,

>> You are however able to login from the console/dashboard?
> The console, for me, isn't at the hostname you mentioned.

The question was about resolving addresses and if the console login works
at all.
As it seems `oc` works when connecting to the API endpoint, right?

> able to login <...> as kubeadmin.

Have you tried using the developer/developer combination?

So far, this does not look like an issue with CRC. Do file an issue at our
repo http://github.com/code-ready/crc/issues
... although this likely seems to be something with the connector.

Also, as it seems to mention CDK/Minishift (which are OpenShift 3.x-based),
I would wonder if the version you use understands OpenShift 4.x-based
clusters. Can you verify this?

regards,


Gerard

On Mon, Nov 18, 2019 at 12:36 PM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Gerard,
>
> The console, for me, isn't at the hostname you mentioned. What you've
> specified is my api server hostname.
>
> [zaphod@oc6010654212 ~]$ oc get route --all-namespaces | grep console
> openshift-console  console
> console-openshift-console.apps-crc.testing   console
>   https  reencrypt/Redirect None
> openshift-console  downloads
> downloads-openshift-console.apps-crc.testing downloads
>   http   edge/Redirect  None
>
> I _am_ able to login at console-openshift-console.apps-crc.testing as
> kubeadmin.
>
> Regards,
> Marvin
>
> On Sun, Nov 17, 2019 at 9:08 PM Gerard Braad  wrote:
>
>> Hi,
>>
>> not sure why this wouldn't work. You are however able to login from the
>> console/dashboard?
>> (To make sure the hostname gets resolved; api.crc.testing)
>>
>> Since CRC is a full OpenShift 4.x installation without specific
>> configuration, it would behave the same as any other OpenShift 4.x install.
>> Have you been able to verify if the connector works with a OpenShift
>> installer deployed cluster, like on AWS or other cloud provider?
>>
>> regards,
>>
>>
>> Gerard
>>
>> On Mon, Nov 18, 2019 at 9:18 AM Just Marvin <
>> marvin.the.cynical.ro...@gmail.com> wrote:
>>
>>> Any takers on this question?
>>>
>>> On Sun, Nov 10, 2019 at 11:52 AM Just Marvin <
>>> marvin.the.cynical.ro...@gmail.com> wrote:
>>>
>>>
>>Gerard Braad | http://gbraad.nl
>>[ Doing Open Source Matters ]
>>
>

-- 

   Gerard Braad | http://gbraad.nl
   [ Doing Open Source Matters ]
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: connection to CRC from CRS

[Just Marvin]

Gerard,

The console, for me, isn't at the hostname you mentioned. What you've
specified is my api server hostname.

[zaphod@oc6010654212 ~]$ oc get route --all-namespaces | grep console
openshift-console  console
console-openshift-console.apps-crc.testing   console
  https  reencrypt/Redirect None
openshift-console  downloads
downloads-openshift-console.apps-crc.testing downloads
  http   edge/Redirect  None

I _am_ able to login at console-openshift-console.apps-crc.testing as
kubeadmin.

Regards,
Marvin

On Sun, Nov 17, 2019 at 9:08 PM Gerard Braad  wrote:

> Hi,
>
> not sure why this wouldn't work. You are however able to login from the
> console/dashboard?
> (To make sure the hostname gets resolved; api.crc.testing)
>
> Since CRC is a full OpenShift 4.x installation without specific
> configuration, it would behave the same as any other OpenShift 4.x install.
> Have you been able to verify if the connector works with a OpenShift
> installer deployed cluster, like on AWS or other cloud provider?
>
> regards,
>
>
> Gerard
>
> On Mon, Nov 18, 2019 at 9:18 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>> Any takers on this question?
>>
>> On Sun, Nov 10, 2019 at 11:52 AM Just Marvin <
>> marvin.the.cynical.ro...@gmail.com> wrote:
>>
>>
>Gerard Braad | http://gbraad.nl
>[ Doing Open Source Matters ]
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: connection to CRC from CRS

[Gerard Braad]

Hi,

not sure why this wouldn't work. You are however able to login from the
console/dashboard?
(To make sure the hostname gets resolved; api.crc.testing)

Since CRC is a full OpenShift 4.x installation without specific
configuration, it would behave the same as any other OpenShift 4.x install.
Have you been able to verify if the connector works with a OpenShift
installer deployed cluster, like on AWS or other cloud provider?

regards,


Gerard

On Mon, Nov 18, 2019 at 9:18 AM Just Marvin <
marvin.the.cynical.ro...@gmail.com> wrote:

> Any takers on this question?
>
> On Sun, Nov 10, 2019 at 11:52 AM Just Marvin <
> marvin.the.cynical.ro...@gmail.com> wrote:
>
>
   Gerard Braad | http://gbraad.nl
   [ Doing Open Source Matters ]
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: How to use extra trusted CA certs when pulling images for a builder

[Clayton Coleman]

Raise a bug to the installler component, yes

On Nov 17, 2019, at 6:03 PM, Joel Pearson 
wrote:

On Mon, 18 Nov 2019 at 12:37, Ben Parees  wrote:

>
>
> On Sun, Nov 17, 2019 at 7:24 PM Joel Pearson <
> japear...@agiledigital.com.au> wrote:
>
>>
>>
>> On Wed, 13 Nov 2019 at 02:43, Ben Parees  wrote:
>>
>>>
>>>
>>> On Mon, Nov 11, 2019 at 11:27 PM Ben Parees  wrote:
>>>


 On Mon, Nov 11, 2019 at 10:47 PM Joel Pearson <
 japear...@agiledigital.com.au> wrote:

>
>
> On Tue, 12 Nov 2019 at 06:56, Ben Parees  wrote:
>
>>
>>
>>>
>>> Can I use the “trustedCA” part of the proxy configuration without
>>> actually specifying an explicit proxy?
>>>
>>
>> you should be able to.  Daneyon can you confirm?  (if you can't i'd
>> consider it a bug).
>>
>> It does work! Thanks for that. user-ca-bundle already existed and had
> my certificate in there, I just needed to reference user-ca-bundle in the
> proxy config.
>

 cool, given that you supplied the CAs during install, and the
 user-ca-bundle CM was created, i'm a little surprised the install didn't
 automatically setup the reference in the proxyconfig resource for you.  I'm
 guessing it did not because there was no actual proxy hostname configured.
 I think that's a gap we should close..would you mind filing a bug?  (
 bugzilla.redhat.com).  You can submit it against the install component.

>>>
>>> fyi I've filed a bug for this aspect of the issues you ran into:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1771564
>>>
>>>
>> Thanks for raising this, reading through the related github tickets it
>> looks like I've opened a can of worms to some degree.
>>
>
> Yes there's some difference of opinion on what the out of box desired
> behavior is, but at a minimum you've exposed a gap in our documentation
> that we will get fixed.
>
>
> I also just discovered that the openshift cluster version operator (CVO),
isn't quite configured correctly out of the box to use the correct trusted
CA certs (which means it can't download cluster updates).

It correctly mounts /etc/ssl/certs from the host (the masters), but it
fails to also mount /etc/pki, because the certs are a symlink
/etc/ssl/certs/ca-bundle.crt ->
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

I couldn't find where the installer sets up the CVO but an example of what
is missing is here.
https://github.com/openshift/cluster-version-operator/blob/01a7825179246fa708ac64de96e6675c0bf9a930/bootstrap/bootstrap-pod.yaml#L44-L46


Is there an existing bug for this? Or should I raise a bugzilla for this?
Would it be part of the installer?

___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: How to use extra trusted CA certs when pulling images for a builder

[Joel Pearson]

On Mon, 18 Nov 2019 at 12:37, Ben Parees  wrote:

>
>
> On Sun, Nov 17, 2019 at 7:24 PM Joel Pearson <
> japear...@agiledigital.com.au> wrote:
>
>>
>>
>> On Wed, 13 Nov 2019 at 02:43, Ben Parees  wrote:
>>
>>>
>>>
>>> On Mon, Nov 11, 2019 at 11:27 PM Ben Parees  wrote:
>>>


 On Mon, Nov 11, 2019 at 10:47 PM Joel Pearson <
 japear...@agiledigital.com.au> wrote:

>
>
> On Tue, 12 Nov 2019 at 06:56, Ben Parees  wrote:
>
>>
>>
>>>
>>> Can I use the “trustedCA” part of the proxy configuration without
>>> actually specifying an explicit proxy?
>>>
>>
>> you should be able to.  Daneyon can you confirm?  (if you can't i'd
>> consider it a bug).
>>
>> It does work! Thanks for that. user-ca-bundle already existed and had
> my certificate in there, I just needed to reference user-ca-bundle in the
> proxy config.
>

 cool, given that you supplied the CAs during install, and the
 user-ca-bundle CM was created, i'm a little surprised the install didn't
 automatically setup the reference in the proxyconfig resource for you.  I'm
 guessing it did not because there was no actual proxy hostname configured.
 I think that's a gap we should close..would you mind filing a bug?  (
 bugzilla.redhat.com).  You can submit it against the install component.

>>>
>>> fyi I've filed a bug for this aspect of the issues you ran into:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1771564
>>>
>>>
>> Thanks for raising this, reading through the related github tickets it
>> looks like I've opened a can of worms to some degree.
>>
>
> Yes there's some difference of opinion on what the out of box desired
> behavior is, but at a minimum you've exposed a gap in our documentation
> that we will get fixed.
>
>
> I also just discovered that the openshift cluster version operator (CVO),
isn't quite configured correctly out of the box to use the correct trusted
CA certs (which means it can't download cluster updates).

It correctly mounts /etc/ssl/certs from the host (the masters), but it
fails to also mount /etc/pki, because the certs are a symlink
/etc/ssl/certs/ca-bundle.crt ->
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

I couldn't find where the installer sets up the CVO but an example of what
is missing is here.
https://github.com/openshift/cluster-version-operator/blob/01a7825179246fa708ac64de96e6675c0bf9a930/bootstrap/bootstrap-pod.yaml#L44-L46


Is there an existing bug for this? Or should I raise a bugzilla for this?
Would it be part of the installer?
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: How to use extra trusted CA certs when pulling images for a builder

[Ben Parees]

On Sun, Nov 17, 2019 at 7:24 PM Joel Pearson 
wrote:

>
>
> On Wed, 13 Nov 2019 at 02:43, Ben Parees  wrote:
>
>>
>>
>> On Mon, Nov 11, 2019 at 11:27 PM Ben Parees  wrote:
>>
>>>
>>>
>>> On Mon, Nov 11, 2019 at 10:47 PM Joel Pearson <
>>> japear...@agiledigital.com.au> wrote:
>>>


 On Tue, 12 Nov 2019 at 06:56, Ben Parees  wrote:

>
>
>>
>> Can I use the “trustedCA” part of the proxy configuration without
>> actually specifying an explicit proxy?
>>
>
> you should be able to.  Daneyon can you confirm?  (if you can't i'd
> consider it a bug).
>
> It does work! Thanks for that. user-ca-bundle already existed and had
 my certificate in there, I just needed to reference user-ca-bundle in the
 proxy config.

>>>
>>> cool, given that you supplied the CAs during install, and the
>>> user-ca-bundle CM was created, i'm a little surprised the install didn't
>>> automatically setup the reference in the proxyconfig resource for you.  I'm
>>> guessing it did not because there was no actual proxy hostname configured.
>>> I think that's a gap we should close..would you mind filing a bug?  (
>>> bugzilla.redhat.com).  You can submit it against the install component.
>>>
>>
>> fyi I've filed a bug for this aspect of the issues you ran into:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1771564
>>
>>
> Thanks for raising this, reading through the related github tickets it
> looks like I've opened a can of worms to some degree.
>

Yes there's some difference of opinion on what the out of box desired
behavior is, but at a minimum you've exposed a gap in our documentation
that we will get fixed.



-- 
Ben Parees | OpenShift
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

external ips - seems like handwaving in docs

[Just Marvin]

Hi,


https://docs.openshift.com/container-platform/4.2/networking/configuring-ingress-cluster-traffic/configuring-ingress-cluster-traffic-service-external-ip.html#nw-creating-project-and-service_configuring-ingress-cluster-traffic-service-external-ip
 .

Step 4 seems like magic. When I do that on my local CRC install, I get
this:

[zaphod@oc6010654212 Downloads]$ oc get svc -n openshift-ingress
NAME  TYPECLUSTER-IP   EXTERNAL-IP
PORT(S)   AGE
router-internal-default   ClusterIP   172.30.165.244   
 80/TCP,443/TCP,1936/TCP   18d
[zaphod@oc6010654212 Downloads]$

Which is what I would have expected to see. Where is that
"router-default" entry coming from? I've added an external ip to the crc
device, so I think I've met the pre-requisites. Whats the step that I'm
missing?

Regards,
Marvin
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: sftp service on cluster - how to do it

[Just Marvin]

Tobias,

I _will_ have access to load balancers if needed, but at the moment, I
need to understand how it works. Assume that I do: what exactly does "proxy
to the internal sftp service" mean? I assume "sftp service" would be the
service that I set up, but which piece is the proxy? I don't see that load
balancer and proxy functions as being the same, so it seems like you are
talking about a third piece. What piece is that?

Regards,
Marvin

On Sun, Nov 17, 2019 at 1:30 PM Tobias Florek  wrote:

> Hi!
>
> I assume you don't have easy access to load balancers, because that
> would be easiest.  Just proxy to the internal sftp service.
>
> If you don't I have used Nodeport service in the past.  You will lose
> the nice port 22 though.  If you control the node's ssh daemon, you can
> also use ProxyJumps.  Be sure to lock down ssh for the users though.
>
> Cheers,
>  Tobias Florek
>
> ___
> users mailing list
> users@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: How to use extra trusted CA certs when pulling images for a builder

[Joel Pearson]

On Wed, 13 Nov 2019 at 01:34, Ben Parees  wrote:

>
>
> On Tue, Nov 12, 2019 at 3:45 AM Joel Pearson <
> japear...@agiledigital.com.au> wrote:
>
>>
>>
>> On Tue, 12 Nov 2019 at 15:37, Ben Parees  wrote:
>>
>>>
>>>
>>> On Mon, Nov 11, 2019 at 11:26 PM Joel Pearson <
>>> japear...@agiledigital.com.au> wrote:
>>>
 I've now discovered that the cluster-samples-operator doesn't seem
 honour the proxy settings, and I see lots of errors in the
 cluster-samples-operator- pod logs

 time="2019-11-12T04:15:49Z" level=warning msg="Image import for
 imagestream dotnet tag 2.1 generation 2 failed with detailed message
 Internal error occurred: Get https://I /v2/
 : x509: certificate signed by unknown
 authority"

 Is there a way to get that operator to use the same user-ca-bundle?

>>>
>>> image import should be using those CAs (it's really about the
>>> openshift-apiserver, not the samples operator) automatically (sounds like
>>> another potential bug, but i'll let Oleg weigh in on this one).
>>>
>>> However barring that, you can use the mechanism described here to
>>> setup additional CAs for importing from registries:
>>>
>>> https://docs.openshift.com/container-platform/4.2/openshift_images/image-configuration.html#images-configuration-file_image-configuration
>>>
>>> you can follow the more detailed instructions here:
>>>
>>> https://docs.openshift.com/container-platform/4.2/builds/setting-up-trusted-ca.html#configmap-adding-ca_setting-up-trusted-ca
>>>
>>
>> I tried this approach but it didn't work for me.
>>
>> I ran this command:
>>
>> oc create configmap registry-cas -n openshift-config \
>> --from-file=registry.redhat.io..5000=/path/to/ca.crt \
>> --from-file=registry.redhat.io..443=/path/to/ca.crt \
>> --from-file=registry.redhat.io=/path/to/ca.crt
>>
>> and:
>>
>> oc patch image.config.openshift.io/cluster --patch
>> '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge
>>
>> And that still didn't work. First I deleted the
>> cluster-samples-operator- pod, then I tried forcing the masters to
>> restart by touching some machine config (I don't know a better way).
>> But it still didn't work.  Maybe the samples operator doesn't let you
>> easily override the trusted CA certs?
>>
>
> Because no good bug report should not be rewarded with some educational
> background:
>
> The samples operator is only responsible for creating the imagestream, it
> isn't actually doing the import (ie reaching out to the registry and
> pulling down the metadata and putting it in the imagestream).  That task is
> performed by the openshift-apiserver.  What should be happening when you
> update the image config resource with the name of the CA configmap is that
> the openshift-apiserver operator should observe the configuration change
> and provide the new CAs to the openshift-apiserver pods (which necessitates
> a restart of the openshift-apiserver pods).
>
> Once the openshift-apiserver pods are restarted with the new CAs, you
> should be able to run "oc import-image" to retry the import.  (The samples
> operator is supposed to retry the failed imports periodically, but there is
> a different bug that is being fixed related to that, so until then you'll
> have to retry the import manually once you've corrected whatever caused the
> failure).
>
> So again, there may be a bug here in terms of the openshift-apiserver
> picking up the CAs and we need to investigate it (as well as a separate bug
> if it is not picking up the proxy CAs), but I wanted you to understand the
> relevant components so your own debugging process can be more productive.
>
>
Thanks for the explanation Ben, it helped me figure out there the issues
where.

For other reasons (I had tried to customise name of the Azure
resource group and something would occasionally (once a day?) change it
back to the default name), I ended up burning the cluster to the ground,
and I configured the "spec.trustedCA.name" reference during installation by
customising the manifest files generated by "openshift-install create
manifests --dir=ignition-files" and then the samples operators worked out
of the box!

So it was just that the samples operator doesn't retry as you mentioned.

Also, I didn't need to setup the additional CAs for importing from
registries in the end.
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: sftp service on cluster - how to do it

[Tobias Florek]

Hi!

I assume you don't have easy access to load balancers, because that
would be easiest.  Just proxy to the internal sftp service.

If you don't I have used Nodeport service in the past.  You will lose
the nice port 22 though.  If you control the node's ssh daemon, you can
also use ProxyJumps.  Be sure to lock down ssh for the users though.

Cheers,
 Tobias Florek

___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users