[Feature Request]: Authentication persistence in a containerized environment.

[graycrow]

Problem to solve
On a containerized environment running the carbone-ee container, neither the generated token /carbone-ee-linux generate-token nor the signing keys are stored in persistent storage and are lost each time the container is restarted. This brings a lot of problems because of the overhead of tracking container restarts and managing authentication keys.

Proposed solution
Please add the ability to configure a signing key or JWT token via environment variables that can be easily passed to the running container.

Describe alternatives you've considered
Another alternative is to mount some directory to the persistent volume, but it will bring the number of required persistent storage volumes to 3 (in addition to app/render and app/template), which is too high, because on some environments (for example Azure AKS) the node VMs have a limited number of attachable disks. If a node has only 4 disk slots and one is already taken by the OS, there are only 3 slots left for all the pods to attach a persistent volume, and if all of them are used by Carbone, it's too luxurious. That's the real case I solved today.

[guillaume-carbone]

Hello,

One possible solution is to set CARBONE_EE_WORKDIR variable to /data (for example) and configure only one persistent storage for /data.
In this way, all folder like /template, /config, /render will be stored in the external volume.

Does this solve this problem?

[graycrow]

Thanks, looks like it will solve all issues, somehow I missed the CARBONE_EE_WORKDIR option.

[graycrow]

Btw, the generate-token command does not know that the workdir has been moved, it still looks for the key in the old location.

carbone@carbone-deployment-7d46986d99-smhwc:~$ ./carbone-ee-linux generate-token
[Error: ENOENT: no such file or directory, open '/app/config/key.pem'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/app/config/key.pem'
}
Error: Cannot read file /app/config/key.pem

carbone@carbone-deployment-7d46986d99-smhwc:~$ ls -la .
total 67248
drwxr-xr-x 1 carbone nogroup     4096 Mar 12 14:50 .
drwxr-xr-x 1 root    root        4096 Mar 12 14:50 ..
drwxr-xr-x 1 carbone nogroup     4096 Mar 12 14:50 .cache
drwx------ 2 carbone nogroup     4096 Mar 12 14:50 .config
-rwxr-xr-x 1 carbone nogroup 68819919 Mar  1 15:51 carbone-ee-linux
drwxr-xr-x 2 carbone nogroup     4096 Mar  1 15:52 config
drwxr-x--- 8 carbone nogroup     4096 Mar 12 14:50 data
drwxr-xr-x 2 carbone nogroup     4096 Mar  1 15:52 plugin
drwxr-xr-x 2 carbone nogroup     4096 Mar  1 15:52 render
drwxrwsr-x 3 root    nogroup     4096 Mar 12 14:50 template

carbone@carbone-deployment-7d46986d99-smhwc:~$ ls -la ./data
total 36
drwxr-x--- 8 carbone nogroup 4096 Mar 12 14:50 .
drwxr-xr-x 1 carbone nogroup 4096 Mar 12 14:50 ..
drwxr-x--- 2 carbone nogroup 4096 Mar 12 14:50 asset
drwxr-x--- 2 carbone nogroup 4096 Mar 12 14:50 config
drwxr-x--- 2 carbone nogroup 4096 Mar 12 14:50 plugin
drwxr-x--- 2 carbone nogroup 4096 Mar 12 14:50 queue
drwxr-x--- 2 carbone nogroup 4096 Mar 12 14:55 render
drwxr-x--- 2 carbone nogroup 4096 Mar 12 14:50 template

carbone@carbone-deployment-7d46986d99-smhwc:~$ ls -la ./data/config
total 20
drwxr-x--- 2 carbone nogroup 4096 Mar 12 14:50 .
drwxr-x--- 8 carbone nogroup 4096 Mar 12 14:50 ..
-rwxr-x--- 1 carbone nogroup  191 Mar 12 14:50 config.json
-rw------- 1 carbone nogroup  365 Mar 12 14:50 key.pem
-rw-r--r-- 1 carbone nogroup  268 Mar 12 14:50 key.pub

carbone@carbone-deployment-7d46986d99-smhwc:~$ ls -la ./config
total 12
drwxr-xr-x 2 carbone nogroup 4096 Mar  1 15:52 .
drwxr-xr-x 1 carbone nogroup 4096 Mar 12 14:50 ..

P.S. The JWT token I generated programmatically using the provided key works fine.

[guillaume-carbone]

Oh.
We'll be looking into this, and we're also thinking about a simpler solution for generating a token.

In the meantime, you can generate the token from /data :

cd /data
/app/carbone-ee-linux generate-token

[guillaume-carbone]

Hello,

We now recommand to manage key outside Carbone. This is new documentation extract from https://carbone.io :

Carbone key generation

When running Carbone for the first time, if no keys are present, Carbone automatically generate a key pair (key.pem and key.pub) in /app/config/.

To simplify migration and architecture issues, we strongly recommend that you generate your own keys and make them available to Carbone.

To do this, you must first generate a private key with the following command:

openssl ecparam -genkey -name secp521r1 -noout -out key.pem

Then the corresponding public key :

openssl ec -in key.pem -pubout -out key.pub 

Launching Carbone with your key

As with license provisioning, we recommend using a docker secret to map the public key to the container's config directory.

Here's an example using docker compose (file docker-compose.yml) :

version: "3.9"
services:
  carbone:
    image: carbone-ee:4.20.0
    platform: linux/amd64
    ports:
      - "4000:4000"
    secrets:
      - source: carbone-license
        target: /app/config/license.carbone-license
      - source: carbone-publickey
        target: /app/config/key.pub
    environment:
      - CARBONE_EE_STUDIO=true
      - CARBONE_EE_AUTHENTICATION=true
      - CARBONE_EE_STUDIOUSER=user:passw0rd
secrets:
  carbone-license:
    file: license.carbone-license
  carbone-publickey:
    file: key.pub

Generating JWT tokens for API use

Carbone uses standard ES512 JWT tokens.

You must then generate a token and sign it with your private key.

The JWT token must contain the following information.
Header :

{
    "alg" : "ES512",
    "typ" : "JWT"
}

Payload

{
    "iss" : "carbone-user",
    "aud" : "carbone-ee", 
    "exp" : xxxxx // timestamp en sec
}

Numerous solutions exist, but we suggest you use https://github.com/smallstep/cli

After installation, you just need to run the following command to generate one JWT token :

current_time=$(date +%s)
expiration_time=$(($current_time + 864000)) # Ten days from now for ex

step crypto jwt sign --alg ES512 --iss=carbone-user --subtle --aud=carbone-ee --exp=$expiration_time --key=key.pem 

Et voilà !