简体   繁体   English

如何在Redhat-SSO映像中为OpenShift启用相互SSL验证模式

[英]How to enable mutual SSL verification mode in Redhat-SSO image for OpenShift

I am using the template sso72-x509-postgresql-persistent, which is based on Redhat-SSO and Keycloak, to create an application in OpenShift. 我使用的模板sso72-x509-postgresql-persistent(基于Redhat-SSO和Keycloak)在OpenShift中创建应用程序。

I am going to enable its mutual SSL mode, so that a user has to only provide his certificate instead of user name and password in his request. 我将启用其双向SSL模式,以便用户仅在请求中提供其证书,而不是用户名和密码。 The document ( https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/html-single/server_administration_guide/index#x509 ) told me to edit the standalone.xml file to add configuration sections. 该文档( https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/html-single/server_administration_guide/index#x509 )告诉我编辑standalone.xml文件以添加配置部分。 It worked fine. 工作正常。

But the template image sso72-x509-postgresql-persistent had problem with this procedure, because after it was deployed on the OpenShift, any changes on the files within the docker have been lost after restart of the docker. 但是模板映像sso72-x509-postgresql-persistent在此过程中遇到了问题,因为在将其部署到OpenShift上之后,重新启动docker后,丢失了docker内部文件的所有更改。

Is there anyway to enable the mutual SSL mode through another level matter like commandline or API instead of editting a configuration file, except making my own docker image? 无论如何,除了制作自己的docker映像外,是否可以通过命令行或API等其他级别来启用相互SSL模式,而不是编辑配置文件?

Ok, I'm including this anyway. 好吧,我还是要包括这个。 I wasn't able to get this working due to permissions issues (the mounted files didn't persist the same permissions as before, so the container continued to fail. But a lot of work went into this answer, so hopefully it points you in the right direction! 由于权限问题,我无法正常工作(挂载的文件未保留以前的权限,因此容器继续失败。但是,此答案做了很多工作,因此希望可以为您指明方向正确的方向!


You can add a Persistent Volume (PV) to ensure your configuration changes survive a restart. 您可以添加一个持久卷(PV),以确保您的配置更改在重启后仍然有效。 You can add a PV to your deployment via: 您可以通过以下方式将PV添加到部署中:

DON'T DO THIS 不要这样做

oc set volume deploymentconfig sso --add -t pvc --name=sso-config --mount-path=/opt/eap/standalone/configuration --claim-mode=ReadWriteOnce --claim-size=1Gi

This will bring up your RH-SSO image with a blank configuration directory, causing the pod to get stuck in Back-off restarting failed container . 这将使您的RH-SSO映像带有空白的configuration目录,从而导致Pod卡在Back-off restarting failed container What you should do instead is: 相反,您应该做的是:

  1. Backup the existing configuration files 备份现有配置文件

     oc rsync <rhsso_pod_name>:/opt/eap/standalone/configuration ~/ 
  2. Create a temporary, busybox deployment that can act as an intermediary for uploading the configuration files. 创建一个临时的busybox部署,该部署可以充当上载配置文件的中介。 Wait for deployment to complete 等待部署完成

     oc run busybox --image=busybox --wait --command -- /bin/sh -c "while true; do sleep 10; done" 
  3. Mount a new PV to the busybox deployment. 将新的PV挂载到busybox部署。 Wait for deployment to complete 等待部署完成

     oc set volume deploymentconfig busybox --add -t pvc --name=sso-volume --claim-name=sso-config --mount-path=/configuration --claim-mode=ReadWriteOnce --claim-size=1Gi 
  4. Edit your configuration files now 立即编辑您的配置文件

  5. Upload the configuration files to your new PV via the busybox pod 通过busybox窗格将配置文件上传到新的PV

     oc rsync ~/configuration/ <busybox_pod_name>:/configuration/ 
  6. Destroy the busybox deployment 销毁busybox部署

     oc delete all -l run=busybox --force --grace-period=0 
  7. Finally , you attach your already created and ready-to-go persistent configuration to the RH SSO deployment 最后 ,将已经创建的随时可用的持久配置附加到RH SSO部署中

     oc set volume deploymentconfig sso --add -t pvc --name=sso-volume --claim-name=sso-config --mount-path=/opt/eap/standalone/configuration 

Once your new deployment is...still failing because of permission issues :/ 一旦您的新部署...由于权限问题仍然失败:/

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM