This documentation is for a release that is no longer maintained
See documentation for the latest supported version.Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 5. Using credentials and configurations in workspaces
You can use your credentials and configurations in your workspaces.
To do so, mount your credentials and configurations to the DevWorkspace
containers in the OpenShift cluster of your organization’s OpenShift Dev Spaces instance:
- Mount your credentials and sensitive configurations as Kubernetes Secrets. One example is a Git credentials store.
- Mount your non-sensitve configurations as Kubernetes ConfigMaps.
If you need to allow the DevWorkspace
Pods in the cluster to access container registries that require authentication, create an image pull Secret for the DevWorkspace
Pods.
The mounting process uses the standard Kubernetes mounting mechanism and requires applying additional labels and annotations to your existing resources. Resources are mounted when starting a new workspace or restarting an existing one.
You can create permanent mount points for various components:
-
Maven configuration, such as the
settings.xml
file - SSH key pairs
- AWS authorization tokens
- Configuration files
- Persistent storage
- Git credentials store files
Additional resources
5.1. Using a Git credentials store Copier lienLien copié sur presse-papiers!
As an alternative to the OAuth for GitHub, GitLab, or Bitbucket that is configured by the administrator of your organization’s OpenShift Dev Spaces instance, you can apply your Git credentials store as a Kubernetes Secret.
Apply the Kubernetes Secret in your user project of the OpenShift cluster of your organization’s OpenShift Dev Spaces instance.
When you apply the Secret, a Git configuration file with the path to the mounted Git credentials store is automatically configured and mounted to the DevWorkspace
containers in the cluster at /etc/gitconfig
. This makes your Git credentials store available in your workspaces.
Prerequisites
-
An active
oc
session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI. -
base64
command line tools are installed in the operating system you are using.
Procedure
In your home directory, locate and open your
.git-credentials
file if you already have it. Alternatively, if you do not have this file, save a new.git-credentials
file, using the Git credentials storage format. Each credential is stored on its own line in the file:https://<username>:<token>@<git_server_hostname>
https://<username>:<token>@<git_server_hostname>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example 5.1. A line in a
.git-credentials
filehttps://trailblazer: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@github.com
https://trailblazer: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@github.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Select credentials from your
.git-credentials
file for the Secret. Encode the selected credentials to Base64 for the next step.TipTo encode all lines in the file:
$ cat .git-credentials | base64 | tr -d '\n'
To encode a selected line:
$ echo -n '<copied_and_pasted_line_from_.git-credentials>' | base64
Create a new OpenShift Secret in your user project.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The
controller.devfile.io/git-credential
label marks the Secret as containing Git credentials. - 2
- A custom absolute path in the
DevWorkspace
containers. The Secret is mounted as thecredentials
file at this path. The default path is/
. - 3
- The selected content from
.git-credentials
that you encoded to Base64 in the previous step.
TipYou can create and apply multiple Git credentials Secrets in your user project. All of them will be copied into one Secret that will be mounted to the
DevWorkspace
containers. For example, if you set the mount path to/etc/secret
, then the one Secret with all of your Git credentials will be mounted at/etc/secret/credentials
. You must set all Git credentials Secrets in your user project to the same mount path. You can set the mount path to an arbitrary path because the mount path will be automatically set in the Git configuration file configured at/etc/gitconfig
.Apply the Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. Enabling artifact repositories in a restricted environment Copier lienLien copié sur presse-papiers!
By configuring technology stacks, you can work with artifacts from in-house repositories using self-signed certificates:
5.2.1. Enabling Maven artifact repositories Copier lienLien copié sur presse-papiers!
You can enable a Maven artifact repository in Maven workspaces that run in a restricted environment.
Prerequisites
- You are not running any Maven workspace.
Procedure
Apply the Secret for the TLS certificate:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Base64 encoding with disabled line wrapping.
Apply the ConfigMap to create the
settings.xml
file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the ConfigMap for the TrustStore initialization script:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Start a Maven workspace.
-
Open a new terminal in the
tools
container. -
Run
~/init-truststore.sh
.
5.2.2. Enabling Gradle artifact repositories Copier lienLien copié sur presse-papiers!
You can enable a Gradle artifact repository in Gradle workspaces that run in a restricted environment.
Prerequisites
- You are not running any Gradle workspace.
Procedure
Apply the Secret for the TLS certificate:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Base64 encoding with disabled line wrapping.
Apply the ConfigMap for the TrustStore initialization script:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the ConfigMap for the Gradle init script:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Start a Gradle workspace.
-
Open a new terminal in the
tools
container. -
Run
~/init-truststore.sh
.
5.2.3. Enabling npm artifact repositories Copier lienLien copié sur presse-papiers!
You can enable an npm artifact repository in npm workspaces that run in a restricted environment.
Prerequisites
- You are not running any npm workspace.
Applying a ConfigMap that sets environment variables might cause a workspace boot loop.
If you encounter this behavior, remove the ConfigMap
and edit the devfile directly.
Procedure
Apply the Secret for the TLS certificate:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Base64 encoding with disabled line wrapping.
Apply the ConfigMap to set the following environment variables in the
tools
container:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.4. Enabling Python artifact repositories Copier lienLien copié sur presse-papiers!
You can enable a Python artifact repository in Python workspaces that run in a restricted environment.
Prerequisites
- You are not running any Python workspace.
Applying a ConfigMap that sets environment variables might cause a workspace boot loop.
If you encounter this behavior, remove the ConfigMap
and edit the devfile directly.
Procedure
Apply the Secret for the TLS certificate:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Base64 encoding with disabled line wrapping.
Apply the ConfigMap to set the following environment variables in the
tools
container:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.5. Enabling Go artifact repositories Copier lienLien copié sur presse-papiers!
You can enable a Go artifact repository in Go workspaces that run in a restricted environment.
Prerequisites
- You are not running any Go workspace.
Applying a ConfigMap that sets environment variables might cause a workspace boot loop.
If you encounter this behavior, remove the ConfigMap
and edit the devfile directly.
Procedure
Apply the Secret for the TLS certificate:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Base64 encoding with disabled line wrapping.
Apply the ConfigMap to set the following environment variables in the
tools
container:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.6. Enabling NuGet artifact repositories Copier lienLien copié sur presse-papiers!
You can enable a NuGet artifact repository in NuGet workspaces that run in a restricted environment.
Prerequisites
- You are not running any NuGet workspace.
Applying a ConfigMap that sets environment variables might cause a workspace boot loop.
If you encounter this behavior, remove the ConfigMap
and edit the devfile directly.
Procedure
Apply the Secret for the TLS certificate:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Base64 encoding with disabled line wrapping.
Apply the ConfigMap to set the environment variable for the path of the TLS certificate file in the
tools
container:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the ConfigMap to create the
nuget.config
file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. Creating image pull Secrets Copier lienLien copié sur presse-papiers!
To allow the DevWorkspace
Pods in the OpenShift cluster of your organization’s OpenShift Dev Spaces instance to access container registries that require authentication, create an image pull Secret.
You can create image pull Secrets by using oc
or a .dockercfg
file or a config.json
file.
5.3.1. Creating an image pull Secret with oc Copier lienLien copié sur presse-papiers!
Prerequisites
-
An active
oc
session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI.
Procedure
In your user project, create an image pull Secret with your private container registry details and credentials:
oc create secret docker-registry <Secret_name> \ --docker-server=<registry_server> \ --docker-username=<username> \ --docker-password=<password> \ --docker-email=<email_address>
$ oc create secret docker-registry <Secret_name> \ --docker-server=<registry_server> \ --docker-username=<username> \ --docker-password=<password> \ --docker-email=<email_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following label to the image pull Secret:
oc label secret <Secret_name> controller.devfile.io/devworkspace_pullsecret=true controller.devfile.io/watch-secret=true
$ oc label secret <Secret_name> controller.devfile.io/devworkspace_pullsecret=true controller.devfile.io/watch-secret=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.2. Creating an image pull Secret from a .dockercfg file Copier lienLien copié sur presse-papiers!
If you already store the credentials for the private container registry in a .dockercfg
file, you can use that file to create an image pull Secret.
Prerequisites
-
An active
oc
session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI. -
base64
command line tools are installed in the operating system you are using.
Procedure
Encode the
.dockercfg
file to Base64:cat .dockercfg | base64 | tr -d '\n'
$ cat .dockercfg | base64 | tr -d '\n'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a new OpenShift Secret in your user project:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.3. Creating an image pull Secret from a config.json file Copier lienLien copié sur presse-papiers!
If you already store the credentials for the private container registry in a $HOME/.docker/config.json
file, you can use that file to create an image pull Secret.
Prerequisites
-
An active
oc
session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI. -
base64
command line tools are installed in the operating system you are using.
Procedure
Encode the
$HOME/.docker/config.json
file to Base64.cat config.json | base64 | tr -d '\n'
$ cat config.json | base64 | tr -d '\n'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a new OpenShift Secret in your user project:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. Mounting Secrets Copier lienLien copié sur presse-papiers!
To mount confidential data into your workspaces, use Kubernetes Secrets.
Using Kubernetes Secrets, you can mount usernames, passwords, SSH key pairs, authentication tokens (for example, for AWS), and sensitive configurations.
Mount Kubernetes Secrets to the DevWorkspace
containers in the OpenShift cluster of your organization’s OpenShift Dev Spaces instance.
Prerequisites
-
An active
oc
session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI. -
You have created a new Secret or determined an existing one in your user project to mount to all
DevWorkspace
containers.
Procedure
- Determine an existing ConfigMap or Secret in your user project to mount to all workspace containers.
Set the required labels for mounting.
oc label secret <Secret_name> \ controller.devfile.io/mount-to-devworkspace=true \ controller.devfile.io/watch-secret=true
$ oc label secret <Secret_name> \ controller.devfile.io/mount-to-devworkspace=true \ controller.devfile.io/watch-secret=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: Use the annotations to configure how the Secret is mounted.
Expand Table 5.1. Optional annotations Annotation Description controller.devfile.io/mount-path:
Specifies the mount path.
Defaults to
/etc/secret/<Secret_name>
.controller.devfile.io/mount-as:
Specifies how the resource should be mounted:
file
,subpath
, orenv
.Defaults to
file
.mount-as: file
mounts the keys and values as files within the mount path.mount-as: subpath
mounts the keys and values within the mount path using subpath volume mounts.mount-as: env
mounts the keys and values as environment variables in allDevWorkspace
containers.
Example 5.2. Mounting a Secret as a file
When you start a workspace, the /home/user/.m2/settings.xml
file will be available in the DevWorkspace
containers.
With Maven, you can set a custom path for the settings.xml
file. For example:
mvn --settings /home/user/.m2/settings.xml clean install
$ mvn --settings /home/user/.m2/settings.xml clean install
5.5. Mounting ConfigMaps Copier lienLien copié sur presse-papiers!
To mount non-confidential configuration data into your workspaces, use Kubernetes ConfigMaps.
Using Kubernetes ConfigMaps, you can mount non-sensitive data such as configuration values for an application.
Mount Kubernetes ConfigMaps to the DevWorkspace
containers in the OpenShift cluster of your organization’s OpenShift Dev Spaces instance.
Prerequisites
-
An active
oc
session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI. -
You have created a new ConfigMap or determined an existing one in your user project to mount to all
DevWorkspace
containers.
Procedure
- Determine an existing ConfigMap in your user project to mount to all workspace containers.
Set the required labels for mounting.
oc label configmap <ConfigMap_name> \ controller.devfile.io/mount-to-devworkspace=true \ controller.devfile.io/watch-configmap=true
$ oc label configmap <ConfigMap_name> \ controller.devfile.io/mount-to-devworkspace=true \ controller.devfile.io/watch-configmap=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: Use the annotations to configure how the ConfigMap is mounted.
Expand Table 5.2. Optional annotations Annotation Description controller.devfile.io/mount-path:
Specifies the mount path.
Defaults to
/etc/config/<ConfigMap_name>
.controller.devfile.io/mount-as:
Specifies how the resource should be mounted:
file
,subpath
, orenv
.Defaults to
file
.mount-as:file
mounts the keys and values as files within the mount path.mount-as:subpath
mounts the keys and values within the mount path using subpath volume mounts.mount-as:env
mounts the keys and values as environment variables in allDevWorkspace
containers.
Example 5.3. Mounting a ConfigMap as environment variables
When you start a workspace, the <env_var_1>
and <env_var_2>
environment variables will be available in the DevWorkspace
containers.