Как использовать секреты Openshift для установления клиентского соединения MQ через SSL

Я пытаюсь объединить предложения по использованию SSL с openshift: https://blog.openshift.com/openshift-demo-part-13-using-ssl/

с тем, как использовать ssl с mq:

Конфигурация Spring для JMS (Websphere MQ - SSL, Tomcat, JNDI, не IBM JRE)

Таким образом, мне удалось изменить мое приложение Spring Boot Camel, чтобы перейти от подключения через канал svrconn mq без SSL к каналу, который использует SSL, добавив свойство SSLCipherSuite в bean-компонент com.ibm.mq.jms.MQConnectionFactory и добавив эти аргументы виртуальной машины в Run Конфигурация (как описано во втором связанном документе):

-Djavax.net.ssl.trustStore=C:\path-to-keystore\key.jks
-Djavax.net.ssl.trustStorePassword=topsecret
-Djavax.net.ssl.keyStore=C:\path-to-keystore\key.jks
-Djavax.net.ssl.keyStorePassword=topsecret
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false

И он отлично работает локально на встроенном сервере Tomcat, однако мне нужно было бы развернуть его в Openshift, поэтому моим первым импульсом было добавить те же аргументы виртуальной машины к тем, которые я использую для развертывания Openshift, а именно:

-Dkubernetes.master=
-Dkubernetes.namespace=
-Dkubernetes.auth.basic.username=
-Dkubernetes.auth.basic.password=
-Dkubernetes.trust.certificates=
-Dfabric8.mode=openshift

но это явно не работает, например, потому что у меня нет того же пути к хранилищу ключей. Поэтому я немного исследовал это и узнал, что мне нужно использовать секреты, которые можно определить с помощью команды CLI >> oc secrets new ‹< или через консоль Openshift, но я не понимаю, как именно действовать. Нужно ли мне добавлять параметры к образу или переменные среды в конфигурацию развертывания или что-то еще? Каким-то образом он должен ссылаться на определенные секреты, и он должен быть назван, изменяя каждую точку с подчеркиванием в его имени? Так, например, если я выдаю:

oc secrets new my-key-jks key.jks

тогда мне нужно >> Добавить значение из карты конфигурации или секрета

JAVAX_NET_SSL_TRUSTSTORE мой-ключ-jks key.jks

и добавить значение:

COM_IBM_MQ_CFG_USEIBMCIPHERMAPPINGS ложь ??

Я пробовал это, но это не работает, я добавил значения в deployconfigs, чтобы получить такую ​​выдержку:

        "spec": {
            "containers": [
                {
                    "env": [
                        {
                            "name": "KUBERNETES_NAMESPACE",
                            "valueFrom": {
                                "fieldRef": {
                                    "apiVersion": "v1",
                                    "fieldPath": "metadata.namespace"
                                }
                            }
                        },
                        {
                            "name": "JAVAX_NET_SSL_TRUSTSTORE",
                            "valueFrom": {
                                "secretKeyRef": {
                                    "key": "key.jks",
                                    "name": "my-key-jks"
                                }
                            }
                        },

когда я делаю:

  oc get dc app_name -o json

Я также создал sa (serviceaccount) и назначил его администратором проекта и поручил ему использовать только что созданный секрет, я сделал это через консоль Openshift, так что сейчас у меня нет кода oc CLI. Это тоже в некоторой степени актуально (но мне это не сильно помогает):

https://github.com/openshift/openshift-docs/issues/699

После сборки статус модуля становится >> Отключение цикла сбоя ‹<, и >> Журналы больше не доступны или не могут быть загружены. ‹************************************************************


person hdjur_jcv    schedule 21.06.2018    source источник


Ответы (1)


ИМХО вы неправильно интерпретируете некоторые из указанных здесь настроек.

1.

Аргументы виртуальной машины после "-Dkubernetes.master =", которые вы указываете здесь, я полагаю, предназначены для передачи плагину maven fabric8, который вы используете для развертывания. Правильно?

Параметры, касающиеся аутентификации / сертификатов здесь, предназначены ТОЛЬКО для связи с кубернетами и НЕ предназначены для предоставления данных хранилища ключей вашему приложению для использования. Так что я думаю, что они не связаны.

Вместо этого вам нужно убедиться, что внутри вашего контейнера ваше приложение запускается с теми же параметрами, которые вы используете для локального выполнения. Конечно, тогда вам придется изменить значения параметров так, чтобы соответствующие данные были доступны внутри вашего контейнера.

2.

Секреты - это инструмент для добавления в ваше развертывание конфиденциальных данных, которые вы не хотите включать в образ вашего приложения. Так, например, ваши хранилища ключей и пароли хранилищ ключей могут быть введены с помощью секрета.

Альтернативой предоставлению секретных данных в качестве переменной среды, как вы пытались, является просто монтирование их в файловую систему, которая делает секретные данные доступными в виде файлов. Поскольку вашему приложению нужен JKS в виде файла, вы можете сделать следующее.

  1. В веб-консоли вашего развертывания воспользуйтесь ссылкой «Добавить файлы конфигурации» в разделе «Тома».

  2. Выберите созданный ранее секрет my-key-jks в качестве источника.

  3. Укажите путь, по которому секрет должен быть смонтирован внутри вашего контейнера, например «/ secret». Затем нажмите «Добавить».

  4. После этого ваши jks будут доступны внутри вашего контейнера по пути "/secret/key.jks", чтобы ваш параметр приложения мог указывать на этот путь.

person Oliver Weise    schedule 25.06.2018
comment
Что касается 1., я согласен со всеми тремя версиями, и я думаю, что уже намекнул на этот факт, так что не было неправильного толкования, о котором я еще не знал. Однако, что касается 2., я могу только поблагодарить вас за предложение смонтировать данные секретов в файловую систему, что я сделал в конфигурации развертывания, и он отлично работает, что было полезно. - person hdjur_jcv; 02.07.2018