# Pass Kubernetes secrets to portable services using ConfigMap 

> [HTML Version](configmap-secrets.html)

You can configure the [portable service](portable-services.md) of the custom module to receive encrypted sensitive data. To do this, in the `values‑brix365.yaml` ​​file, [enable the use of ConfigMap](configmap.md#enable-configmap), a Kubernetes resource for working with configuration data.



If you need to pass sensitive information, such as a database connection string, to the portable service:  


1. [Save sensitive data to a Kubernetes secret](#create-secrets).

2. [Set rules for secret passing using ConfigMap](#secret-rule).



## Step 1: Save the secret in the namespace of the portable services

A single Kubernetes secret can store multiple keys, not all of which are used in the portable service. When you configure a rule for a Kubernetes secret in a ConfigMap, it is passed with all the keys it contains. Therefore, it is recommended to create a separate secret and add to it only the keys required for the portable service. This approach will prevent the accidental transfer of redundant sensitive data.



The secret is created in the namespace of the portable services — by default, this is `brix365‑applets`. To do this:



1. Create a secret manifest in **.yaml** format:

````
apiVersion: v1  
kind: Secret  
metadata:  
 name: mysecret # The secret name. Specified according to the DNS Subdomain Names format. For more information, see the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)  
type: Opaque # Use the default value  
data:  
 key1: YmFy # Specify the Base64-encoded key values  
 key2: Zm9v

````


2. Create the secret:

````
kubectl apply -f ./mysecret.yaml -n brix365-applets 

````
Where:

- `mysecret.yaml` is the secret manifest.

- `brix365‑applets` is the namespace in which the portable services are located.

## Step 2: Set rules for passing secrets using ConfigMap

1. Once you've prepared the secret to pass to the portable service, open the ConfigMap file for editing using the command:

````
kubectl edit configmap brix365-babysitter-config -n brix365-applets

````
Where:



- `brix365‑babysitter‑config`  is the name of the ConfigMap.

- `brix365‑applets` is the namespace where the portable services are located.



2. In the file that opens, in the `secretMappings` parameter, configure the rule for passing secrets to the portable service. You can set this parameter:



- In the `global` block. The secret will apply to portable services in all pods for which separate secret rules are not configured.

- In a separate block. Create one with the unique name of the portable service to pass the secret only to that pod. Create a block name using the template `\{company\}.ext\_\{id\}.\{uniquename\}`. For more information on naming a block that specifies parameters for a specific service, see the [article on configuring ConfigMap](configmap.md#service-block-name).  
  
Please note that the value of the `secretMappings` parameter from the block for a specific portable service has a higher priority than the value from the `global` block. If the parameter is not specified at the level of the portable service, the value from the `global` block is used.



3. In the `secretMappings` parameter, you can specify rules for an unlimited number of secrets. For each secret, specify:



- `secretRef`. The name of the secret from which all keys contained within it are passed.

- `type`. The secret transfer method. Available options:

	- `env`. Keys from the secret are passed to the environment variables of the portable service.

	- `volume`. Keys from the secret are transferred to the file system of the portable service.

	- `mountPath`. If you selected the secret passing method to the file system of the portable service, specify the path to the directory where the files containing the secret keys will be stored.



**Important**: The `mountPath` parameter must be unique for each secret transferred to the portable service.

````
начало примечание

````
**Note**  
****  
It is recommended to use the file system for storing secrets rather than environment variables. This approach is more secure and ensures that new values ​​are immediately applied if they change in secrets already transferred to the service. When storing secrets in the environment variables of the portable service, a restart of the service is required to use the updated secrets.

````
конец примечание

4. ````
After adding changes, apply them using the command specifying the namespace in which the portable services are located:

````
kubectl apply -f cfg.yaml -n brix365-applets

````
The configured `secretMappings` parameter will be applied automatically, as the `babysitter` service monitors changes in the ConfigMap. All microservices for which the settings have changed will restart. 



## Use case for configuring the secretMappings parameter



Let's look how configured rules for passing secrets are applied. Let's assume we want to pass secrets to several portable services as follows:

| | |
|------|------|
| **Portable Service** | **Passed Secrets** |
| **portableservice1** | Secrets named `secret1` and `secret2` are passed to the portable service's environment variables. |
| **portableservice2** | Secrets named `secret1` and `secret2` are passed to environment variables, and `secret3` is passed to the file system of the portable service. |
| `portableservice3`** **and other portable services | Secret named `secret1` are added to the environment variables of any portable services. |


To do this:



1. In the `brix365‑applets` namespace, [create secrets](#create-secrets) with the following names:

- `secret1`.

- `secret2`.

- `secret3`.



2. In the ConfigMap file, specify the secret transfer rules:



1. In the `global` block, specify the secret named `secret1`, as it is used in the `portableservice3`, as well as in other portable services.

2. Since the `portableservice1` and `portableservice2` use additional `secret2` and `secret3`** **secrets, create separate blocks for these services and specify individual secret rules for them. 



The resulting ConfigMap might look like this:



````
global:  
   secretMappings:  
   - secretRef: "secret1" # Name of the secret from which all keys are passed  
     type: "env"  
\# Parameters for the portable service with the unique name portableservice1  
jilybhacnrpeu.ext\_4a685c94-3dcd-433a-ac5f-6367aaf38950.portableservice1:  
   secretMappings:  
   - secretRef: "secret1" # Name of the secret from which all keys are passed  
     type: "env"  
   - secretRef: "secret2" # Name of the secret from which all keys are passed  
     type: "env"  
\# Parameters for the portable service with the unique name portableservice2  
jilybhacnrpeu.ext\_4a685c94-3dcd-433a-ac5f-6367aaf38950.portableservice2:  
   secretMappings:  
   - secretRef: "secret1" # name of the secret from which all keys are passed  
     type: "env"  
   - secretRef: "secret2" # name of the secret from which all keys are passed  
     type: "env"  
   - secretRef: "secret3" # name of the secret from which all keys are passed  
     type: "volume"  
     mountPath: '/etc/secrets'  
\# Parameters for the portable service with the unique name portableservice3  
jilybhacnrpeu.ext\_4a685c94-3dcd-433a-ac5f-6367aaf38950.portableservice3:  
   replicaCount: 1
````