You can find links to the related video recordings and printable materials at the end of this post.

• Video
• Python and FastAPI skeleton
  • Environment and dependencies
  • Write code
  • Test the code
• Local DB: Redis-Stack
  • Setup
  • Update the code
  • Test the code
• Local dockerized Redis Enterprise
  • Provision Redis Enterprise
  • Create a cluster
  • Create a database with needed modules
  • Update the code with password authentication
  • Test the code
• Package the microservice
  • Environment and dependencies
  • Build the docker container
  • Run the packaged microservice
  • Test the microservice
• Use a managed Redis Enterprise
  • Create a Redis Enterprise database in GCP
  • Update the connection details
  • Test the packaged microservice
• Deploy in Google CloudRun
  • Create the application
  • Test the application
• Materials and Links
• Footnotes

Video

Python and FastAPI skeleton

Environment and dependencies

First, You need to create a folder to create and store the sources and a Python virtual environment :

mkdir FastApiDemo
cd FastApiDemo
python3 -m venv venv
source venv/bin/activate
pip install fastapi
pip install uvicorn

Write code

Then, you can start with a very simple list of object stored in an array and two basic REST API endpoints implementing GET and PUT endpoints.

main.py :

# Data model
#
from pydantic import BaseModel
from typing import Union
class User(BaseModel):
    name: str
    email: str
    age: int
    city: str
    height: float
    weight: float
    gender: Union[bool, None] = None

users = []

# Expose data access with a REST API provided by FastAPI
#
from fastapi import FastAPI
app = FastAPI()

# Read endpoint
#
@app.get("/users/{user_id}")
def read_user(user_id: int):
    return users[user_id]

# Write endpoint
#
@app.put("/users/{user_id}")
def update_user(user_id: int, user: User):
    while (len(users)<=user_id):
        users.append("");
    users[user_id]=user
    return True

Test the code

Now, we can start the uvicorn server and test the GET/PUT endpoints both with curl in command line and with the embedded Swagger Web user interface (http://localhost:8000/docs)

uvicorn main:app --reload

curl http://localhost:8000/users/1 --request GET --header 'content-type: application/json'
curl --request PUT --url "http://localhost:8000/users/1" --header 'content-type: application/json' --data '{"name":"Paul John","email":"paul.john@example.com","age":42,"city":"London","height":0,"weight":0,"gender":"True"}'
curl http://localhost:8000/users/1 --request GET --header 'content-type: application/json'
xdg-open http://localhost:8000/docs

Local DB: Redis-Stack

Now, we want to use a Redis database to store the records instead of a simple object array. This will make our microservice completely stateless.

Setup

First, we can start a dockerized image of Redis Open-source with all the official modules. It exposes the Redis database on the standard port 6379 and a RedisInsight client Web user interface on port 8001 :

docker run -p 6379:6379 -p 8001:8001 --name redis-stack redis/redis-stack

Then, you need to add the Redis Python client library to the development environment and use environment variables to store the database connection details :

pip install "redis[hiredis]"
export REDISHOST=localhost
export REDISPORT=6379

Update the code

Now, you can update the code :

1. remove the object array
2. include the Redis Python client library
3. open a connection to the database
4. optionnaly prepopulate the database with some sample records
5. update the GET endpoint to fetch data from Redis
6. update the PUT endpoint to store data in Redis

# Data model
#
from pydantic import BaseModel
from typing import Union
class User(BaseModel):
    name: str
    email: str
    age: int
    city: str
    height: float
    weight: float
    gender: Union[bool, None] = None

#users = []
# Data storage in Redis
#
import redis
import os
r = redis.Redis(
        host=os.environ.get('REDISHOST'),
        port=os.environ.get('REDISPORT'),
        )

# Prepopulate wih sample data
# JSON data stored in a Redis JSON datastructure
#
from redis.commands.json.path import Path
r.json().set("user:1", Path.root_path(), { "name": "Paul John", "email": "paul.john@example.com", "age": 42, "city": "London" })
r.json().set("user:2", Path.root_path(), { "name": "Eden Zamir", "email": "eden.zamir@example.com", "age": 29, "city": "Tel Aviv" })
r.json().set("user:3", Path.root_path(), { "name": "Paul Zamir", "email": "paul.zamir@example.com", "age": 35, "city": "Tel Aviv" })

# Expose data access with a REST API provided by FastAPI
#
from fastapi import FastAPI
app = FastAPI()

# Read endpoint
#
@app.get("/users/{user_id}")
def read_user(user_id: int):
    return r.json().get("user:"+str(user_id))

# Write endpoint
#
@app.put("/users/{user_id}")
def update_user(user_id: int, user: User):
    return r.json().set('user:'+str(user_id), Path.root_path(),
        { "name": user.name, "email": user.email, "age": user.age, "city": user.city, "height": user.height, "weight": user.weight, "gender": user.gender })

Test the code

Now, we can restart the local application server :

uvicorn main:app --reload

and try to get the 4 first records :

for i in 1 2 3 4; do
  printf "\n%s: " "$i"
  curl http://localhost:8000/users/$i --request GET --header 'content-type: application/json'
done

The fourth one does not exist yet and should return null. Lets create it and check in the Swagger interface :

curl --request PUT --url "http://localhost:8000/users/4" --header 'content-type: application/json' --data '{"name":"Francois Cerbelle","email":"francois@redis.com","age":48,"city":"Paris","height":179,"weight":84,"gender":"True"}'
xdg-open http://localhost:8000/docs

Local dockerized Redis Enterprise

The goal is to use a development environment as close as possible to the final production environment. Thus, lets replace our local dockerized redis-stack by a local dockerized redis-enterprise database.

Provision Redis Enterprise

First, we can start the redis-enterprise docker image. I expose the ports for both the web administration interface and the REST API :

docker run -d --cap-add sys_resource --name redisenterprise1 -p 8443:8443 -p 9443:9443 redislabs/redis

Create a cluster

First, we need to initialize the Redis-Enterprise cluster with a first, and only, node. We can use to web admin interface (https://localhost:8443) ;

xdg-open https://localhost:8443

or the REST API

curl "https://127.0.0.1:9443/v1/bootstrap/create_cluster" --insecure -X "POST" -H "Accept:application/json" -H "Content-Type:application/json" -u "francois@redis.com:password" -d '{"action": "create_cluster","cluster": { "name": "cluster.local" },"node": {"paths": {"persistent_path": "/var/opt/redislabs/persist","ephemeral_path": "/var/opt/redislabs/tmp","bigredis_storage_path": "/var/opt/redislabs/flash"}},"license": "","credentials": {"username": "francois@redis.com","password": "password"}}'

Create a database with needed modules

Then, we can ask the Redis-cluster to create, monitor, maintain and expose a redis database with the required modules only (JSON and Search). We will use the web administration interface, but we could also use the REST API.

xdg-open https://localhost:8443

We now have a redis database, lets define the connection details in the environment variables for our application. We will use the web administration interface to find them, but we could also use the REST API.

export REDISHOST=172.17.0.2
export REDISPORT=12581
export REDISPASS=xxx

Update the code with password authentication

Now, we have to update our source code to use the provided connection password.

# Data model
#
from pydantic import BaseModel
from typing import Union
class User(BaseModel):
    name: str
    email: str
    age: int
    city: str
    height: float
    weight: float
    gender: Union[bool, None] = None

#users = []
# Data storage in Redis
#
import redis
import os
r = redis.Redis(
        host=os.environ.get('REDISHOST'),
        port=os.environ.get('REDISPORT'),
        password=os.environ.get('REDISPASS'),
        )

# Prepopulate wih sample data
# JSON data stored in a Redis JSON datastructure
#
from redis.commands.json.path import Path
r.json().set("user:1", Path.root_path(), { "name": "Paul John", "email": "paul.john@example.com", "age": 42, "city": "London" })
r.json().set("user:2", Path.root_path(), { "name": "Eden Zamir", "email": "eden.zamir@example.com", "age": 29, "city": "Tel Aviv" })
r.json().set("user:3", Path.root_path(), { "name": "Paul Zamir", "email": "paul.zamir@example.com", "age": 35, "city": "Tel Aviv" })

# Expose data access with a REST API provided by FastAPI
#
from fastapi import FastAPI
app = FastAPI()

# Read endpoint
#
@app.get("/users/{user_id}")
def read_user(user_id: int):
    return r.json().get("user:"+str(user_id))

# Write endpoint
#
@app.put("/users/{user_id}")
def update_user(user_id: int, user: User):
    return r.json().set('user:'+str(user_id), Path.root_path(),
        { "name": user.name, "email": user.email, "age": user.age, "city": user.city, "height": user.height, "weight": user.weight, "gender": user.gender })

Test the code

We can test our microservice, you should be confortable, now. Restart the service

uvicorn main:app --reload

Use the same test scenario as previously

for i in 1 2 3 4; do
  printf "\n%s: " "$i"
  curl http://localhost:8000/users/$i --request GET --header 'content-type: application/json'
done
curl --request PUT --url "http://localhost:8000/users/4" --header 'content-type: application/json' --data '{"name":"Francois Cerbelle","email":"francois@redis.com","age":48,"city":"Paris","height":179,"weight":84,"gender":"True"}'
xdg-open http://localhost:8000/docs

Package the microservice

Environment and dependencies

requirements.txt :

typing
pydantic
fastapi
uvicorn
redis

Dockerfile :

# From https://cloud.google.com/run/docs/quickstarts/build-and-deploy/python?hl=fr

# Use the official lightweight Python image.
# https://hub.docker.com/_/python
FROM python:3.10-slim

# Allow statements and log messages to immediately appear in the Knative logs
ENV PYTHONUNBUFFERED True

# Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./

# Install production dependencies.
RUN pip install --no-cache-dir -r requirements.txt

# Run the web service on container startup. Here we use the gunicorn
# webserver, with one worker process and 8 threads.
# For environments with multiple CPU cores, increase the number of workers
# to be equal to the cores available.
# Timeout is set to 0 to disable the timeouts of the workers to allow Cloud Run to handle instance scaling.
#CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app
CMD exec uvicorn --host 0.0.0.0 --port $PORT main:app

.dockerignore :

Dockerfile
README.md
*.pyc
*.pyo
*.pyd
__pycache__
.pytest_cache

Build the docker container

docker build -t fastapi .

Run the packaged microservice

docker run --env PORT=8000 --env REDISHOST=$REDISHOST --env REDISPORT=$REDISPORT --env REDISPASS=$REDISPASS -p 8000:8000 --rm fastapi

Test the microservice

for i in 1 2 3 4; do
  printf "\n%s: " "$i"
  curl http://localhost:8000/users/$i --request GET --header 'content-type: application/json'
done
curl --request PUT --url "http://localhost:8000/users/4" --header 'content-type: application/json' --data '{"name":"Francois Cerbelle","email":"francois@redis.com","age":48,"city":"Paris","height":179,"weight":84,"gender":"True"}'
xdg-open http://localhost:8000/docs

Use a managed Redis Enterprise

Next step is to use a real Redis-Enterprise managed instance (DBaaS) in the cloud from our local dockerized microservice.

Create a Redis Enterprise database in GCP

You need to create an account and connect to the Redis Cloud portal (https://app.redislabs.com)

Then, you need to create a new subscription (cluster). You have to choose the Plan (flexible),

the cloud provider (GCP), the region (europe-west1) and to give it a name.

Next, you have to list the database specifications : a name, optionnaly a port, the activated modules (only JSON and Search), the dataset size and throughput, the high-availability option and validate. We only need one database.

Next screen lets you check all the details and enter your payment details. You can use free trial links from https://redis.com.

The cluster will be provisionned, the database created and it will be available approximately 15 minutes later.

You can connect RedisInsight, Redis Command Line or several source codes, using either a private endpoint (only reachable from GCP) or a public endpoint.

Update the connection details

Use the connection details from the portal to update the connection environment variables.

export REDISHOST=redis-16566.c29816.eu-west1-mz.gcp.cloud.rlcp.com
export REDISPORT=16566
export REDISPASS=

Test the packaged microservice

docker run --env PORT=8000 --env REDISHOST=$REDISHOST --env REDISPORT=$REDISPORT --env REDISPASS=$REDISPASS -p 8000:8000 --rm fastapi

for i in 1 2 3 4; do
  printf "\n%s: " "$i"
  curl http://localhost:8000/users/$i --request GET --header 'content-type: application/json'
done
curl --request PUT --url "http://localhost:8000/users/4" --header 'content-type: application/json' --data '{"name":"Francois Cerbelle","email":"francois@redis.com","age":48,"city":"Paris","height":179,"weight":84,"gender":"True"}'
xdg-open http://localhost:8000/docs

Deploy in Google CloudRun

Finally, we have a containerizable microservice which can be run anywhere and which can connect to any Redis database. We have a managed Redis Enterprise database. Last step is to deploy the microservice in Google CloudRun and make it use our Redis database.

Create the application

Despite we could upload the docker image to the “Google Artefact Repository” and the choose it to be executed by the “Google CloudRun” service. In my case, for the demo, I use a single command line to send the current folder’s source code to Google, to ask Google to create the Docker image, to store the image in the “Artefact Repository” and to use it in a new “fastapi” CloudRun service with the Redis enterprise connection parameters :

gcloud run deploy --source . --allow-unauthenticated --port=8080 --service-account=319143195410-compute@developer.gserviceaccount.com --min-instances=1 --set-env-vars=REDISHOST=$REDISHOST,REDISPORT=$REDISPORT,REDISPASS=$REDISPASS --cpu-boost --region=europe-west1 --project=central-beach-194106

It is deployed as a Google CloudRun service

Test the application

It exposes the Swagger web user interface

New records are stored in Redis Enterprise Cloud (Managed) on GCP

Materials and Links

• Demo video ¹

Footnotes

Vous pouvez trouver des liens vers les enregistrements vidéo et les supports imprimables associés à la fin de cet article.

• Vidéo
• Squelette Python et FastAPI
  • Environement de dev
  • Code de l’API
  • Test de l’API
• Base locale : Redis-Stack
  • Préparation
  • Utilisation de Redis dans le code
  • Test de l’API
• Base locale : Redis Enterprise
  • Installation rapide
  • Initialisation du cluster
  • Création de la base
  • Authentification depuis le code
  • Test du microservice
• Dockerisation du microservice
  • Préparation
  • Construction du conteneur
  • Exécution du microservice
  • Test du microservice
• Redis Enterprise managé DBaaS
  • Création d’une base Redis enterprise dans le cloud
  • Mise à jour des informations de connexion
  • Test hybride du microservice
  • Supervision Cloud
• Déploiement Google CloudRun
  • Création du service
  • Test final
• Supports et liens
• Notes de bas de page

Vidéo

Squelette Python et FastAPI

Environement de dev

D’abord, il faut créer un répertoire pour stocker les sources et un environnement de développement virtuel Python :

mkdir FastApiDemo
cd FastApiDemo
python3 -m venv venv
source venv/bin/activate
pip install fastapi
pip install uvicorn

Code de l’API

Ensuite, on peut commencer avec une liste d’objets stockée en mémoire, dans un tebleau, et deux points de connexion REST pour implémenter les lectures (GET) et les écritures (PUT) :

main.py :

# Modèle de données
#
from pydantic import BaseModel
from typing import Union
class User(BaseModel):
    name: str
    email: str
    age: int
    city: str
    height: float
    weight: float
    gender: Union[bool, None] = None

users = []

# Expose data access with a REST API provided by FastAPI
#
from fastapi import FastAPI
app = FastAPI()

# Interface de consultation
#
@app.get("/users/{user_id}")
def read_user(user_id: int):
    return users[user_id]

# Interface de modification
#
@app.put("/users/{user_id}")
def update_user(user_id: int, user: User):
    while (len(users)<=user_id):
        users.append("");
    users[user_id]=user
    return True

Test de l’API

Nous pouvons désormais démarrer le serveur uvicorn pour exposer les points de connexion de l’API.

uvicorn main:app --reload

Puis les tester grâce à curl en ligne de commande,

curl http://localhost:8000/users/1 --request GET --header 'content-type: application/json'
curl --request PUT --url "http://localhost:8000/users/1" --header 'content-type: application/json' --data '{"name":"Paul John","email":"paul.john@example.com","age":42,"city":"London","height":0,"weight":0,"gender":"True"}'
curl http://localhost:8000/users/1 --request GET --header 'content-type: application/json'
xdg-open http://localhost:8000/docs

puis grâce à l’interface wab de Swagger fournie par FastAPI sur l’URL http://localhost:8000/docs :

Base locale : Redis-Stack

Désormais, nous voulons utiliser une base Redis à la place du tableau d’objets en mémoire pour y stocker les enregistrements. Cela rendra notre microservice complètement « Stateless ».

Préparation

Nous commençons par démarrer une image dockerisée de Redis communautaire avec tous les modules officiels. Elle expose une base Redis sur le port standard $6379$ et un client graphique RedisInsight sur le port $8001$

docker run -p 6379:6379 -p 8001:8001 --name redis-stack redis/redis-stack

Il faut ensuite installer la bibliothèque cliente Redis pour Python dans l’environnement virtuel de développement et j’utilise des variables d’environnement pour transmettre les détails de connexion au microservice :

pip install "redis[hiredis]"
export REDISHOST=localhost
export REDISPORT=6379

Utilisation de Redis dans le code

Nous pouvons enfin modifier le code pour qu’il utilise Redis :

1. Retirer le tableau en mémoire
2. Inclure la bibliothèque cliente
3. Ouvrir une connexion sur la base Redis
4. Éventuellement pré-peupler la base avec des exemples
5. Utiliser Redis comme source pour le point de connexion en lecture (GET)
6. Utiliser Redis comme destination pour le point de connexion en écriture (PUT)

# Modèle de données
#
from pydantic import BaseModel
from typing import Union
class User(BaseModel):
    name: str
    email: str
    age: int
    city: str
    height: float
    weight: float
    gender: Union[bool, None] = None

# Bibliothèque cliente Redis et ouverture de la connexion
#
import redis
import os
r = redis.Redis(
        host=os.environ.get('REDISHOST'),
        port=os.environ.get('REDISPORT'),
        )

# Insertion de quelques enregistrements d'exemple
# JSON en utilisant le module éponyme dans Redis
#
from redis.commands.json.path import Path
r.json().set("user:1", Path.root_path(), { "name": "Paul John", "email": "paul.john@example.com", "age": 42, "city": "London" })
r.json().set("user:2", Path.root_path(), { "name": "Eden Zamir", "email": "eden.zamir@example.com", "age": 29, "city": "Tel Aviv" })
r.json().set("user:3", Path.root_path(), { "name": "Paul Zamir", "email": "paul.zamir@example.com", "age": 35, "city": "Tel Aviv" })

# Expose data access with a REST API provided by FastAPI
#
from fastapi import FastAPI
app = FastAPI()

# Point de connexion en consultation
#
@app.get("/users/{user_id}")
def read_user(user_id: int):
    return r.json().get("user:"+str(user_id))

# Point de connexion en modification
#
@app.put("/users/{user_id}")
def update_user(user_id: int, user: User):
    return r.json().set('user:'+str(user_id), Path.root_path(),
        { "name": user.name, "email": user.email, "age": user.age, "city": user.city, "height": user.height, "weight": user.weight, "gender": user.gender })

Test de l’API

Nous pouvons redémarrer le serveur d’application local :

uvicorn main:app --reload

et tenter de consulter les quatre premiers enregistrements :

for i in 1 2 3 4; do
  printf "\n%s: " "$i"
  curl http://localhost:8000/users/$i --request GET --header 'content-type: application/json'
done

Il n’y en a que trois, le quatrième n’existe pas et renvoie null

Créons le en ligne de commande :

curl --request PUT --url "http://localhost:8000/users/4" --header 'content-type: application/json' --data '{"name":"Francois Cerbelle","email":"francois@redis.com","age":48,"city":"Paris","height":179,"weight":84,"gender":"True"}'

Et vérifions dans l’interface de Swagger, par exemple :

Base locale : Redis Enterprise

Le but est d’utiliser un environnement de développement aussi proche que possible de l’environnement final de production. Remplaçons la base locale Redis communautaire par une base Redis Entreprise.

Installation rapide

Tout d’abord, nous pouvons démarrer une image docker de Redis Enterprise. J’expose les ports réseau pour l’interface d’administration web et pour l’API REST :

docker run -d --cap-add sys_resource --name redisenterprise1 -p 8443:8443 -p 9443:9443 redislabs/redis

Initialisation du cluster

Redis Entreprise fonctionne comme un orchestrateur et un gestionnaire de configuration pour des bases Redis, un peu comme Kubernetes pour des conteneurs. Nous devons donc commencer par initialiser le cluster Redis Enterprise avec un premier, et seul, nœud. Pour cela, il y a soit l’interface web : https://localhost:8443

xdg-open https://localhost:8443

Création du premier administrateur :

Choix du nom de cluster :

Configuration du nœud :

soit l’API REST :

curl "https://127.0.0.1:9443/v1/bootstrap/create_cluster" --insecure -X "POST" -H "Accept:application/json" -H "Content-Type:application/json" -u "francois@redis.com:password" -d '{"action": "create_cluster","cluster": { "name": "cluster.local" },"node": {"paths": {"persistent_path": "/var/opt/redislabs/persist","ephemeral_path": "/var/opt/redislabs/tmp","bigredis_storage_path": "/var/opt/redislabs/flash"}},"license": "","credentials": {"username": "francois@redis.com","password": "password"}}'

Création de la base

Nous pouvons ensuite décrire à Redis Enterprise la base Redis que nous souhaitons lui voir créer, superviser, maintenir et exposer avec les modules nécessaires à notre projet (JSON et Search). Nous utiliserons l’interface web, mais nous pourrions également utiliser l’API REST.

xdg-open https://localhost:8443

Nous pourrions utiliser l’API REST, mais nous utiliserons l’interface web pour récupérer les informations de connexion à la base, le nom ou l’IP, le port et éventuellement le mot de passe :

Utilisons les informations receuillies pour valoriser les variables d’environnement de notre microservice.

export REDISHOST=172.17.0.2
export REDISPORT=12581
export REDISPASS=xxx

Authentification depuis le code

Nous devons éventuellement modifier le code pour utiliser le mot de passe fourni par la variable d’environnement lors de la connexion à la base Redis :

# Modèle de données
#
from pydantic import BaseModel
from typing import Union
class User(BaseModel):
    name: str
    email: str
    age: int
    city: str
    height: float
    weight: float
    gender: Union[bool, None] = None

# Stockage des données dans Redis
#
import redis
import os
r = redis.Redis(
        host=os.environ.get('REDISHOST'),
        port=os.environ.get('REDISPORT'),
        password=os.environ.get('REDISPASS'),
        )

# Prépopulation de la base avec des enregistrements d'exemple
# en JSON
#
from redis.commands.json.path import Path
r.json().set("user:1", Path.root_path(), { "name": "Paul John", "email": "paul.john@example.com", "age": 42, "city": "London" })
r.json().set("user:2", Path.root_path(), { "name": "Eden Zamir", "email": "eden.zamir@example.com", "age": 29, "city": "Tel Aviv" })
r.json().set("user:3", Path.root_path(), { "name": "Paul Zamir", "email": "paul.zamir@example.com", "age": 35, "city": "Tel Aviv" })

# Expose data access with a REST API provided by FastAPI
#
from fastapi import FastAPI
app = FastAPI()

# Point de connexion pour les consultations
#
@app.get("/users/{user_id}")
def read_user(user_id: int):
    return r.json().get("user:"+str(user_id))

# Point de connexion pour les modifications
#
@app.put("/users/{user_id}")
def update_user(user_id: int, user: User):
    return r.json().set('user:'+str(user_id), Path.root_path(),
        { "name": user.name, "email": user.email, "age": user.age, "city": user.city, "height": user.height, "weight": user.weight, "gender": user.gender })

Test du microservice

Voilà le moment de tester la connexion de notre microservice à la base Redis fournie par Redis Enterprise. Redémarrons-le :

uvicorn main:app --reload

Nous pouvons utiliser le même scénario que précédemment, je ne vais pas le détailler une seconde fois :

for i in 1 2 3 4; do
  printf "\n%s: " "$i"
  curl http://localhost:8000/users/$i --request GET --header 'content-type: application/json'
done
curl --request PUT --url "http://localhost:8000/users/4" --header 'content-type: application/json' --data '{"name":"Francois Cerbelle","email":"francois@redis.com","age":48,"city":"Paris","height":179,"weight":84,"gender":"True"}'
xdg-open http://localhost:8000/docs

Dockerisation du microservice

Préparation

Listons les dépendences de notre microservice pour qu’elles soient disponibles dans le conteneur.

requirements.txt :

typing
pydantic
fastapi
uvicorn
redis

Spécifions la manière de construire le conteneur. Je me suis basé sur l’exemple fourni par Google CloudRun que j’ai modifié pour utiliser uvicorn à la place de gunicorn.

Dockerfile :

# From https://cloud.google.com/run/docs/quickstarts/build-and-deploy/python?hl=fr

# Use the official lightweight Python image.
# https://hub.docker.com/_/python
FROM python:3.10-slim

# Allow statements and log messages to immediately appear in the Knative logs
ENV PYTHONUNBUFFERED True

# Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./

# Install production dependencies.
RUN pip install --no-cache-dir -r requirements.txt

# Run the web service on container startup. Here we use the gunicorn
# webserver, with one worker process and 8 threads.
# For environments with multiple CPU cores, increase the number of workers
# to be equal to the cores available.
# Timeout is set to 0 to disable the timeouts of the workers to allow Cloud Run to handle instance scaling.
#CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app
CMD exec uvicorn --host 0.0.0.0 --port $PORT main:app

Il est inutile d’empaqueter certains fichiers temporaire ou de développement, listons les dans les exclusions.

.dockerignore :

Dockerfile
README.md
*.pyc
*.pyo
*.pyd
__pycache__
.pytest_cache

Construction du conteneur

L’étape de construction doit être assez rapide, quelques secondes, vu la simplicité de notre microservice.

docker build -t fastapi .

Exécution du microservice

La ligne de commande démarre le conteneur docker du microservice en précisant le port à utiliser par le serveur uvicorn, et le port forwarding associé pour rendre le serveur accessible depuis l’extérieur. Il est important de prévoir ce paramétrage qui sera indispensable pour le déploiement dans CloudRun par la suite. Le processus dans docker n’ayant pas accès directement aux variables d’environnement à l’extérieur, nous les passons en paramètre.

docker run --env PORT=8000 --env REDISHOST=$REDISHOST --env REDISPORT=$REDISPORT --env REDISPASS=$REDISPASS -p 8000:8000 --rm fastapi

Test du microservice

Le test de cette version dockerisée du microservice est strictement identique à celui de la version non dockerisée, c’est le but de ce tutoriel.

for i in 1 2 3 4; do
  printf "\n%s: " "$i"
  curl http://localhost:8000/users/$i --request GET --header 'content-type: application/json'
done
curl --request PUT --url "http://localhost:8000/users/4" --header 'content-type: application/json' --data '{"name":"Francois Cerbelle","email":"francois@redis.com","age":48,"city":"Paris","height":179,"weight":84,"gender":"True"}'
xdg-open http://localhost:8000/docs

Redis Enterprise managé DBaaS

La prochaine étape consiste à utiliser une véritable instance managée de Redis Enterprise dans le cloud, à partir de notre microservice dockerisé, qu’il soit sur notre poste de développement ou déployé dans CloudRun.

Création d’une base Redis enterprise dans le cloud

Il faut commencer par créer un compte sur le portail https://app.redislabs.com et s’y connecter.

Il faut ensuite créer une souscription, correspondant à un cluster, en choissant un plan (Fixed correspond à des configuration partagées pré-établies, Flexible correspond à des configurations sur mesure et Annual correspond à des configurations sur mesure négociées). Dans notre cas, je choisi Flexible.

Puis, il faut sélectionner le fournisseur Cloud dans lequel nous allons créer le service Redis. Notre microservice devant être déployé sur Google CloudRun, autant que le services Redis s’y trouve également. De même, choisissons la région la plus adaptée, (europe-west1 en ce qui me concerne). Enfin, nous devons lui donner un nom, ça pourrait être «Prod», «PreProd», par exemple.

Nous devons ensuite lister les bases Redis que cette souscription doit nous fournir, avec un nom, éventuellement un port réseau, les modules à activer (JSON et Search), le dimensionnement (volumétrie et débit), la haute-disponibilité ou non…

L’étape suivante permet de valider tous les détails avant de lancer la construction du service. Il est possible d’utiliser des crédits à travers les liens disponibles sur le site https://redis.com.

Le premier service va prendre environ 15 minutes à se déployer lors de sa création.

L’interface fournit des facilités pour se connecter à la base depuis l’intérieur (private) du fournisseur Cloud ou depuis l’extérieur (public), à l’aide d’exemples de code utilisant les bibliothèques clientes les plus communes, les outils en ligne de commande ou le client graphique RedisInsight

Mise à jour des informations de connexion

Nous pouvons désormais utiliser les nouvelles informations de connexion disponibles sur l’interface web Cloud (ou par appel d’API REST) pour mettre à jour les variables d’environnement utilisées par le microservice pour se connecter.

export REDISHOST=redis-16566.c29816.eu-west1-mz.gcp.cloud.rlcp.com
export REDISPORT=16566
export REDISPASS=

Test hybride du microservice

docker run --env PORT=8000 --env REDISHOST=$REDISHOST --env REDISPORT=$REDISPORT --env REDISPASS=$REDISPASS -p 8000:8000 --rm fastapi

Le test est presque devenu un automatisme et se répète exactement à l’identique, quelle que soit la configuration et l’architecture.

for i in 1 2 3 4; do
  printf "\n%s: " "$i"
  curl http://localhost:8000/users/$i --request GET --header 'content-type: application/json'
done
curl --request PUT --url "http://localhost:8000/users/4" --header 'content-type: application/json' --data '{"name":"Francois Cerbelle","email":"francois@redis.com","age":48,"city":"Paris","height":179,"weight":84,"gender":"True"}'
xdg-open http://localhost:8000/docs

Supervision Cloud

On peut constater sur la console de supervision Cloud que les trois clés initiales ont bien été créées lors du démarrage du microservice.

Ces clés sont bien visibles et consultables depuis RedisInsight en local connecté à la base DBaaS dans le Cloud.

Déploiement Google CloudRun

Enfin, nous disposons d’un service Redis managé dans le cloud (identique à un Redis local sur le poste de travail, identique à un Redis communautaire) et d’une API flexible conteneurisée pouvant être exécutée n’importe où pour se connecter à Redis. La dernière étape consiste à déployer le conteneur du microservice, à le faire exécuter et à l’exposer dans Google CloudRun.

Création du service

Bien que nous puissions créer une image docker et l’enregistrer dans le dépôt d’artefacts Google pour l’utiliser depuis un service CloudRun, dans mon cas, je vais pousser les sources de mon microservice vers Google pour que Google construise l’image docker tout seul la stocke dans l’ «artefact repository» et l’utilise pour démarrer un nouveau service CloudRun…. J’ai uniquement besoin de fournir les paramètres de connexion à Redis et le port que je souhaite exposer.

gcloud run deploy --source . --allow-unauthenticated --port=8080 --service-account=319143195410-compute@developer.gserviceaccount.com --min-instances=1 --set-env-vars=REDISHOST=$REDISHOST,REDISPORT=$REDISPORT,REDISPASS=$REDISPASS --cpu-boost --region=europe-west1 --project=central-beach-194106

On peut constater au bout de quelques dizaines de secondes que le service a bien été déployé à partir d’une image construite à la volée par Google.

Test final

On peut constater que l’interface Swagger est bien disponible sur l’url fournie par le service CloudRun.

Les nouveau enregistrements se stockent bien dans la base Redis managée sur GCP.

Supports et liens

• Demo video ¹

Notes de bas de page

Vous pouvez trouver des liens vers les enregistrements vidéo et les supports imprimables associés à la fin de cet article.

• Vidéo
• Prérequis
• Opérateur Redis Enterprise
  • Récupération des fichiers modèles
  • Création d’un espace de nommage
  • Déploiement de l’opérateur
  • Activation du controleur d’admission
• Déploiement de Redis Enterprise
  • Création du cluster
  • Création d’une base de données
  • Modification d’une base
  • Suppression d’une base
  • Démarrage d’un pod de benchmark
• Supervision
  • Déploiement et intégration de Prometheus
  • Déploiement et intégration de Grafana
• Déploiement d’une application
  • Redisbank
• Supports et liens
• Notes de bas de page

Vidéo

Les étapes sont inspirées de la documentation officielle¹, à la date du 27/01/2023.

Prérequis

Il faut disposer d’un cluster Azure Kubernetes Services (AKS) dans Azure. La création de ce cluster est visible dans la vidéo accompagnant cet article.

Opérateur Redis Enterprise

Récupération des fichiers modèles

Commençons par récupérer les fichiers d’exemples depuis le dépôt GitHub² pour éviter de devoir les resaisir.

git clone https://github.com/RedisLabs/redis-enterprise-k8s-docs.git

Création d’un espace de nommage

Nous allons déployer Redis Enterprise dans un espace de nommage. Cet espace peut être dédié exclusivement à un cluster Redis Enterprise ou bien être celui d’une application. Il ne peut y avoir qu’un seul cluster Redis Enterprise par namespace, en revanche, il peut y avoir plusieurs namespaces avec un cluster dans chacun. Enfin, les bases crées et hébergées dans un cluster, dans un namespace peuvent être exposées et accessibles depuis d’autres namespaces.

kubectl create namespace redisns

Comme nous allons principalement travailler dans ce namespace, nous le configurons comme namespace par défaut dans notre contexte.

kubectl config set-context --current --namespace=redisns

Déploiement de l’opérateur

Tout d’abord, nous devons identifier la dernière version disponible afin de l’installer.

VERSION=`curl --silent https://api.github.com/repos/RedisLabs/redis-enterprise-k8s-docs/releases/latest | grep tag_name | awk -F'"' '{print $4}'`

Ensuite, nous pouvons demander à kubernetes d’installer cette version de l’opérateur directement depuis l’URL.

kubectl apply -f https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/$VERSION/bundle.yaml

Enfin, nous pouvons vérifier le bon déroulement de l’installation.

kubectl get deployment redis-enterprise-operator

Activation du controleur d’admission

L’opérateur utilise les fichiers de description, les CRDs, comme configuration à mettre en place et à maintenir. Les fichiers CRD sont au format YAML et suivent une syntaxe stricte. Le controleur d’admission a pour tâche de vérifier la validité syntaxique de ces fichiers et leur cohérence par rapport au contexte actuel du cluster, pour refuser tout changement qui serait impossible à réaliser. Cela permet d’éviter de casser une configuration qui fonctionne. Il faut récupérer le certificat auto-signé généré à la création du cluster depuis un des secrets K8S pour le faire prendre en compte par le pod d’admission grâce à un modèle de fichier YAML.

kubectl get secret admission-tls
CERT=`kubectl get secret admission-tls -o jsonpath='{.data.cert}'`
sed 's/NAMESPACE_OF_SERVICE_ACCOUNT/redisns/g' admission/webhook.yaml | kubectl create -f -
cat > modified-webhook.yaml <<EOF
webhooks:
- name: redb.admission.redislabs
  clientConfig:
    caBundle: $CERT
  admissionReviewVersions: ["v1beta1"]
EOF
kubectl patch ValidatingWebhookConfiguration redb-admission --patch "$(cat modified-webhook.yaml)"

Par défaut, le controleur d’admission surveille les CRDs de tous les espaces de nommage. On peut le restreindre à certain espaces de nommage, mais je ne le ferai pas dans cet article.

Déploiement de Redis Enterprise

Création du cluster

Nous allons demander à l’opérateur d’effectuer les opérations nécessaires pour atteindre et maintenir la configuration décrite dans un fichier CRD de description de cluster. Nous allons indiquer le nombre de nœuds du cluster, la quantité de RAM et de CPU souhaitée pour chaque nœud et donner un nom à ce cluster. Nous choisissons 3 nœuds, ce qui est le minimum pour avoir la haute-disponibilité et le minimum géré par l’opérateur. Nous indiquons que nous voulons que chaque nœud dispose de 10Go de RAM. Cette configuration est inférieure aux préconisations officielles de production mais fera l’affaire pour la démonstration.

cat <<EOF | kubectl apply -f -
apiVersion: "app.redislabs.com/v1"
kind: "RedisEnterpriseCluster"
metadata:
  name: my-rec
spec:
  nodes: 3
  redisEnterpriseNodeResources:
    limits:
      cpu: 2000m
      memory: 10Gi
    requests:
      cpu: 2000m
      memory: 10Gi
EOF

L’opérateur constate la présence d’un changement de configuration souhaitée dans le fichier CRD et va tenter de l’appliquer. Nous pouvons vérifier la configuration des clusters Redis Enterprise (REC, Redis Enterprise Clusters).

kubectl get rec

Ensuite, nous attendons que tous les pods soient créés, initialisés par un premier container et éxécutant un second container.

kubectl rollout status sts/my-rec

Finallement, il est possible de vérifier le déploiement complet :

kubectl get all

Le cluster Redis Enterprise dispose d’une interface web d’administration. Si nous n’avons pas défini d’informations de connexion (identifiant et mot de passe), l’opérateur en a créé pour nous dans des secrets Kubernetes. Nous allons donc les récupérer pour nous connecter à l’interface web :

kubectl get secret
kubectl get secret/my-rec -o jsonpath='{.data.password}' | base64 --decode
kubectl get secret/my-rec -o jsonpath='{.data.username}' | base64 --decode
kubectl port-forward service/my-rec-ui 8443:8443

La dernière commande permet d’exposer le service d’administration web depuis le cluster Kubernetes vers notre poste de travail pour nous y connecter avec un navigateur sur l’URL https://localhost:8443

Création d’une base de données

Nous pouvons ensuite décrire la base que nous souhaitons dans un fichier de description CRD. La plupart des options de configuration d’une base sont disponibles et disposent de valeurs par défaut. Je me contente d’indiquer :

• le nom de la base
• l’occupation maximale de la base en RAM
• le mode de persistance
• le nombre de shards maitres
• la réplication pour la haute-disponibilité
• le nom du cluster dans lequel je souhaite disposer de la base

  cat << EOF | kubectl apply -f -
  apiVersion: app.redislabs.com/v1alpha1
  kind: RedisEnterpriseDatabase
  metadata:
  name: smalldb
  spec:
  memorySize: 100MB
  persistence: "aofEverySecond"
  shardCount: 2
  replication: true
  redisEnterpriseCluster:
    name: my-rec
  EOF
  

  On peut utiliser la commande suivante pour vérifier la disponibilité de la base :

  kubectl get redb smalldb -o jsonpath="{.status.status}"
  

  Dès que la base est disponible, elle est visible dans l’interface web d’administration et l’opérateur créée automatiquement un service Kubernetes dans l’espace de nommage d’utilisation de la base, celui de l’application qui va l’utiliser (que je n’ai pas spécifié ici).

  kubectl get redb
  kubectl get svc
  

  Si aucune information n’a été prérenseignée, l’opérateur créée automatiquement un nom interne, choisit un port au hasard, créée un mot de passe généré et un nom de service à exposer. Toutes ces informations peuvent facilement être retrouvées dans Kubernetes.

  kubectl get redb smalldb -o jsonpath="{.spec.databaseSecretName}"
  kubectl get secret/redb-smalldb -o jsonpath='{.data.password}' | base64 --decode
  kubectl get secret/redb-smalldb -o jsonpath='{.data.port}' | base64 --decode
  kubectl get secret/redb-smalldb -o jsonpath='{.data.service_name}' | base64 --decode
  

Modification d’une base

Maintenant que la base de données est créée, il est possible d’en changer la configuration. On peut le faire de différente manière :

• Accéder à l’interface web et modifier la configuration : ne jamais faire comme ça, les modification ne seraient pas dans le fichier CRD de description et l’opérateur chercherait à revenir à la configuration décrite.
• Par kubectl apply, automatisable, sans interraction
• Par kubectl edit, interractive Voici la commande interractive, à titre d’exemple. Je n’illustrerai pas plus la modification de la configuration des bases ici.

  kubectl edit redb smalldb
  

Suppression d’une base

Il est évidemment possible de supprimer une base de données à l’aide de la commande suivante. Je ne la supprime pas tout de suite car je vais en avoir besoin dans les étapes suivantes.

kubectl delete redb smalldb

Démarrage d’un pod de benchmark

Nous pouvons maintenant démarrer un nouveau pod avec un conteneur de benchmark, tel que memtier_benchmark. Nous aurons besoin des informations de connexion à la base pour les transmettre à l’outil. Nous verrons plus loin comment industrialiser cette récupération, mais pour ce premier exemple, je les récupère dans des variables d’environnement locales.

DBNAME='smalldb'
DBSECNAME=`kubectl get redb "${DBNAME}" -o jsonpath="{.spec.databaseSecretName}"`
SVCNAME=`kubectl get secret/${DBSECNAME} -o jsonpath='{.data.service_name}' | base64 --decode`
SVCPORT=`kubectl get secret/${DBSECNAME} -o jsonpath='{.data.port}' | base64 --decode`
SVCPASS=`kubectl get secret/${DBSECNAME} -o jsonpath='{.data.password}' | base64 --decode`

et je les passe à l’application en ligne de commande. Il ne faut pas faire cela en production, car les informations apparaissent en clair si on affiche la liste des processus (ps -aux).

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: memtier
spec:
  containers:
  - name: memtier
    image: redislabs/memtier_benchmark:latest
    args: ["--key-prefix=a","--ratio=1:4","--test-time=120","-d","100","-t","2","-c","25","--pipeline=50","--key-pattern=S:S","--hide-histogram","-x","1000","-s","${SVCNAME}.redisns.svc","-p","${SVCPORT}","-a","${SVCPASS}"]
EOF

kubectl logs memtier

Supervision

Déploiement et intégration de Prometheus

Redis-Enterprise expose de nombreuses métriques concernant le cluster, les nœuds, les bases et les shards sous la forme d’un exporteur au format Prometheus pour que ce dernier puisse les collecter, les stocker et les représenter ou les servir à Grafana. On peut aussi utiliser Prometheus-Alertmanager pour superviser et déclencher des alertes.

Je ne vais pas couvrir un déploiement complet de prometheus, dans les règles de l’art ou avec son opérateur. On peut trouver de nombreux articles qui le font très bien, par exemple phoenixnap³ ou devopscube⁴.

L’opérateur a automatiquement créé des services Kubernetes pour exposer le point de connexion de l’exporteur au format Prometheus du cluster Redis Enterprise. Si vous n’avez pas installé de certificats personnalisés, l’opérateur a automatiquement créé des certificats auto-signés et ils faudra donc penser à l’option tls_config pour que prometheus puisse accéder à l’exporteur.

Prometheus dispose aussi d’un opérateur permettant la découverte et l’ajout automatique de sources à partir d’annotation ou de labels. Je ne couvre pas cette installation complète de Prometheus. Je ne fais qu’une installation basique pour illustrer la collecte des metriques du cluster, des nœuds, des bases et des shards Redis Enterprise.

Il faut inclure dans le fichier de configuration de prometheus une référence au nom du service prometheus du cluster. Ce nom est composé du nom du cluster postfixé par -prom :

    scrape_configs:
      - job_name: 'myrec'
        scheme: https
        static_configs:
        - targets: ['my-rec-prom.redisns.svc:8070']
        tls_config:
          insecure_skip_verify: true

Commençons par créer un espace de nommage spécifique pour la supervision monitoring, dans lequel nous allons déployer Prometheus.

kubectl create namespace monitoring

Prometheus aurait théoriquement besoin de permissions pour accéder aux métriques exposées par Kubernetes. Bien que nous ne nous y intéressons pas, je vais quand même créer un compte de service, un role de cluster et une association entre ce compte et le role :

cat << EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]
EOF

cat << EOF | kubectl create -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: monitoring
EOF

cat << EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: monitoring
EOF

Ensuite, j’externalise le fichier de configuration de Prometheus à l’extérieur de son pod, dans une ConfigMap. C’est dans ce fichier de configuration qu’il faut inclure la définition du service Redis-Prometheus.

cat << EOF | kubectl create -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    global:
      scrape_interval:     15s
      evaluation_interval: 15s
    alerting:
      alertmanagers:
      - static_configs:
        - targets:
    rule_files:
      # - "example-file.yml"
    scrape_configs:
      - job_name: 'prometheus'
        static_configs:
        - targets: ['localhost:9090']
      - job_name: 'myrec'
        scheme: https
        static_configs:
        - targets: ['my-rec-prom.redisns.svc:8070']
        tls_config:
          insecure_skip_verify: true
EOF

Je déploie un pod Prometheus. Dans le cadre de ce tutoriel, je ne configure pas de volume persistent. Prometheus perdra donc sa base si le pod redémarre. Autrement, il faudrait inclure une demande de persistance dans la configuration :

      - name: prometheus-storage-volume
        persistentVolumeClaim:
            claimName: pvc-nfs-data

cat << EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
  labels:
    app: prometheus
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9090"
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus
        args:
          - '--storage.tsdb.retention=6h'
          - '--storage.tsdb.path=/prometheus'
          - '--config.file=/etc/prometheus/prometheus.yml'
        ports:
        - name: web
          containerPort: 9090
        volumeMounts:
        - name: prometheus-config-volume
          mountPath: /etc/prometheus
        - name: prometheus-storage-volume
          mountPath: /prometheus
      restartPolicy: Always
      volumes:
      - name: prometheus-config-volume
        configMap:
            defaultMode: 420
            name: prometheus-config
      - name: prometheus-storage-volume
        emptyDir: {}
EOF

Je termine en exposant prometheus sous la forme d’un service Kubernetes pour pouvoir le manipuler plus facilement ensuite. J’ai fait le choix d’un service NodePort, dans la pratique, en production, on préfère parfois un LoadBalancer mais je voulais limiter les dépendances à la configuration Kubernetes du fournisseur :

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
    name: prometheus-service
    namespace: monitoring
    annotations:
        prometheus.io/scrape: 'true'
        prometheus.io/port:   '9090'

spec:
    selector:
        app: prometheus
    type: NodePort
    ports:
    - port: 8080
      targetPort: 9090 
      nodePort: 30909
EOF

Enfin, je connecte le service Prometheus du cluster à un port sur mon poste de travail pour m’y connecter depuis mon navigateur local http://localhost:8080 . Cette commande est blocante.

kubectl port-forward service/prometheus-service 9090:8080 -n monitoring

Déploiement et intégration de Grafana

Redis fournit des tableaux de bord Grafana prêts à l’emploi pour représenter et exploiter les métriques stockées dans Prometheus.

Tous comme pour Prometheus, mon but n’est pas de faire un tutoriel d’installation de Grafana sur Kubernetes dans les règles de l’art. Je me base donc sur l’article de blog de devopscube⁵.

Dans le même esprit que pour Prometheus, j’externalise la configuration de Grafana dans une ConfigMap pour ne pas la maintenir à l’intérieur des pods Grafana :

cat << EOF | kubectl create -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-datasources
  namespace: monitoring
data:
  prometheus.yaml: |-
    {
        "apiVersion": 1,
        "datasources": [
            {
               "access":"proxy",
                "editable": true,
                "name": "prometheus",
                "orgId": 1,
                "type": "prometheus",
                "url": "http://prometheus-service.monitoring.svc:8080",
                "version": 1
            }
        ]
    }
EOF

Tout comme pour Prometheus, je déploie Grafana, sans PersistentVolume, les pods perdent donc leurs données et les tableaux de bord configurés quand ils sont arrêtés :

cat << EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      name: grafana
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:latest
        ports:
        - name: grafana
          containerPort: 3000
        resources:
          limits:
            memory: "1Gi"
            cpu: "1000m"
          requests: 
            memory: 500M
            cpu: "500m"
        volumeMounts:
          - mountPath: /var/lib/grafana
            name: grafana-storage
          - mountPath: /etc/grafana/provisioning/datasources
            name: grafana-datasources
            readOnly: false
      volumes:
        - name: grafana-storage
          emptyDir: {}
        - name: grafana-datasources
          configMap:
              defaultMode: 420
              name: grafana-datasources
EOF

J’expose Grafana en tant que Service Kubernetes pour le manipuler plus facilement :

cat << EOF | kubectl create -f -
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: monitoring
  annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/port:   '3000'
spec:
  selector: 
    app: grafana
  type: NodePort  
  ports:
    - port: 3000
      targetPort: 3000
      nodePort: 32000
EOF

Et, finalement, je connecte le service Grafana depuis le cluster Kubernetes vers mon poste de travail pour y connecter mon navigateur. Cette commande est blocante :

kubectl port-forward service/grafana 3000 -n monitoring

Je peux me connecter à Grafana par l’URL http://localhost:3000 , l’identifiant par défaut est admin, le mot de passe aussi. À partir de là, je peux copier-coller le code source des trois tableaux de bord Redis pour Grafana au format JSON, disponibles depuis la page Prometheus integration⁶

Déploiement d’une application

Nous avons créé une base de test et y avons connecté manuellement une application de benchmark. Nous allons maintenant voir comment créer une base à valeur ajoutée avec des modules et une application connectée automatiquement sans passer les informations en ligne de commande.

J’ai créé un compte (fcerbell) et un dépôt (repository redisbank) sur DockerHub⁷ pour y publier l’image compilée de l’application, le temps de ce tutoriel.

Commençons par supprimer la base de test, si elle existe toujours. Redis Enterprise est multi-tenant et peut héberger autant de base de données Redis que souhaité, dans la limite des ressources matérielles mises à sa disposition et de ce qu’autorise la licence déployée. La license Redis Enterprise d’évaluation n’inclue pas d’assez de shards pour disposer de ces deux bases simultanément avec leur dimensionnement.

kubectl delete redb smalldb

Redisbank

J’ai choisi une application très simple. Il s’agit d’une application monolithique en Java, utilisant le framework Spring et Spring-Data-Redis. Je commence par récupérer le code source de l’application depuis le dépôt GitHub⁸

git clone https://github.com/fcerbell/redisbank
cd redisbank/

Je compile l’image en l’étiquettant avec le nom de mon dépôt sur Docker Hub, je me connecte au dépôt et j’y envoie l’image compilée pour qu’elle soit disponible en téléchargement libre depuis un dépôt d’images, pour Kubernetes :

docker build -t fcerbell/redisbank .
docker login
docker push fcerbell/redisbank:latest

Je peux créer une base pour l’application. Cette base est dimensionnée sur un seul shard, et n’utilisera qu’un cœur au plus, elle est répliquée, donc hautement disponible, elle utilisera un second shard de réplication. Elle n’occupera pas plus de 1Go de RAM, soit 500Mo pour les données et 500Mo pour le réplica. Mais sa véritable particularité est de charger deux modules d’extension utilisés par l’application. Avec Redis-Enterprise, il suffit de les spécifier, charge au cluster de les trouver, de les déployer sur les nœuds où tourneront les shards et de les faire charger par les shards.

• RedisSearch est un moteur d’indexation automatique en temps réel et sans maintenance. Il permet de répondre à des requêtes de Full-Text Search (FTS), avec tokenisation, stemming, stop-words, langages, recherches floues ou approximatives, recherches phonetiques, scoring, … Mais aussi à des requêtes d’auto-complétion, des requêtes complexes avec agrégation, filtrage, ….
• Redis Timeseries permet de stocker des séries temporelles dans une structure adaptée, avec la possibilité de faire des agrégation automatique graduelles dans le temps. ```bash cat « EOF | kubectl apply -f - apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseDatabase metadata: name: redis-enterprise-database spec: memorySize: 1G shardCount: 1 replication: true modulesList:
  • name: “search” version: “2.4.16”
  • name: “timeseries” version: “1.6.17” EOF ```

Une fois la base créée, je peux déployer l’application dans un petit pod. Cette application utilise SpringData-Redis pour se connecter à Redis. Ce framework utilise un fichier de configuration pour y trouver les informations de connexion : application.yaml. En le consultant, on voit qu’il utilise des variables d’environnement pour initialiser ces informations, si elles sont disponibles :

# Properties for running on localhost are the default
# Environment variables will be used when set
# Use these on your deployment environment of choice
stomp.host=${STOMP_HOST:localhost}
stomp.protocol=${STOMP_PROTOCOL:ws}
stomp.port=${STOMP_PORT:8080}
spring.redis.host=${REDIS_HOST:localhost}
spring.redis.port=${REDIS_PORT:6379}
spring.redis.password=${REDIS_PASSWORD:}

# Global properties
stomp.endpoint=/websocket
stomp.destinationPrefix=/topic
stomp.transactionsTopic=/topic/transactions
management.endpoints.web.exposure.include=env
spring.session.store-type=redis
spring.session.redis.namespace={lars:}spring:session

Il suffit donc d’indiquer à Kubernetes de recopier les informations de connexion depuis le Secret dans des variables d’environnement de la session exécutant l’application dans le conteneur du pod. Non seulement ces information sensibles ne transitent pas par le réseau ou par mon poste de travail, elle n’apparaissent pas dans la liste des processus, mais en plus, cette configuration est portable à travers les environnements de déploiement (Dev, Recette, Intégration, PréProd, Prod…).

cat << EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redisbank-deployment
spec:
  selector:
    matchLabels:
      app: redisbank
  replicas: 1
  template:
    metadata:
      labels:
        app: redisbank
    spec:
      containers:
      - name: redisbank
        image: fcerbell/redisbank:latest
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        ports:
        - name: redisbank
          containerPort: 8080
        env:                        ## Set app environment variables from REDB secrets
        - name: SPRING_REDIS_HOST
          valueFrom:
            secretKeyRef:
              name: redb-redis-enterprise-database
              key: service_name
        - name: SPRING_REDIS_PORT
          valueFrom:
            secretKeyRef:
              name: redb-redis-enterprise-database
              key: port
        - name: SPRING_REDIS_PASSWORD
          valueFrom:
            secretKeyRef:
              name: redb-redis-enterprise-database
              key: password
EOF

Comme d’habitude, je crée un service Kubernetes pour manipuler l’interface web de l’application

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: redisbank
  labels:
    app: redisbank
spec:
  ports:
  - port: 8081
    targetPort: 8080
    nodePort: 30080
    name: redisbank
  selector:
    app: redisbank
  type: NodePort
EOF

Et je connecte ce service à un port de ma machine locale pour y connecter mon navigateur :

kubectl port-forward service/redisbank 8081

http://localhost:8081

Supports et liens

Notes de bas de page

You can find links to the related video recordings and printable materials at the end of this post.

• Explanation and demo video
• Prepare the environment
• Prerequisites
• A security and compliance issue
• Simple Redis ACLs limits
• Implementing roles with Redis Enterprise
  • Create databases
  • Create the accounts
  • Create the ACL
  • Create the roles
  • Map ACLs to roles in each database
  • Disable default anonymous account
  • Assign a roles to each account
• Permissions tests
• Permissions maintenance
  • A new employee joins
  • A developer switches to another team
  • An employee leaves
  • Access to new structures
• Wrap-up and LDAP
• Materials and Links
• Footnotes

Explanation and demo video

Prepare the environment

You can use official Redis Enterprise docker containers from docker hub to reproduce the demonstration or practice.

# Start Redis Enterprise
docker run -d --cap-add sys_resource --name redisenterprise -p 8443:8443 -p 9443:9443 -p 12000:12000 -p 12001:12001 -p 12002:12002 redislabs/redis
sleep 20

# Initialize the Cluster
docker exec -d --privileged redisenterprise "/opt/redislabs/bin/rladmin" cluster create name cluster.local username francois@redislabs.com password password
sleep 15

Prerequisites

This contents assume that you already know what are Redis ACL. If you did you watch it previously, I recommend that you watch the How to manage security, data-access and permissions with Redis ACL contents before this one. If you want to reproduce the following steps by yourself, you need to install docker, curl and jq. The commands are not purely POSIX shell compliant and need some bash extensions.

A security and compliance issue

Redis is used in nearly every company in the world. The data access control is critical to ensure the data security and to respect the compliance rules such as GDPR. Each incoming connection needs to be authenticated and potentially granted permissions on available databases, commands and data.

Lets imagine that you have three databases :

• an orders database to store orders and order lines ;
• a products database to store the product catalog and the product availability in stocks ;
• a messaging database used as a message bus to communicate between all microservices with Redis PubSub.

Two microservices, each with two endpoints :

• One microservice to manage orders in the orders database, with : the orders-update endpoint to create and update orders (read-write), and the orders-invoice endpoint to generate invoices (read-only), they also need a read-write and read-only access to the messaging database.
• The other microservice to manage the product catalog with two endpoints, products-update to update products and products-stocks to check a product availability. They also need a read-write and a read-only access to the messaging database.

There are also people :

• one administrator, Angélina who should not access the data
• two project managers, Paul for the orders management, and Pierre for the product catalog. They need to access the logs, the database configuration, the monitoring and to change their projects data. They also need a read-write access to the message bus, the messaging database.
• one developer David, working on the orders project microservice only, and one developer Denis, working on the products project microservice only. Each of them need a limited access to the monitoring, a read-only access to their own database only and a subscribe-only (read-only) access to the messages in the messaging database.

This is a fairly simple example compared to real enterprise needs. The permissions are easy to implement, but not to scale if you have several projects, several profiles such as developers, managers, architects, administrators, and several databases. Security with ACL administration quickly becomes a nightmare and needs to be industrialized and automated. Lets see how Redis Enterprise manage this example.

Simple Redis ACLs limits

Despite Redis is widely known and used by developers as a database, the security belongs to Ops who are not always aware of the security features. Since version 6, Redis includes authentication by username and data access authorizations with Access Control Lists (ACL).

Ok, lets have a look at their needed permissions, on the cluster and databases. We will potentially need to create the users in each database.

You would have to connect to each database, create all the accounts with a password, then to create the ACLs individually. If a project has any change, it needs to change the ACL definitions for all the relevant users in each database, individually. What a pain to maintain when a new developer join or leave one or several projects, when new projects are created, when projects need access to different datastructures … Let’s try to factorize these.

Implementing roles with Redis Enterprise

On top of ACLs, Redis Enterprise implemented TLS mutual authentication and Roles Based Access Control (RBAC) to make the ACL management more efficient and more scalable with multiple databases. What are the best practices on how to implement authentication, ACLs and roles in Redis Enterprise, and what can be easily achieved with them ?

Redis Enterprise Roles can be compared to groups or profiles. A role grants permissions globally on the Redis enterprise cluster administration and apply specific ACLs on each database. It automatically creates the accounts, configure the ACL and maintain everything up-to-date in each relevant database.

Create databases

You can create them with the web admin interface

or with the REST API

function DBCreate {
  dbname='"name":"'"$1"'",'
  dbsize='"memory_size":'"${2:-102400}"','
  dbcfg="$3"
  curl -k -u "francois@redislabs.com:password" --request POST --url "https://localhost:9443/v1/bdbs" --header 'content-type: application/json' --data '{
    '${dbname}'
    '${dbsize}'
    '${dbcfg}'
  }';
}
function DBFindUidByName {
  dbname="$1"
  # Find the DB UID by name
  dbid=`curl -s -k -u "francois@redislabs.com:password" --request GET --url "https://localhost:9443/v1/bdbs" --header 'content-type: application/json' | jq '.[]|select(.name=="'${dbname}'").uid'`
  echo $dbid
}

function DBUpdate {
  dbname="$1"
  config="$2"
  dbid=`DBFindUidByName "${dbname}"`
  # Update the DB configuration
  curl -k -u "francois@redislabs.com:password" --request PUT --url "https://localhost:9443/v1/bdbs/${dbid}" --header 'content-type: application/json' --data '{
    '"${config}"'
  }';
}

function DBDelete {
  dbname="$1"
  dbid=`DBFindUidByName "${dbname}"`
  # Delete the database
  curl -k -u "francois@redislabs.com:password" --request DELETE --url "https://localhost:9443/v1/bdbs/${dbid}" --header 'content-type: application/json'
}

DBCreate orders 102400 '"port":12000'
DBCreate products 102400 '"port":12001'
DBCreate messaging 102400 '"port":12002'

The final result is the same and all the databases are successfully created :

Create the accounts

Then, we need to create all the accounts for the endpoints and for the users. We create them in the cluster and the cluster will automatically maintain a copy of them in the relevant databases.

The accounts can be created with the web interface

Or with the REST API, to industrialize the creation and automate it.

function UserCreate {
  username='"name":"'$1'",'
  useremail='"email":"'$2'",'
  userpass='"password":"'${3:-$1}'",'
  curl -k -u "francois@redislabs.com:password" --request POST --url "https://localhost:9443/v1/users" --header 'content-type: application/json' --data '{
     '${username}'
     '${useremail}'
     '${userpass}'
     "role": "none"
  }'
}

function UserFindUidByName {
  username="$1"
  # Find Account UID by name
  uuid=`curl -s -k -u "francois@redislabs.com:password" --request GET --url "https://localhost:9443/v1/users" --header 'content-type: application/json' | jq '.[]|select(.name=="'${username}'").uid'`
  echo ${uuid}
}

function UserUpdate {
  username="$1"
  usercfg="$2"
  uuid=`UserFindUidByName "${username}"`
  curl -k -u "francois@redislabs.com:password" --request PUT --url "https://localhost:9443/v1/users/${uuid}" --header 'content-type: application/json' --data '{'"${usercfg}"'}'
}

function UserDelete {
  username="$1"
  uuid=`UserFindUidByName "${username}"`
  curl -k -u "francois@redislabs.com:password" --request DELETE --url "https://localhost:9443/v1/users/${uuid}" --header 'content-type: application/json'
}


# Users
for u in orders-update orders-invoice products-update products-stocks Angelina Paul Pierre David Denis; do
  UserCreate "${u}" "${u}@example.org" "${u}"
done

At the end, the result is the same and all the accounts are created in the cluster :

Create the ACL

We have to define these ACLs in the cluster. They will be some sort of ACL templates to apply tu users in specific databases, depending on the granted roles. So, we need to find all the possible ACL to apply and define them in the cluster. We can easily identify five distinct ACL : read-write access or read-only access to data, publish-subscribe or subscribe-only access to channels, and database administration.

The ACLs can be created with the web administration interface

or with REST API calls. I wrote a bash function helper to make them more friendly.

function ACLCreate {
  aclname="$1"
  acltext="$2"
  curl -k -u "francois@redislabs.com:password" --request POST --url "https://localhost:9443/v1/redis_acls" --header 'content-type: application/json' --data '{"name": "'"${aclname}"'", "acl": "'"${acltext}"'" }' 
}

function ACLFindUidByName {
  aclname="$1"
  # Find ACL UID by name
  uuid=`curl -s -k -u "francois@redislabs.com:password" --request GET --url "https://localhost:9443/v1/redis_acls" --header 'content-type: application/json' | jq '.[]|select(.name=="'"${aclname}"'").uid'`
  echo ${uuid}
}

function ACLUpdate {
  aclname="$1"
  acltext="$2"
  acluid=`ACLFindUidByName "${aclname}"`
  curl -k -u "francois@redislabs.com:password" --request PUT --url "https://localhost:9443/v1/redis_acls/${acluid}" --header 'content-type: application/json' --data '{"acl":"'"${acltext}"'"}'
}

function ACLDelete {
  aclname="$1"
  acluid=`ACLFindUidByName "${aclname}"`
  curl -k -u "francois@redislabs.com:password" --request DELETE --url "https://localhost:9443/v1/redis_acls/${acluid}" --header 'content-type: application/json'
}

ACLCreate "DataRW"  '-@all +@hash +@list -@dangerous ~*'
ACLCreate "DataRO"  '-@all +@hash +@list -@dangerous -@write ~*'
ACLCreate "MsgRW"   '-@all +publish +subscribe -@dangerous ~*'
ACLCreate "MsgRO"   '-@all +subscribe -@dangerous ~*'
ACLCreate "DBAdmin" '-@all +@admin +@dangerous'

Create the roles

With these definitions, we can more easily see patterns :

The Redis Enterprise cluster can grant cluster permissions to roles and each Redis Enterprise database can grant specific ACLs to a role. The idea is to create a distinct role per unique permission set, each unique line in the table. Thus, for our simple case, we need to create nine roles, one for each possible combination. A role is an account profile or an account group with the same permissions on the cluster and on the databases.

The cluster permissions are directly and globally assigned to the role, let’s create them with the web administration interface first

And then with the REST API and an helper function

function RoleCreate {
  rolename="$1"
  roleperm="$2"
  curl -k -u "francois@redislabs.com:password" --request POST --url "https://localhost:9443/v1/roles" --header 'content-type: application/json' --data '{"name": "'"${rolename}"'", "management": "'"${roleperm}"'" }'  
}

function RoleFindUidByName {
  rolename="$1"
  # Find Role UID by name
  ruid=`curl -s -k -u "francois@redislabs.com:password" --request GET --url "https://localhost:9443/v1/roles" --header 'content-type: application/json' | jq '.[]|select(.name=="'"${rolename}"'").uid'`
  echo ${ruid}
}

function RoleUpdate {
  rolename="$1"
  roleperm="$2"
  roleuid=`RoleFindUidByName "${rolename}"`
  curl -k -u "francois@redislabs.com:password" --request PUT --url "https://localhost:9443/v1/roles/${roleuid}" --header 'content-type: application/json' --data '{"management":"'"${roleperm}"'"}'
}

function RoleDelete {
  rolename="$1"
  roleuid=`RoleFindUidByName "${rolename}"`
  curl -k -u "francois@redislabs.com:password" --request DELETE --url "https://localhost:9443/v1/roles/${roleuid}" --header 'content-type: application/json'
}

RoleCreate "Orders-RW"    "none"
RoleCreate "Orders-RO"    "none"
RoleCreate "Products-RW"  "none"
RoleCreate "Products-RO"  "none"
RoleCreate "Global-ADM"   "admin"
RoleCreate "Orders-PM"    "db_member"
RoleCreate "Products-PM"  "db_member"
RoleCreate "Orders-DEV"   "db_viewer"
RoleCreate "Products-DEV" "db_viewer"

Map ACLs to roles in each database

Then, in each database, we have to define if a specific ACL template should be applied to the members of specific roles. Let’s start with the orders database.

The Web administration interface makes some convenience abstractions to map ACLs to Roles for each database under the unified roles page.

The REST API is operating at a lower level, directly manipulating the role-acl mapping in the database definitions. Let’s create the mapping for the orders database.

I define a first bash helper function, to lookup roles and ACLs uid and build the mapping JSON objects, and a second one to apply a configuration change to a database.

function RoleACLMap {
  rolename=$1
  aclname=$2
  roleuid=`RoleFindUidByName "${rolename}"`
  acluid=`ACLFindUidByName "${aclname}"`
  # Build the JSON object to map the ACL to the role
  echo '{"redis_acl_uid": '${acluid}',"role_uid": '${roleuid}'}'
}

mapping="`RoleACLMap Orders-RW DataRW`"
mapping="${mapping},`RoleACLMap Orders-RO DataRO`"
mapping="${mapping},`RoleACLMap Global-ADM DBAdmin`"
mapping="${mapping},`RoleACLMap Orders-PM DataRW`"
mapping="${mapping},`RoleACLMap Orders-DEV DataRO`"
DBUpdate "orders" '"roles_permissions":['"$mapping"']'

We can check the result in the web interface.

Let’s create the mapping for the products database.

mapping="`RoleACLMap Products-RW DataRW`"
mapping="${mapping},`RoleACLMap Products-RO DataRO`"
mapping="${mapping},`RoleACLMap Global-ADM DBAdmin`"
mapping="${mapping},`RoleACLMap Products-PM DataRW`"
mapping="${mapping},`RoleACLMap Products-DEV DataRO`"
DBUpdate "products" '"roles_permissions":['"$mapping"']'

And finally, define the mappings for the messaging database.

mapping="`RoleACLMap Orders-RW MsgRW`"
mapping="${mapping},`RoleACLMap Orders-RO MsgRO`"
mapping="${mapping},`RoleACLMap Products-RW MsgRW`"
mapping="${mapping},`RoleACLMap Products-RO MsgRO`"
mapping="${mapping},`RoleACLMap Global-ADM DBAdmin`"
mapping="${mapping},`RoleACLMap Orders-PM MsgRW`"
mapping="${mapping},`RoleACLMap Products-PM MsgRW`"
mapping="${mapping},`RoleACLMap Orders-DEV MsgRO`"
mapping="${mapping},`RoleACLMap Products-DEV MsgRO`"
DBUpdate "messaging" '"roles_permissions":['"$mapping"']'

Disable default anonymous account

By default, if an authentication idid not occur or fails, because the password is wrong or because the account does not exist in the database, the connexion is assigned to the default anonymous user, with default allcommands on allkeys permissions. We do not want that. we defined restricted permissions, we need to disable the default anonymous account in each database.

Either from the web administration interface :

Or with the REST API.

DBUpdate "orders" '"default_user": false'
DBUpdate "products" '"default_user": false'
DBUpdate "messaging" '"default_user": false'

Assign a roles to each account

So, for each project, we defined

• a read-only application role,
• a read-write application role,
• a read-ony with limited admin permission developer role,
• a read-write product manager role on the needed database for each microservice and a global administrator only role.

Lets assign roles to the accounts :

Once again, either from the web administration interface :

Or with the REST API :

function UserSetRole {
  username=$1
  rolename=$2
  roleuid=`RoleFindUidByName "${rolename}"`
  UserUpdate "${username}" '"role_uids":['${roleuid}']'
}
UserSetRole "orders-update" "Orders-RW"
UserSetRole "orders-update" "Orders-RW"
UserSetRole "orders-invoice" "Orders-RO"
UserSetRole "products-update" "Products-RW"
UserSetRole "products-stocks" "Products-RO"
UserSetRole "Angelina" "Global-ADM"
UserSetRole "Paul" "Orders-PM"
UserSetRole "Pierre" "Products-PM"
UserSetRole "David" "Orders-DEV"
UserSetRole "Denis" "Products-DEV"

Permissions tests

I wrote a script to test a set of meaningful commands with each account on each database.

cat << "EOF" > RBAC-tests.sh
#!/bin/bash
R='\033[1;31m'
G='\033[1;32m'
Y='\033[1;33m'
B='\033[1;36m'
P='\033[1;35m'
LG='\033[0;37m'
N='\033[0m'

function CmdTest {
DBPORT=$1
DBUSER=$2
DBPASS=$3
DESC=$4
CMD="$5"
ERR=$6
echo -en " - ${DESC} (${P}${CMD}${N}): "
RES=`echo "${CMD}" | timeout 1 redis-cli --user ${DBUSER} --pass ${DBPASS} -p ${DBPORT} 2> /dev/null | tr '\r' ','`
echo "${RES}" | grep "${ERR}" > /dev/null 2>&1
[ $? -eq 0 ] && echo -en ${R} || echo -en ${G}
echo -e ${RES}${N}
}

function BatchTest {
DBUSER=$1
DBPASS=$2
DBNAME=$3
DBPORT=$4
echo
echo -e ${LG}Database${N}: ${Y}${DBNAME}${N}\(${Y}${DBPORT}${N}\), ${LG}User${N}: ${B}${DBUSER}${N}, ${LG}Password${N}: ${B}${DBPASS}${N}
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "STRING Write            " "SET key value" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "STRING Read             " "GET key" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "HASH Write              " "HSET order:key field1 value1 field2 value2" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "HASH Read               " "HGETALL order:key" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "LIST Write              " "LPUSH order:key:sub value1" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "LIST Write              " "LPUSH order:key:sub value2" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "LIST Read               " "LLEN order:key:sub" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "LIST Read+Write         " "LPOP order:key:sub" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "PUBSUB Write            " "PUBLISH channel msg" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "PUBSUB Read             " "SUBSCRIBE channel" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "STREAM Write            " 'XADD mystream * item 1' '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "STREAM Read             " "XLEN mystream" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "Generic commands        " "INFO KEYSPACE" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "DANGEROUS ADMIN commands" "FLUSHALL" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
}

for account in orders-update orders-invoice products-update products-stocks Angelina Paul Pierre David Denis Didier; do
clear
BatchTest ${account} ${account} orders 12000
BatchTest ${account} ${account} products 12001
BatchTest ${account} ${account} messaging 12002
read
done
EOF
chmod +x RBAC-tests.sh
./RBAC-tests.sh

For orders-update

For orders-invoice

and so on, you can execute it yourself with the code available in my blog or zoom on my results in the Video.

Permissions maintenance

We initialized the projects, but things can change over the time.

A new employee joins

A new developer, Didier, joins the orders team.

We only have to give him the Orders-DEV role and he will have the appropriate permissions on the cluster and the data.

UserCreate "Didier" "Didier@example.org" "Didier"
UserSetRole "Didier" "Orders-DEV"

A developer switches to another team

The existing developer, David, moves to the products team.

We only have to change his role, and he will no longer have his previous permissions, but only the new permissions.

UserSetRole "David" "Products-DEV"

An employee leaves

A developer, Denis, leaves the company.

We only have to delete or disable this accounts.

UserDelete "Denis"

Access to new structures

Streams usage needed in messaging DB.

The messaging features need to use streams commands, from now, we only have to update the Msg-RO and Msg-RW ACLs.

ACLUpdate "MsgRW"   '-@all +publish +subscribe +@stream -@dangerous ~*'
ACLUpdate "MsgRO"   '-@all +subscribe +@stream -@write -@dangerous ~*'

Wrap-up and LDAP

Applications, developers, project managers and admins are uniquely identified with their own authentication and have specific permissions on the cluster and on the data. My next contents will talk about LDAP to roles mapping, because it is a pain to maintain when new people are hired, when people leave, when people move from one project to another, when people work on several projects… whereas all these information are already available and maintained up-to-date in the Enterprise LDAP.

Materials and Links

Footnotes

Vous pouvez trouver des liens vers les enregistrements vidéo et les supports imprimables associés à la fin de cet article.

• Vidéo d’explication et de démo
• Préparation de l’environnement
• Prérequis
• Un problème de sécurité et de conformité
• Limites des ACL Redis
• Mise en place
  • Création des bases
  • Création des comptes
  • Création des ACLs
  • Création des rôles
  • Relations Rôle-ACL dans les bases
  • Invalidation du compte anonyme par défaut
  • Affectation des rôles aux comptes
• Test des permissions
• Maintenance des permissions
  • Arrivée d’un développeur
  • Changement de projet
  • Départ d’un développeur
  • Modification d’un projet
• Conclusion et LDAP
• Supports et liens
• Notes de bas de page

Vidéo d’explication et de démo

Préparation de l’environnement

# Démarrage de Redis Enterprise
docker run -d --cap-add sys_resource --name redisenterprise -p 8443:8443 -p 9443:9443 -p 12000:12000 -p 12001:12001 -p 12002:12002 redislabs/redis
sleep 20

# Initialisation du cluster
docker exec -d --privileged redisenterprise "/opt/redislabs/bin/rladmin" cluster create name cluster.local username francois@redislabs.com password password
sleep 15

Prérequis

Ce contenu suppose que vous connaissez déjà les ACLs Redis. Si vous ne l’avez pas déjà vu, je vous recommende de regarder le contenu sur Comment gérer sécurité, accès aux données et permissions avec les ACL de Redis avant celui-ci. Si vous voulez reproduire la démonstration, vous aurez besoin de docker, curl et jq. Les commandes ne sont pas en pur shell POSIX mais font aussi appel à des extensions bash.

Un problème de sécurité et de conformité

Redis est utilisé dans presque toutes les entreprises dans le monde. Le contrôle d’accès aux données est critique pour assurer la sécurité des données et pour respecter la conformité aux règles comme RGPD (GDPR). Chaque connexion entrante doit être authentifiée et doit potentiellement reçevoir des permissions ou privilèges sur les bases disponibles, les commandes à exécuter et les données.

Imaginons que nous disposions de trois bases :

• une base orders pour y enregistrer les commandes et les lignes de commandes ;
• une base products pour enregistrer le catalogue des produits et leur quantité restante en stocks ;
• une base messaging servant de bus de communication entre les microservices à l’aide des fonctionalités PubSub de Redis.

Ajoutons à cela deux microservices, chacun ayant deux points de connexion (endpoints) :

• un microservice pour gérer les commandes dans la base orders, avec deux points de connexion : orders-update pour créer et modifier les commandes, nécessitant des permissions de lecture et d’écriture, et orders-invoice, pour générer les factures, avec des permissions en lecture seule. Ils doivent aussi accéder à la base servant de bus de communication respectivement en lecture-écriture et en lecture-seule ;
• l’autre microservice se charge de la gestion du catalogue produit et des stocks, avec deux points de connexion : products-update pour mettre le catalogue et les quantités à jour, et products-stocks pour vérifier la disponibilité d’un produit. Ils doivent aussi accéder à la base servant de bus de communication respectivement en lecture-écriture et en lecture-seule.

Puis, il y a les personnes :

• un administrateur, Angélina, qui n’a pas besoin d’accéder aux données ;
• deux chefs de projet, Paul pour le projet orders et Pierre, pour le projet products. Ils doivent pouvoir accéder aux données de leur projet en lecture et écriture pour les modifier, ainsi qu’au bus de messages. Ils doivent accéder aux journaux, à la configuration des bases et à la supervision ;
• deux développeurs, David, travaillant sur le projet orders avec un accès en lecture seule sur les données, et Denis, travaillant sur le projet products. Ils doivent aussi avoir un accès en lecture seule sur le bus de communication PubSub Redis. Ils doivent avoir accès à la supervision des bases.

C’est un exemple relativement simple, comparé aux besoins des entreprises dans la vraie vie. Les permissions sont simples à mettre en place, mais pas à maintenir ou à faire passer à l’échelle si vous avez plusieurs projets, profiles (développeurs, managers, chefs de projets, architectes, administrateurs) et bases de données. L’administration de la sécurité avec les ACL Redis peut rapidement devenir un cauchemard et doit être industrialisée et automatisée. Voyons comment Redis Entreprise peut gérer cet exemple.

Limites des ACL Redis

Bien que Redis soit largement connu et utilisé par les développeurs comme base de données, la gestion de la sécurité dépend des ops qui ne sont pas toujours au courant des fonctionnalités de sécurité de Redis. Depuis la version 6, Redis inclut l’authentification par identifiant et la gestion des autorisations d’accès aux données par des ACL, Access Control Lists, listes de contrôle d’accès.

Regardons quelles sont les permissions nécessaires, tant sur le cluster que sur les bases. Il faudra potentiellement créer manuellement les utilisateurs dans chaque base de données.

Avec les ACL Redis, sans les rôles, il faut créer chaque compte dans chaque base de donnée, avec un mot de passe, puis créer les ACLs individuellement. Si un projet doit changer de permissions, elles doivent être mises à jour individuellement dans chaque compte de chaque base. Quelle complexité lorsque les les projets changent les structures de données auxquelles ils doivent accéder. Essayons de factoriser tout cela.

Mise en place

Au-delà des ACLs, Redis Enterprise implémente une authentification mutuelle par TLS et un contrôle d’accès par role (RBAC) pour rendre la gestion des ACLs plus efficace et plus scalable au moment de gérer plusieurs projets avec de nombreuses personnes et plusieurs bases. Quelles sont les meilleurs pratiques pour implémenter l’authentification, les ACLs et les rôles dans Redis Enterprise ? Que peut on attendre de Redis Enterprise ?

Les rôles de Redis Enterprise peuvent être comparés à des groupes ou des profiles. Un rôle accorde des permissions globalement sur le cluster Redis Enterprise et des ACLs ciblées sur chacune des bases. Il créée et configure des comptes et des ACLs automatiquement dans chaque base.

Dans chaque base, on peut définir les ACLs à appliquer aux comptes en fonction de leur rôle.

Création des bases

On peut créer des bases manuellement dans l’interface web

ou automatiquement, par script, grâce à l’API REST.

function DBCreate {
  dbname='"name":"'"$1"'",'
  dbsize='"memory_size":'"${2:-102400}"','
  dbcfg="$3"
  curl -k -u "francois@redislabs.com:password" --request POST --url "https://localhost:9443/v1/bdbs" --header 'content-type: application/json' --data '{
    '${dbname}'
    '${dbsize}'
    '${dbcfg}'
  }';
}
function DBFindUidByName {
  dbname="$1"
  # Find the DB UID by name
  dbid=`curl -s -k -u "francois@redislabs.com:password" --request GET --url "https://localhost:9443/v1/bdbs" --header 'content-type: application/json' | jq '.[]|select(.name=="'${dbname}'").uid'`
  echo $dbid
}

function DBUpdate {
  dbname="$1"
  config="$2"
  dbid=`DBFindUidByName "${dbname}"`
  # Update the DB configuration
  curl -k -u "francois@redislabs.com:password" --request PUT --url "https://localhost:9443/v1/bdbs/${dbid}" --header 'content-type: application/json' --data '{
    '"${config}"'
  }';
}

function DBDelete {
  dbname="$1"
  dbid=`DBFindUidByName "${dbname}"`
  # Delete the database
  curl -k -u "francois@redislabs.com:password" --request DELETE --url "https://localhost:9443/v1/bdbs/${dbid}" --header 'content-type: application/json'
}

DBCreate orders 102400 '"port":12000'
DBCreate products 102400 '"port":12001'
DBCreate messaging 102400 '"port":12002'

Création des comptes

Encore une fois, les comptes peuvent être créés manuellement dans l’interface web d’administration :

ou de manière automatisée, grâce à l’API REST de gestion du cluster.

function UserCreate {
  username='"name":"'$1'",'
  useremail='"email":"'$2'",'
  userpass='"password":"'${3:-$1}'",'
  curl -k -u "francois@redislabs.com:password" --request POST --url "https://localhost:9443/v1/users" --header 'content-type: application/json' --data '{
     '${username}'
     '${useremail}'
     '${userpass}'
     "role": "none"
  }'
}

function UserFindUidByName {
  username="$1"
  # Find Account UID by name
  uuid=`curl -s -k -u "francois@redislabs.com:password" --request GET --url "https://localhost:9443/v1/users" --header 'content-type: application/json' | jq '.[]|select(.name=="'${username}'").uid'`
  echo ${uuid}
}

function UserUpdate {
  username="$1"
  usercfg="$2"
  uuid=`UserFindUidByName "${username}"`
  curl -k -u "francois@redislabs.com:password" --request PUT --url "https://localhost:9443/v1/users/${uuid}" --header 'content-type: application/json' --data '{'"${usercfg}"'}'
}

function UserDelete {
  username="$1"
  uuid=`UserFindUidByName "${username}"`
  curl -k -u "francois@redislabs.com:password" --request DELETE --url "https://localhost:9443/v1/users/${uuid}" --header 'content-type: application/json'
}


# Comptes
for u in orders-update orders-invoice products-update products-stocks Angelina Paul Pierre David Denis; do
  UserCreate "${u}" "${u}@example.org" "${u}"
done

Au final, le résultat est identique :

Création des ACLs

On peut facilement identifier cinq ACLs distinctes :

• Accès en lecture-écriture sur les données ;
• Accès en lecture seule sur les données ;
• Accès en consultation-publication sur des channels de communication ;
• Accès en consultation seule sur les channels de communication ;
• Accès aux commandes d’administration de la base.

Ces ACLs peuvent être créées manuellement depuis l’interface web d’administration :

Ou depuis l’API REST pour automatiser et industrialiser leur gestion :

function ACLCreate {
  aclname="$1"
  acltext="$2"
  curl -k -u "francois@redislabs.com:password" --request POST --url "https://localhost:9443/v1/redis_acls" --header 'content-type: application/json' --data '{"name": "'"${aclname}"'", "acl": "'"${acltext}"'" }' 
}

function ACLFindUidByName {
  aclname="$1"
  # Find ACL UID by name
  uuid=`curl -s -k -u "francois@redislabs.com:password" --request GET --url "https://localhost:9443/v1/redis_acls" --header 'content-type: application/json' | jq '.[]|select(.name=="'"${aclname}"'").uid'`
  echo ${uuid}
}

function ACLUpdate {
  aclname="$1"
  acltext="$2"
  acluid=`ACLFindUidByName "${aclname}"`
  curl -k -u "francois@redislabs.com:password" --request PUT --url "https://localhost:9443/v1/redis_acls/${acluid}" --header 'content-type: application/json' --data '{"acl":"'"${acltext}"'"}'
}

function ACLDelete {
  aclname="$1"
  acluid=`ACLFindUidByName "${aclname}"`
  curl -k -u "francois@redislabs.com:password" --request DELETE --url "https://localhost:9443/v1/redis_acls/${acluid}" --header 'content-type: application/json'
}

ACLCreate "DataRW"  '-@all +@hash +@list -@dangerous ~*'
ACLCreate "DataRO"  '-@all +@hash +@list -@dangerous -@write ~*'
ACLCreate "MsgRW"   '-@all +publish +subscribe -@dangerous ~*'
ACLCreate "MsgRO"   '-@all +subscribe -@dangerous ~*'
ACLCreate "DBAdmin" '-@all +@admin +@dangerous'

Dans les deux cas, le résultat est le même et les ACLs sont créées :

Création des rôles

Il faut maintenant disposer de rôles pour choisir quelle ACL appliquer à quel compte sur quelle base. On peut facilement identifier des motifs :

Le cluster Redis Enterprise peut accorder des privilèges d’administration aux rôles et chaque base du cluster peut accorder les permissions spécifiques d’ACL prédéfinies à chaque rôle. L’idée est donc de créer un rôle distinct par jeu de permission (cluster+bases) unique, par ligne distincte dans le tableau. Ainsi, dans notre simple cas d’exemple, nous avons besoin de neuf rôles, un pour chaque combinaison possible. Un rôle est un profile de compte ou un groupe de comptes ayant les mêmes permissions et privilèges sur l’administration du cluster, sur les bases, sur les commandes exécutables et sur les données accessibles.

Les droits d’administration du cluster étant attachés globalement aux rôles, il faut donc les y inclure lors de la conception des droits d’accès et lors de la création des rôles.

Créons donc les rôles, soit dans l’interface web d’administration du cluster Redis Enterprise…

Soit grâce à des appels d’API REST pour automatiser leur création…

function RoleCreate {
  rolename="$1"
  roleperm="$2"
  curl -k -u "francois@redislabs.com:password" --request POST --url "https://localhost:9443/v1/roles" --header 'content-type: application/json' --data '{"name": "'"${rolename}"'", "management": "'"${roleperm}"'" }'  
}

function RoleFindUidByName {
  rolename="$1"
  # Find Role UID by name
  ruid=`curl -s -k -u "francois@redislabs.com:password" --request GET --url "https://localhost:9443/v1/roles" --header 'content-type: application/json' | jq '.[]|select(.name=="'"${rolename}"'").uid'`
  echo ${ruid}
}

function RoleUpdate {
  rolename="$1"
  roleperm="$2"
  roleuid=`RoleFindUidByName "${rolename}"`
  curl -k -u "francois@redislabs.com:password" --request PUT --url "https://localhost:9443/v1/roles/${roleuid}" --header 'content-type: application/json' --data '{"management":"'"${roleperm}"'"}'
}

function RoleDelete {
  rolename="$1"
  roleuid=`RoleFindUidByName "${rolename}"`
  curl -k -u "francois@redislabs.com:password" --request DELETE --url "https://localhost:9443/v1/roles/${roleuid}" --header 'content-type: application/json'
}

RoleCreate "Orders-RW"    "none"
RoleCreate "Orders-RO"    "none"
RoleCreate "Products-RW"  "none"
RoleCreate "Products-RO"  "none"
RoleCreate "Global-ADM"   "admin"
RoleCreate "Orders-PM"    "db_member"
RoleCreate "Products-PM"  "db_member"
RoleCreate "Orders-DEV"   "db_viewer"
RoleCreate "Products-DEV" "db_viewer"

On aboutit finalement au même résultat :

Relations Rôle-ACL dans les bases

Chaque base de données peut accorder les permissions correspondantes à une ACL prédéfinie à chaque compte en fonction de son rôle. Un compte membre du groupe Products-DEV se verra accorder l’ACL Msg-RO sur la base messaging et l’ACL Data-RO sur la base products, mais aucune ACL, et donc pas de compte, sur la base orders :

L’interface d’administration web effectue une abstration de confort pour associer les ACL à des rôles dans chaque base, à partir de la page d’édition des rôles :

Cependant, l’API REST donne accès au véritable modèle de données interne, sans abstraction, et manipule directement les associations Rôle-ACL dans la définition des bases. Créons ces associations Rôle-ACL pour la base orders :

Un premier appel d’API REST permet de trouver l’identifiant interne d’un rôle, un autre permet de trouver l’identifiant de l’ACL à y associer, pour construire une association au format JSON. Ces associations sont concaténées dans un tableau JSON et envoyées dans la configuration de la base par un ultime appel d’API.

function RoleACLMap {
  rolename=$1
  aclname=$2
  roleuid=`RoleFindUidByName "${rolename}"`
  acluid=`ACLFindUidByName "${aclname}"`
  # Build the JSON object to map the ACL to the role
  echo '{"redis_acl_uid": '${acluid}',"role_uid": '${roleuid}'}'
}

mapping="`RoleACLMap Orders-RW DataRW`"
mapping="${mapping},`RoleACLMap Orders-RO DataRO`"
mapping="${mapping},`RoleACLMap Global-ADM DBAdmin`"
mapping="${mapping},`RoleACLMap Orders-PM DataRW`"
mapping="${mapping},`RoleACLMap Orders-DEV DataRO`"
DBUpdate "orders" '"roles_permissions":['"$mapping"']'

On peut le constater dans l’interface web d’administration.

Configurons les associations Role-ACL pour la base products :

mapping="`RoleACLMap Products-RW DataRW`"
mapping="${mapping},`RoleACLMap Products-RO DataRO`"
mapping="${mapping},`RoleACLMap Global-ADM DBAdmin`"
mapping="${mapping},`RoleACLMap Products-PM DataRW`"
mapping="${mapping},`RoleACLMap Products-DEV DataRO`"
DBUpdate "products" '"roles_permissions":['"$mapping"']'

Et finalement pour la base messaging :

mapping="`RoleACLMap Orders-RW MsgRW`"
mapping="${mapping},`RoleACLMap Orders-RO MsgRO`"
mapping="${mapping},`RoleACLMap Products-RW MsgRW`"
mapping="${mapping},`RoleACLMap Products-RO MsgRO`"
mapping="${mapping},`RoleACLMap Global-ADM DBAdmin`"
mapping="${mapping},`RoleACLMap Orders-PM MsgRW`"
mapping="${mapping},`RoleACLMap Products-PM MsgRW`"
mapping="${mapping},`RoleACLMap Orders-DEV MsgRO`"
mapping="${mapping},`RoleACLMap Products-DEV MsgRO`"
DBUpdate "messaging" '"roles_permissions":['"$mapping"']'

Invalidation du compte anonyme par défaut

Ok, nous avons défini les ACLs et les rôles, nous avons accordé des permissions (ACL) aux différents rôles dans chaque base, il faut éviter qu’un compte n’appartenant pas à un rôle déclaré dans une base, un compte non créé dans la base par le cluster Redis Enterprise, se voit accordé les permissions du compte anonyme par défaut. Il faut donc désactiver ce compte anonyme dans chaque base, soit à travers l’interface web :

Soit par des appels d’API REST :

DBUpdate "orders" '"default_user": false'
DBUpdate "products" '"default_user": false'
DBUpdate "messaging" '"default_user": false'

Affectation des rôles aux comptes

Nous avons donc défini des ACL, des rôles, les ACLs accordées aux comptes appartenant aux rôles dans les bases, pour chaque cas d’utilisation possible.

Il nous reste à assigner un rôle à chaque compte, pour qu’il bénéficie des ACLs accordées à son rôle dans chaque base :

Par exemple, le compte Denis dispose du rôle Products-DEV et aura donc l’ACL DataRO sur la base products et l’ACL Msg-RO sur la base messaging, ce qui correspond au besoin exprimé initialement.

On peut faire cette association compte-rôle dans l’interface web, bien sûr :

Ou grâce à l’API REST, si on souhaite automatiser :

function UserSetRole {
  username=$1
  rolename=$2
  roleuid=`RoleFindUidByName "${rolename}"`
  UserUpdate "${username}" '"role_uids":['${roleuid}']'
}
UserSetRole "orders-update" "Orders-RW"
UserSetRole "orders-update" "Orders-RW"
UserSetRole "orders-invoice" "Orders-RO"
UserSetRole "products-update" "Products-RW"
UserSetRole "products-stocks" "Products-RO"
UserSetRole "Angelina" "Global-ADM"
UserSetRole "Paul" "Orders-PM"
UserSetRole "Pierre" "Products-PM"
UserSetRole "David" "Orders-DEV"
UserSetRole "Denis" "Products-DEV"

Au final, le résultat sera identique :

Et les bases seront configurées correctement :

Test des permissions

J’ai écrit rapidement un script pour tester automatiquement les principales commandes autorisables et celles supposées interdites, par chaque compte dans chaque base.

cat << "EOF" > RBAC-tests.sh
#!/bin/bash
R='\033[1;31m'
G='\033[1;32m'
Y='\033[1;33m'
B='\033[1;36m'
P='\033[1;35m'
LG='\033[0;37m'
N='\033[0m'

function CmdTest {
DBPORT=$1
DBUSER=$2
DBPASS=$3
DESC=$4
CMD="$5"
ERR=$6
echo -en " - ${DESC} (${P}${CMD}${N}): "
RES=`echo "${CMD}" | timeout 1 redis-cli --user ${DBUSER} --pass ${DBPASS} -p ${DBPORT} 2> /dev/null | tr '\r' ','`
echo "${RES}" | grep "${ERR}" > /dev/null 2>&1
[ $? -eq 0 ] && echo -en ${R} || echo -en ${G}
echo -e ${RES}${N}
}

function BatchTest {
DBUSER=$1
DBPASS=$2
DBNAME=$3
DBPORT=$4
echo
echo -e ${LG}Database${N}: ${Y}${DBNAME}${N}\(${Y}${DBPORT}${N}\), ${LG}User${N}: ${B}${DBUSER}${N}, ${LG}Password${N}: ${B}${DBPASS}${N}
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "STRING Write            " "SET key value" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "STRING Read             " "GET key" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "HASH Write              " "HSET order:key field1 value1 field2 value2" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "HASH Read               " "HGETALL order:key" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "LIST Write              " "LPUSH order:key:sub value1" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "LIST Write              " "LPUSH order:key:sub value2" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "LIST Read               " "LLEN order:key:sub" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "LIST Read+Write         " "LPOP order:key:sub" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "PUBSUB Write            " "PUBLISH channel msg" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "PUBSUB Read             " "SUBSCRIBE channel" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "STREAM Write            " 'XADD mystream * item 1' '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "STREAM Read             " "XLEN mystream" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "Generic commands        " "INFO KEYSPACE" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
CmdTest ${DBPORT} ${DBUSER} ${DBPASS} "DANGEROUS ADMIN commands" "FLUSHALL" '\(ERR\|WRONGPASS\|(error)\|NOAUTH\|NOPERM\)'
}

for account in orders-update orders-invoice products-update products-stocks Angelina Paul Pierre David Denis Didier; do
clear
BatchTest ${account} ${account} orders 12000
BatchTest ${account} ${account} products 12001
BatchTest ${account} ${account} messaging 12002
read
done
EOF
chmod +x RBAC-tests.sh
./RBAC-tests.sh

Le résultat pour le compte orders-update sur les différentes bases est :

puis pour orders-invoice :

Et ainsi de suite. On constate que les permissions initialement définies sont bien implémentées et appliquées aux différents comptes sur les différentes bases.

Maintenance des permissions

Après la phase de mise en place et d’initialisation des projets, les choses peuvent changer.

Arrivée d’un développeur

Un nouveau développeur, Didier, rejoint l’équipe de développement du projet orders.

Il n’y a pas besoin de créer son compte dans les bases orders et messaging, puis de lui accorder des permissions spécifiques… Il suffit de lui attribuer le rôle Orders-DEV et le cluster Redis Enterprise se chargera du reste.

UserCreate "Didier" "Didier@example.org" "Didier"
UserSetRole "Didier" "Orders-DEV"

Changement de projet

Un développeur existant, David, est retiré du projet orders pour se trouver affecter au projet products.

Encore une fois, il est inutile de parcourir les différentes bases pour l’en retirer, puis d’ajouter son compte et les permissions du projet products dans les bases products et messaging. Il suffit de changer son rattachement pour lui affecter le rôle Products-DEV :

UserSetRole "David" "Products-DEV"

Départ d’un développeur

Un développeur, Denis, quitte le projet ou l’entreprise, que ce soit parce qu’il démissionne ou qu’il était consultant externe ou stagiaire.

Il suffit de désactiver ou de supprimer son compte, le cluster Redis Enterprise s’occupera de supprimer son compte, mot de passe et ACL de toutes les bases où il avait été déclaré grâce à son rôle Products-DEV. Aucun risque d’erreur ou de permissions fantômes.

UserDelete "Denis"

Modification d’un projet

Désormais, les fonctionalités de bus de communication entre les microservices nécessite l’utilisation des structures de données Streams de Redis. Il faut donc autoriser l’utilisation des commandes liées aux Streams.

Pour cela, il suffit de mettre à jour les deux ACLs reflétant les permission de lecture-seule Msg-RO et de lecture-écriture Msg-RW pour l’usage des messages. Ces ACL sont accordées par les rôles à qui en a besoin, sur la base messaging.

ACLUpdate "MsgRW"   '-@all +publish +subscribe +@stream -@dangerous ~*'
ACLUpdate "MsgRO"   '-@all +subscribe +@stream -@write -@dangerous ~*'

Les comptes ayant des rôles accordant ces ACLs seront automatiquement mis à jour dans la base messaging, sans en oublier aucun et sans erreur.

Conclusion et LDAP

Désormais, les applications, les développeurs, les chefs de projet et les administrateurs sont authentifié par un identifiant et un mot de passe personnel dans les bases auxquelles ils doivent avoir accès. Par ailleurs, il ne disposent que des permissions nécessaires selon leur rôle dans ces bases et dans le cluster. Mon prochain article traitera de l’association automatique entre LDAP et les rôles. En effet, même si les rôles facilitent et industrialisent la gestion des permissions pour éviter les oublis et les erreurs, ils dupliquent des informations se trouvant déjà dans l’annuaire LDAP de l’entreprise. Autant en bénéficier et refléter les informations du LDAP dans les rôles, automatiquement et en temps réel.

Supports et liens

Notes de bas de page

You can find links to the related video recordings and printable materials at the end of this post.

• Video
• Introduction
• The security problem
• Limits of the existing solution
• Implemented solution and results
  • What is a Redis ACL
  • Account initialization
  • Disabling an account
  • Multiple passwords per account
  • Command categories
  • Data-access restrictions
  • Specific command restrictions
  • Importance of rules ordering
• What about our example
  • Create accounts
  • Disable or limit the default account
  • Tests
    • Anonymous account
    • order-update microservice
    • order-invoice microservice
    • David developer
    • Paul Project manager
    • Angelina adminstrator
  • Security management at scale
• Materials and Links

Video

Introduction

Do you know that Redis can be secured with accounts and passwords for authentication and with access control lists for commands and data permissions ? You will learn how do ACL work, how to implement it.

The security problem

Until version 6, Redis only had a single anonymous default user, potentially with a single password, to grant full privileges. This security weakness is not a real concern for developers who love Redis for its flexibility, performances and other data manipulation and storage capabilities. They use it everywhere in nearly every company. This is a problem for ops and for the company’s security team, but they got used to it. They, you, might not know that Redis has named accounts with personal passwords for a real authentication and access control lists (ACL) for authorization and permission management. Redis can be secured, let’s see how it works and how to implement it with a sample project.

Limits of the existing solution

We have a single database to store orders and two microservices, one to update an order, another one to generate the invoice. This is a project, so we have one developer for each microservice, David and Denis, a project manager, Paul, and an administrator, Angelina. The microservices and the people are all using the same anonymous account, with the same single shared password. This password grants them full access to the whole dataset and to every Redis command. Everyone with this potential password can execute any command, with read-write permissions on the whole dataset. When a microservice needs read-write access to update a database and another one only needs read-only access, if the second one has a bug, is corrupted or compromised, it can corrupt the data of the first one or even delete the data. If a contractor or an intern work on the project, they have full access and the global simple shared password will probably not be changed when they leave, the microservices configuration would have to be changed, too. It makes it also impossible to track and audit who made what. Let’s see how Redis 6 and later can address this data-access security concern.

Implemented solution and results

First, I assume that all connections to the Redis database are encrypted with TLS, otherwise, the passwords can be intercepted.

What is a Redis ACL

An ACL, for access control list, is an ordered list of rules or ACE, for access control entries. Each rule can grant or revoke permissions on Redis commands, Redis key patterns or Redis channels to a named account, potentially protected by a password. Let’s see how to define ACLs.

acl setuser <account> [rulelist]

Account initialization

An account can be reinitialized with the reset rule to its initial state : with password enforced but not defined, without limiting rules, no command is allowed, no key is available, and disabled.

# Init the account and allow passwordless authentication
redis-cli acl setuser francois reset nopass
# The account is disabled
redis-cli --user francois --pass 'anything' quit

Disabling an account

An account can be temporarily disabled with the off rule or enabled with the on rule.

# Enable the account
redis-cli acl setuser francois on
# The connection succeed
redis-cli --user francois --pass 'anything' quit
# Disable the account
redis-cli acl setuser francois off
# No more connection possible
redis-cli --user francois --pass 'anything' quit
# Renable the account
redis-cli acl setuser francois on

Multiple passwords per account

The ACL can set one or several passwords to authenticate an account, with the > sign for a cleartext password or with the # sign for a hashed password. It can also invalidate one of the previously assigned password respectively with the < or ! sign. All passwords can be invalidated at once with the nopass rule, also allowing passwordless connections.

# Add a password to the account
redis-cli acl setuser francois '>mypassword'
# No more passwordless connection possible
redis-cli --user francois --pass 'anything' quit
redis-cli --user francois --pass mypassword quit
# Add a second password to the account
redis-cli acl setuser francois '>mysecondpassword'
# The first password still works
redis-cli --user francois --pass mypassword quit
# The second password also works
redis-cli --user francois --pass mysecondpassword quit
# Remove the first password
redis-cli acl setuser francois '<mypassword'
# The first password does not work anymore
redis-cli --user francois --pass mypassword quit
# The second password still works
redis-cli --user francois --pass mysecondpassword quit

Command categories

Rules can grant or revoke execution privileges on common command-categories, respectively with the + or - sign, followed by the @ sign and the category.

nocommands and allcommands are special keywords for -@all and +@all

# Reset the account with all keys access
redis-cli acl setuser francois reset on '>mypassword' ~*
# String commands are disabled
redis-cli --user francois --pass mypassword set strkey value1
# Limit the account to string related commands only
redis-cli acl setuser francois reset on '>mypassword' +@string ~*
# String keys write and read are allowed
redis-cli --user francois --pass mypassword set strkey value1
redis-cli --user francois --pass mypassword get strkey
# But not the other datatypes commands
redis-cli --user francois --pass mypassword sadd setkey value
# And not the general commands
redis-cli --user francois --pass mypassword info
# Grant a read-only access to string values only
redis-cli acl setuser francois reset on '>mypassword' +@string -@write ~*
# The account can not write
redis-cli --user francois --pass mypassword set strkey value1
# But the account can read
redis-cli --user francois --pass mypassword get strkey

Data-access restrictions

Rules can limit the available keyspace to glob patterns prefixed with the ~ sign.

# Access to all keys
redis-cli acl setuser francois reset on '>mypassword' +@all ~*
redis-cli --user francois --pass mypassword set mykey value1
redis-cli --user francois --pass mypassword set yourkey valuer2
redis-cli --user francois --pass mypassword set hiskey valuer3
# Access to my keys and your keys only
redis-cli acl setuser francois reset on '>mypassword' +@all ~my* ~your*
redis-cli --user francois --pass mypassword set mykey value1
redis-cli --user francois --pass mypassword set yourkey valuer2
redis-cli --user francois --pass mypassword set hiskey valuer3

Specific command restrictions

A rule can also grant or revoke execution privileges on specific commands with the + or - sign, respectively, and the command itself.

# Grant read-only access to string values, and to expiry information
redis-cli acl setuser francois reset on '>mypassword' -@all +get -set +ttl -expire -del +exists ~*
# The account can not write
redis-cli --user francois --pass mypassword set strkey value1
# The account can not change the key's TTL
redis-cli --user francois --pass mypassword expire strkey 60
# But it can read the value
redis-cli --user francois --pass mypassword get strkey
# And get the remaining TTL
redis-cli --user francois --pass mypassword ttl strkey

Importance of rules ordering

The rule order is important, rules are evaluated from left to right. A rule list can grant execution on hash commands only, but revoke execution on all the write commands.

# Grant read-only access to hash keys
redis-cli acl setuser francois reset on '>mypassword' -@all +@hash -@write ~*
# A write attempt fails
redis-cli --user francois --pass mypassword hset hashkey field1 value1 field2 value2
# Revoke write commands, but grant them afterwards
redis-cli acl setuser francois reset on '>mypassword' -@all -@write +@hash ~*
# The revocation is useless and writes are possible !
redis-cli --user francois --pass mypassword hset hashkey field1 value1 field2 value2

What about our example

Create accounts

We need to create six password protected accounts with different permissions

• orders-update : read-write access on hashes and lists starting with order:’’
• orders-invoice : same, but read-only
• david : same as orders-invoice
• denis : same as orders-invoice
• paul : same as orders-update, to manually fix data
• angelina : admin access to potentially flush the database, but access to the data

So, our orders Redis database can revoke permissions on all commands, but grant permissions on all of the hash and list manipulation commands, excluding the dangerous commands, on keys begining with order:*to a named account order-update, identified by a secret password. The first microservice can connect with his own credentials, is limited to the needed commands on the needed keys.

redis-cli acl setuser order-update reset on '>order-update' -@all +@hash +@list -@dangerous ~order:*

The order-invoice microservice needs the exact same permissions, without any write command, the ACL would be :

redis-cli acl setuser order-invoice reset on '>order-invoice' -@all +@hash +@list -@dangerous -@write ~order:*

Now, David and Denis need to have the same read-only permissions

redis-cli acl setuser david reset on '>david' -@all +@hash +@list -@dangerous -@write ~order:*
redis-cli acl setuser denis reset on '>denis' -@all +@hash +@list -@dangerous -@write ~order:*

Paul, as a project manager, needs to be able to change values

redis-cli acl setuser paul reset on '>paul' -@all +@hash +@list -@dangerous ~order:*

Finally, Angelina needs full admin access, to potentially flush the database

redis-cli acl setuser angelina reset on '>angelina' +@admin +@dangerous

Disable or limit the default account

The default anonymous account is a fallback to grant permissions when no authentication occured or succeed. This account has to be limited. The second execution should fail.

redis-cli acl setuser default reset +info
redis-cli acl setuser default reset +info

It can also be completely disabled. It is still enabled, but can only execute the AUTH command to authenticate as another account. The second execution should fail.

redis-cli acl setuser default off
redis-cli acl setuser default off

From that point, the only admin still available to change the permissions is… Angélina

Tests

The easiest way to test is to execute the following set of commands with each account. We first test that the account can read and write string keys, then hash keys, then list keys. Finally, we check that the info command can be executed and how many keys are in the database before trying to flush the whole database and check if it worked.

redis-cli --user angelina --pass angelina << EOF
set key value
get key
hset order:key field1name field1value field2name field2value
hgetall order:key
lpush order:key:sub value1
lpush order:key:sub value2
llen order:key:sub
lpop order:key:sub
info keyspace
flushall
info keyspace
EOF

Anonymous account

This account should not be able to execute any of these commands, with one exception, the INFO command, if you chose to leave it to this user.

order-update microservice

This account should not be able to read and write the string keys, because he is not allowed to execute string commands and because the key does not match the allowed pattern. He should be able to read and write the hash and list keys, he is allowed to use these commands and to access the keys. But it should not be allowed to flush the database.

order-invoice microservice

This account has the same permissions, but not on the write commands, thus the HSET will fail, as expected. But the LPOP also because this command not only read a value, but also remove it from the list, this is a read-write combined command.

David developer

David and Denis have the exact same permissions as order-invoice.

Paul Project manager

Paul has the exact same permissions as order-update and should be able to write the allowed hasn and list keys.

Angelina adminstrator

Angélina is not allowed to read or write any key, SET, GET, HSET, HGET, LPUSH and LPOP commands will fail, but she can execute the INFO command to get the number of keys on the database and to FLUSHALL the data.

Security management at scale

Applications, developers, project managers and admins are uniquely identified with their own credentials and have specific permissions on the database and on the data. But what happens when microservices are added with their own databases, with developers moving from a project to another, with new hired people, leaving people, with another Redis database used as a message bus to communicate with PubSub between all microservices… It is a pain to maintain and Redis can also manage such situations with a role based access control explained in my next content.

Materials and Links

Vous pouvez trouver des liens vers les enregistrements vidéo et les supports imprimables associés à la fin de cet article.

• Vidéo
• Introduction
• Un problème de sécurité
• Limites de la solution existante
• Solution implémentée et résultats
  • Qu’est-ce qu’une ACL Redis
  • Initialiser un compte
  • Désactiver un compte
  • Plusieurs mots de passe par compte
  • Catégories de commandes
  • Restrictions d’accès aux données
  • Restrictions sur les commandes
  • Importance de l’ordre des règles
• Revenons à notre exemple
  • Création des comptes
  • Désactivation du compte anonyme par défaut
  • Tests des privilèges
    • Compte anonyme
    • Microservice order-update
    • Microservice order-invoice
    • Développeur David
    • Chef de projet Paul
    • Administrateur Angelina
  • Gestion de la sécurité à l’échelle
• Supports et liens

Vidéo

Introduction

Savez-vous que Redis peut être sécurisé par des comptes avec mots de passe pour l’authentification et par des listes de controle d’accès pour les commandes et l’accès aux données ? Voyons comment fonctionnent les ACL et comment les utiliser.

Un problème de sécurité

Jusqu’à la version 6, Redis n’avait qu’un unique utilisateur anonyme par défaut, éventuellement avec un mot de passe, pour accorder les pleins pouvoirs. Cette faiblesse de sécurité n’est pas un vrai problème pour les développeurs qui aiment Redis pour sa flexibilité, ses performances et ses possibilités de manipulation et de stockage des données. Ils l’utilisent partout, dans presque toutes les entreprises. C’est un problème pour les ops et les équipes de sécurité, mais ils s’y sont habitués. Ils, vous, ne savez peut-être pas que Redis dispose de comptes nominatifs, avec des mots de passe individuels, pour l’authentification et de listes de contrôles d’accès (ACL), pour la gestion des autorisations et permissions. Redis peut être sécurisé, voyons comment cela fonctionne et comment l’implémenter avec un exemple de projet.

Limites de la solution existante

Nous disposons d’une unique base pour enregistrer les commandes et de deux microservices, un pour modifier une commande, l’autre pour générer la facture. C’est un projet, nous avons donc un développeur par microservice, David et Denis, un chef de projet, Paul, et un administrateur, Angélina. Les microservices et les personnes utilisent toutes le même compte anonyme avec son unique mot de passe. Ce simple mot de passe leur donne un accès complet aux données et aux commandes Redis. Chacun peut exécuter n’importe quelle commande, avec le droit d’écriture, sur le jeu de données.

Lorsqu’un microservice a besoin de lire et d’écrire, alors que le second n’a besoin que de lire, si le second a un bug, est corrompu ou compromis, il peut corrompre les données du premier. Si un prestataire ou un stagiaire arrive, il aura un accès complet aux données et l’unique mot de passe partagé ne sera probablement pas changé à leur départ, il faudrait aussi modifier la configuration des applications. Aucun audit n’est possible, pour vérifier qui a fait quoi. Voyons comment Redis 6 permet de gérer ce problème de sécurité.

Solution implémentée et résultats

Je suppose que les connexions à la base Redis sont chiffrées par TLS, sinon, les mots de passe circulent en clair sur le réseau.

Qu’est-ce qu’une ACL Redis

Une ACL, pour Access Control List, est une liste ordonée de règles ou ACE, pour Access Control Entries. Chaque règle accorde ou retire des privilèges à un compte nommé, sur des commandes Redis, des clés ou des channels. Le compte peut être protégé par son propre mot de passe. Comment définir des ACL ?