zowe / zowe-install-packaging

Packaging repository for the Zowe install scripts and files
Eclipse Public License 2.0
26 stars 52 forks source link

Use existing keyrings during setup #3877

Open 1000TurquoisePogs opened 6 days ago

1000TurquoisePogs commented 6 days ago

Many users do not want Zowe to create a keyring. They just want to use their own keyring. This is possible and the requirements are documented at https://docs.zowe.org/stable/user-guide/configure-certificates#zowe-certificate-requirements but zowe does not provide clear documentation or intuition on how to make use of such keyrings.

Proposal 1:

Change example-zowe.yaml to add a 6th "certificate setup scenario"

It should look like this:

zowe:
  setup:
    certificate:
      type: JCERACFKS
      keyring:
        name: ZoweKeyring
        label: localhost
        create: false

This yaml is similar to the 3rd scenario (create keyring & certificate), but create: false will be used to tell it not to create.

The result of this config should be that no JCL is executed, no system change occurs. At maximum, validation could be performed to see if the keyring chosen is actually valid for zowe use.

But the point of this yaml would be that upon running zwe init certificate, the only thing it would do is convert from the setup.certificate structure to the certificate structure.

Proposal 2:

Just completely comment out the whole zowe.setup.certificate section and make clear that users should go right down to the zowe.certificate area in which they'll find

zowe:
  certificate:
    keystore:
      type: JCERACFKS
      file: "safkeyring://${{zowe.setup.security.users.zowe}}/ZoweKeyring"
      alias: localhost
      password: password
    truststore:
      type: ${{ zowe.certificate.keystore.type }}
      file: ${{ zowe.certificate.keystore.file }}
      password: ${{ zowe.certificate.keystore.password }}

In other words, users need only alter the alias & end of file portions to get running. defaults.yaml could have complicated defaulting to hide away the truststore section entirely I suppose.

JoeNemo commented 1 hour ago

I like proposal 1 for it's stability over changes Zowe, administrators, and ZOS environment. The default should probably be false.