We have deployed on our cluster https://github.com/stakater/Reloader which allow your application to automatically be redeployed if a secret or confimaps change is detected.

Simply annotate your deployment,cronjob,statefullset etc....


annotations:
    reloader.stakater.com/auto: "true"

In the context of the App template bwj-s since we are using a helmRelease you should annotate the controller. As an example for the echo-server.


values:
    controllers:
      echo-server:
        annotations:
          reloader.stakater.com/auto: "true"
        replicas: 2
        strategy: RollingUpdate

Encryption

In regard of GitOps there is multiple way to handle encryption of secret that live within a git repository. We recommending you to use SOPS as you encryption engine.

We have already Setup a key Private key dedicated to your namespace that will be able to decrypt any secret that you is in your git repository.

./sops.yaml is the configuration file that will handle how you secret will be encrypted while using sops.

Quick Start

To work with secret you'll need:

Create your own key

Linux

mkdir -p $XDG_CONFIG_HOME/sops/age
age-keygen -o $XDG_CONFIG_HOME/sops/age/keys.txt

MacOS

mkdir -p "$HOME/Library/Application Support/sops/age"
age-keygen -o "$HOME/Library/Application Support/sops/age/keys.txt"

Propagate your Public key

Edit the ./sops.yaml file and add your public key that you have generated previously.

Please notice that you can copy this file into any subfolder of your project in case you need to have different keys depending on your secrets file. This is useful to limit who has access to the production secrets while all developers might have access to the dev secrets.

$ cat .sops.yaml
  ---
  
  # This example uses YAML anchors which allows reuse of multiple keys
  # without having to repeat yourself.
  # Also see https://github.com/Mic92/dotfiles/blob/master/nixos/.sops.yaml
  # for a more complex example.
  keys:
    age:
    - &cluster_age_key age13jnzxrtrghlh8zvc9q3d8yd2a9xdp8jset72l8dwz6pept3j3c0qkmxd47
    - &YOUR_KEY_NAME <PUBLIC_KEY>
  creation_rules:
    - path_regex: .+secret(\.sops)?\.ya?ml
      input_type: yaml
      encrypted_regex: ^(data|stringData)$
      key_groups:
        - age: &key_groups
            - *cluster_age_key
            - *YOUR_KEY_NAME
    - path_regex: .+secret(\.sops)?\.env
      input_type: env
      key_groups:
        - age: *key_groups
  stores:
    yaml:
      indent: 2

Create your first secret

$ sops name_of_you_file.secret.sops.yaml
``
You can then deploy it the cluster will be able to Decrypt it using it's public
key

##### Edit secrets

You can use the same command used to create new secrets to edit existing files

You can also use [this VSCode plugin](https://marketplace.visualstudio.com/items?itemName=signageos.signageos-vscode-sops)

##### Rewrapping secret

In case add/remove a key secret generated previously will need to be
reencrypted with the appropriate key.  We have place a [shell
script](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/scripts/rewrap-secrets.sh) that will do that for you. 

It will reencrypt all the secret that it will find in folder and subfolder
following the .sops.yaml rules files of your directory.


| :boom: INFOS               |
|:----------------------------|
| You can have as many .sops.yaml file as you want in your repository |
=======
# Environments

## Variables
<b style='color: lightblue;'>kustomization/vars</b>

We already introduce you to the vars kustomization earlier. This kustomization
is responsable for loading any variables into your tenant

```mermaid
graph LR
    A["<b style='color: #FF8C00;'>tenant-apps</b>"]:::mainEntry -->|Loading| B["<b style='color: #1E90FF;'>vars/kustomization</b>"]:::intermediate
    B -->|Loading| C["<b style='color: #32CD32;'>/vars/tenant_name/kustomization.yaml</b>"]:::finalStep
    
    classDef mainEntry fill:#FFFACD,stroke:#FF8C00,stroke-width:2px,stroke-dasharray: 5 5;
    classDef intermediate fill:#E0FFFF,stroke:#1E90FF,stroke-width:2px,stroke-dasharray: 5 5;
    classDef finalStep fill:#E0FFD1,stroke:#32CD32,stroke-width:2px,stroke-dasharray: 5 5;

Once variables are loaded you can referenced them on any Kube Ressources

In our example.


$ oc get configmap -n tenant-tpl(our_tenant_name)
NAME                       DATA   AGE
example-vars               1      16s

Using varialbes into Flux HelmRelease

From our echo-server HR definition you can see the following sections

Secret

{WIP}