Managing secrets

When developing your application, you need to interact with other systems, for example, SSH to your z/OS system, pull and push from your Git repositories on a GitLab or GitHub server, or access asset stores such as artifactory. On a development laptop, you would typically manage keys and configuration settings for these systems in your home directory so they can be used for many different projects, for instance, you would use the same SSH keys for multiple Git repositories for many different projects on your GitHub server.

To achieve the same level of reuse and to securely manage your secrets, OpenShift Dev Spaces can manage these secrets and settings as Kubernetes secrets in your personal Kubernetes namespace in which your workspaces run on OpenShift. When a workspace is started, these secrets and settings will be mounted as files and provided read-only as symbolic links in your home directory. For example, a pair of private and public ssh keys would be stored as one Kubernetes secret in Openshift and then mounted as files ~/.ssh/rsa-id and ~/.ssh/rsa-id.pub to all your different Dev Spaces workspaces in your home directory whenever they start up.

In addition to every user creating and managing personal secrets, OpenShift Dev Spaces administrators can also set up OAuth-based authentication providers such as to a GitHub Enterprise server in your organization. This will allow you to access that server without the need of creating personal secrets, but by just using with your regular authentication method. Ask your administrator to review this documentation of the Red Hat administration guide with the details.

The Red Hat user documentation provides details for creating and managing personal secrets. As a convenience, here are instructions for creating all the secrets needed to access your remote z/OS system password-less. These steps are a prerequisite to run Ansible playbooks against your z/OS system.

Creating secrets for password-less access to your z/OS system

To ssh into a z/OS system, you need to create ssh private and public keys as well as a know_hosts file entry as K8s secrets.

In a nutshell to produce these secrets, for the experts, generally you need to perform the following steps:

1. Create RSA key pairs and base64-encode them
2. Create a known_hosts entry and base64-encode it
3. Create a secret OpenShift resource and submit it against your workspace's namespace
4. Upload the public key to z/OS

As OpenShift administrators will be able to access your secrets and decode your private key, It's strongly suggested that you create a fresh new key pair with a passphrase. You can perform all these step in a running Dev Spaces workspace. To do that, create a folder such as /project/ssh-keys or even /projects/zopeneditor-sample/ssh-keys, and store the intermediate files produced by these instructions there. After you finished, you can delete the entire directory. The following steps assume that you created and CDed into that new empty directory called ssh-keys in the Dev Spaces Terminal view.

1. Generate a new RSA key pair with the following command:

   ssh-keygen -t rsa -f devspaces-id -P ""
   

   The last -P parameter defines a passphrase, which you can provide to ensure that an OpenShift administrator will not be able to use your keys. If you leave it empty, you will not be prompted for the passphrase when using the keys.

2. Execute this command to generate the known_hosts entry needed for this secret. Replace the word hostname with the IP address or the fully qualified hostname that you are going to use for interacting with the z/OS system, for example, in the Ansible inventory files. Replace ibmuser with the username that you are going to use on this z/OS system. Also remember to provide a -p parameter for the ssh port to use if is no the standard port. This command will first prompt you to check the ECDSA key fingerprint and then for your z/OS password.

   ssh ibmuser@hostname -o UserKnownHostsFile=./known-hosts
   exit
   

   If you are doing this for multiple machines, execute this command against each one and then manually concatenate all the outputs separated by a newline character into one file.

3. Now you have three files in your folder that need to be base64 encoded so their content can be used with an OpenShift secret.

   cat devspaces-id | base64 | tr -d '\n' > devspaces-id-private.txt
   cat devspaces-id.pub | base64 | tr -d '\n' > devspaces-id-public.txt
   cat known-hosts | base64 | tr -d '\n' > known-hosts.txt
   

4. Create a new file called secret.yaml in your current Dev Spaces workspace so you can edit it with the editor.

   apiVersion: v1
   kind: Secret
   metadata:
     name: ssh-devspaces-secret
     labels:
       controller.devfile.io/mount-to-devworkspace: "true"
       controller.devfile.io/watch-secret: "true"
     annotations:
       controller.devfile.io/mount-path: "/home/user/.ssh"
   data:
     id_rsa: <paste-content-of-devspaces-id-private.txt>
     id_rsa.pub: <paste-content-of-devspaces-id-public.txt>
     known_hosts: <paste-contents-of-known_hosts.txt>
   

   As indicated, replace the three lines at the end with the content of your three txt files created in the previous steps.

5. If you have access to the OpenShift Console, then you could also use the (+) icon in OpenShift to submit this by copying and pasting it as an alternative. If you use the editor to create the file, then run this command from the Dev Spaces terminal to add the secret to your personal OpenShift namespace that runs your Dev Spaces workspaces.

   oc apply -f secret.yaml
   

6. Once the secret is submitted, the Dev Spaces workspace will prompt you to reload itself. Once that has finished, you can check if your secret was made available using the Terminal again.

   ll ~/.ssh
   total 0
   lrwxrwxrwx. 1 root 1000720000 13 May 30 22:20 id_rsa -> ..data/id_rsa
   lrwxrwxrwx. 1 root 1000720000 17 May 30 22:20 id_rsa.pub -> ..data/id_rsa.pub
   lrwxrwxrwx. 1 root 1000720000 18 May 30 22:20 known_hosts -> ..data/known_hosts
   

7. Now you can add your public key to the z/OS system via this command, which will again prompt you (for the last time) for your z/OS password. Again add a -p parameter for a custom ssh port.

   ssh-copy-id -f -i ~/.ssh/id_rsa.pub ibmuser@hostname
   

8. Perform the final test by logging on to the z/OS system, this time without being prompted.

   ssh ibmuser@hostname
   

Modifying secrets in the OpenShift web console

Once you have created your secrets via the oc apply command, you can easily review and edit them graphically in the OpenShift Developer web console.

1. You can navigate to the console from the OpenShift Dev Spaces dashboard by clicking the Applications icon (icon with nine squares) in the toolbar and select OpenShift console. Alternatively, if you are inside a OpenShift Dev Spaces workspace, then you can click the Dev Spaces icon and text in the editor's status bar all the way on the left and select Dev Spaces: Open OpenShift Console from the drop-down menu. If you are an Openshift administrator you will see the Administrative perspective of the OpenShift web console. Switch to the Developer perspective for these steps.
2. In the Developer perspective, the menu on the left will show you shortcuts to information that you have access to in the context of an OpenShift project, for example, Kubernetes namespace.
3. Switch to the project that manages your workspaces in the drop-down menu at the top. The name of your project is typically following the schema <user-login-name>-devspaces-<unique-identifier>.
4. After you selected your project, select the Secrets menu on the left, which will show you all the secrets that your project manages for your workspaces.
5. Within the secrets list, click on the ssh-devspaces-secret secret or whatever name you used in the steps above, if you created many secrets.
6. You can click the Reveal value link to display the contents of your secret. This can be useful if you want to copy your public ssh key and use it with another system.
7. In the Actions drop-down, select Edit Secrets, which will open a form-based editor in which you can make changes such as adding another known_hosts entry or swapping our your ssh keys.