Forem: Dan

Authorization needs to be dynamic, declarative, and decoupled

Dan — Tue, 12 Nov 2024 10:00:00 +0000

Guest article written by Fatuma Abdullahi. Thanks! For more great community content and discussions, join our Slack today!

Authorization mechanisms have traditionally been closely tied to the main application logic, and while this works in traditional monolithic systems, maintaining this coupling becomes harder as application complexity grows.

As authorization is a significant aspect of creating and maintaining secure systems, it is better to have it decoupled (or "externalized"); that is, to reduce the dependence between authorization and core application logic. Decoupling simultaneously increases the reliability of the authorization functionality whilst decreasing the complexity of the core system itself.

It is also advantageous to have authorization logic expressed in declarative terms to describe the rules and expected outcomes. This allows the system to make decisions rather than explicitly stating how decisions should be made, making the authorization system accessible to less technical members of an organization. This leads to a dynamic authorization system, or one that makes real-time decisions as requests come in.

Decoupled, or externalized, authorization

Using an authorization system that is external to your primary system offers some hard-to-beat advantages, including:

Enhanced Security

External authorization providers are more secure because they are specialized, and are designed from the ground-up with domain-specific experience. They are more aware of the landscape and know what to look out for better than any team whose focus is pulled in many different directions.

Simpler Policy Management

External authorization providers offer a standard way of writing policies and rules, making policy management predictable and allowing the team to move faster.

Straightforward Scaling

External authorization systems have the concept of scale built in. They can be adapted at any size, and when the application grows or its authorization needs change, the external system grows with it seamlessly.

Advantages of externalizing authorization

Decoupling authorization shares advantages with using an external system because both rely on the separation of authorization and business logic as a central pillar. However, additional advantages appear when using an internally-decoupled system. These include:

Increased System Resilience

Separating authorization logic and rules from your main application increases your systems' resilience as the interdependence between them reduces. This allows your system to withstand outages without affecting all your functions.

Simplified Workflows

Keeping authorization external to your primary system simplifies setting up authorization logic and rules. It keeps the teams' focus on how authorization should look independent of any core logic, reducing chances of blind spots and increasing clarity.

Easier Maintenance

Using separate authorization systems makes maintaining the authorization engine more straightforward because of the decoupling that occurs. This makes it simpler to debug and increases the team's developer experience.

RBAC and decoupled authorization

Role-based access Control (RBAC) is an authorization technique that uses a user's role in a system to determine what resources they can access. It is a common way to enforce authorization across systems by assigning permissions to roles rather than to individual users and then assigning roles to users. When enforcing decoupled authorization, RBAC is implemented by centralizing all roles and their related permissions across the system.

There are some trade-offs when using RBAC to manage authorization, including:

Role Explosion

As a system grows, the number of roles and permissions might rapidly multiply leading to too many role definitions overall. This makes it harder to manage and reason about the authorization policies.

Granular Permissions

Sometimes, RBAC is used even in situations better served by more granular access controls. Scenarios requiring dynamic or context-specific permissions might be better served using other techniques like ABAC (Attribute-Based Access Control), which offer more control and flexibility.

Reduced Flexibility

Making changes to RBAC-based policies can be difficult in a growing system, and changes may cause system-wide repercussions. This can lead to a system being slower in adapting to changing authorization needs.

It is important to consider these trade-offs when designing RBAC-based authorization policies and to consider whether other access control techniques might be a better fit.

Authorization and microservices architecture

Microservice architecture refers to organizing application logic into services that typically carry out one thing and can be deployed independently while loosely coupled. For example, edge functions are microservices.

In a system where the backend isn’t distributed in this way (i.e. monolithic architecture), managing authorization queries is reasonably straightforward, as all the data is available in a central location. The challenge with authorization in a microservice architecture is that the services are separated by definition, and often may not talk to each other, making consistent access control and synchronization hard.

There are several ways to handle authorization in a microservices architecture, including implementing a gateway API (Application Programming Interface) service. Cerbos can be integrated into a microservices architecture as a mechanism deployed alongside microservices (e.g. a sidecar in Kubernetes), such that every service has consistent access to the authorization endpoint.

This flexible approach ensures that policies stay consistent across the entire system, regardless of the many services involved. This further simplifies policy management while enhancing security.

Authorization best practices

There are several principles to keep in mind to help make your authorization system robust and to follow best practices, including:

Principle of Least Privilege

This principle emphasizes that users should only ever have the minimum access to perform the required role and no more. This reduces the risk of unauthorized access and the chances of a breach.

Continuous Monitoring and Logging

Logging authorization requests is good practice. This makes it easier to monitor and detect any anti-patterns. Implementing this makes your authorization system more robust and secure, and it also simplifies compliance and audit procedures.

Separation of Concerns

Keeping authorization logic and policies decoupled increases your system's resilience, as any issues in parts of the application will not bring down the entire system. Additionally, decoupling authorization increases flexibility, extensibility, and maintainability at a system level.

Learn more!

You can learn more about decoupled / externalized authorization using the resources below:

Authentication and authorization in Node.js applications

Dan — Tue, 08 Oct 2024 13:00:00 +0000

Thanks to our friendly Cerbos community member—who wishes to remain anonymous—for this tutorial. For more great community content and discussions, join our Slack today!

In this article, we will discuss authentication and authorization, and how to implement both JWT authentication and Cerbos authorization in a Node.js application.

Understanding authentication

Authentication is the process of verifying the identity of a user. In a Node.js application, we typically authenticate a user based on a set of credentials, such as a username and password, to gain access to the application.

Some common authentication methods are:

Username and password
Token-based authentication
Single Sign-On (SSO)

The authentication process works like this:

The user provides their credentials.
The server verifies the provided credentials.
If the credentials are valid, the server generates an authentication token or session ID for the user.
The newly generated token/session ID is sent back to the client and stored for future use.
To prove their authenticity, the user includes the token/session ID in each request.

Understanding authorization

Authorization is the process of giving access to users to do specific work/actions. It decides what an authenticated user is allowed to do within the application. After authentication, authorization makes sure that the user only does what they're allowed to do, following specific rules and permissions.

Some common authentication models are:

How does authorization work?

The authorization process works like this:

The authenticated user makes a request to the server.
The server verifies the user and gets their assigned roles and permissions.
The server evaluates if the user has permission for the requested actions.
If the user is authorized, the server allows the user to perform the requested actions.
Otherwise, it denies access and returns an appropriate error response.

What is RBAC?

Role Based Access Control, or RBAC, is an access control method that gives permissions to the user based on their assigned roles within our applications. In simple words, it controls what users can do within the application.

Instead of assigning permissions to individual users, RBAC groups users into roles, and then assigns permissions to those roles. This makes it easier to manage access control, as we only need to update permissions for a role, rather than for each individual user.

Key components of RBAC are:

Role: Defines a set of responsibilities, tasks, or functions within the application.
Permissions: Represents specific actions that users can perform.
Role Assignments: Users are assigned to one or more roles, and each role is associated with a set of permissions.
Access control policies: Dictate which roles can access particular resources and what actions they can take.

RBAC is powerful, but implementing and managing it yourself is not easy. The open-source Cerbos PDP (or Policy Decision Point), acts as a stand-alone service, streamlining access control by centralizing both policy decisions and audit log collection, and decoupling authorization logic from your application.

Cerbos can function effectively within diverse software environments, from monoliths to fully decentralized architectures. It’s stateless and can be deployed via a Kubernetes sidecar, in a Docker container, or even as a single binary on a virtual machine. Cerbos exposes a rich HTTP API, which makes it language-agnostic, and allows it to interact and scale seamlessly with other services.

Implementing authentication and authorization in Node.js

Now that we have an understanding of authentication and authorization, let’s explore how to implement them in our Node.js application. In this section, we’ll build a simple Node.js app and integrate authentication and authorization functionalities.

Prerequisites

Before starting the project, make sure you have:

Node.js and npm installed on your system.
Docker installed on your machine (for running the Cerbos container).
Postman or a similar tool for testing API endpoints.

Set up a Node.js project

Create the project

To start with, we need to set up a Node.js project. Run the following command in the terminal:

npm init -y

This will initialize a new Node.js project.

Install the dependencies

Next, install the required dependencies for our project:

npm install express jsonwebtoken dotenv bcryptjs nodemon

This will install the following packages:

express: A popular web framework for Node.js.
jsonwebtoken: For generating and verifying JSON Web Tokens (JWT) for authentication.
dotenv: loads environment variables from a .env file.
bcryptjs: to hash the password.
nodemon: nodemon helps Node.js-based application restarts automatically when there is a change in the code.

Environment variables

Next, create a .env file to securely store our sensitive information, such as API credentials.

JWT_SECRET= "Your_Secret_Key_Here"
PORT=3000

Create the Express server

Now, we'll create an index.js file in the base directory and set up a simple Express server.

const express = require("express");
const dotenv = require("dotenv");
require('dotenv').config(); 

const app = express();
const port = process.env.PORT;

//middleware provided by Express to parse incoming JSON requests.
app.use(express.json()); 

app.get("/", (req, res) => {
  res.send("Hello World");
});

app.listen(process.env.PORT, () => { console.log(`Server is running on port ${process.env.PORT}`); });

At the top of the project, we're loading environment variables using dotenv.config() to make them accessible throughout the file. This way, we can use the dotenv package to access the PORT number from the .env file, instead of hardcoding it directly.

Run the project

In this step, we'll add a start script to the package.json file to easily run our project.

By default we'd have to restart our server each time we make changes to a file. To avoid this, we can use nodemon, which will scan for changes and restart automatically.

Add the following item to package.json:

"scripts": {
  "start": "nodemon index.js"
}

And now, we test!

npm run start

Finally, open http://localhost:3000/ in a browser, and if everything went to plan, you'll see the default "Hello World" page.

Implementing authentication with JWT

Our basic project setup is done! Next, we’ll implement authentication using JWT tokens.

Create routes for authentication

The authentication route will allow users to sign up and log in. Commonly, routes go in routes/, and since this is an authentication mechanism, we'll name it authentication.js. I've split this into multiple sections to make it easier to read, but it's the same file.

require('dotenv').config(); 
const express = require('express'); 
const jwt = require('jsonwebtoken'); 
const bcrypt = require('bcryptjs');

const app = express(); 
app.use(express.json());

const users = [ ]; // in-memory database to keep things basic for this tutorial

// Register route

app.post('/signup, (req, res) = >{

  const { username, password, role } = req.body;

  if (!Array.isArray(role)) {
    return res.status(400).json({ message: "Role must be an array" });
  }

  const userExists = users.find(user = >user.username === username);
  if (userExists) {
    return res.status(400).json({
      message: 'User already exists'
    });
  }

  const hashedPassword = bcrypt.hashSync(password, 8);

  users.push({
    username,
    password: hashedPassword,
    role
  });

  res.status(201).json({
    message: 'User registered successfully'
  });
});

// Login route 

app.post('/login', (req, res) = >{
  const {
    username,
    password
  } = req.body;

  const user = users.find(user = >user.username === username);
  if (!user) {
    return res.status(404).json({
      message: 'User not found'
    });
  }

  const isPasswordValid = bcrypt.compareSync(password, user.password);
  if (!isPasswordValid) {
    return res.status(401).json({
      message: 'Invalid credentials'
    });
  }

  const token = jwt.sign({
    username: user.username,
    role: user.role
  },
  process.env.JWT_SECRET, {
    expiresIn: '1h',
  });

  res.status(200).json({
    token
  });
});

The signup route allows users to register by providing a username and password. Upon receiving the data, it creates a new user instance and saves it to the in-memory database.

And, the login route verifies the user's credentials against the in-memory database. If the username and password match, it generates a JWT token and returns it to the client.

Middleware for JWT verification

Now, we’ll add one middleware function called verifyJWT that verifies the JWT token sent by the client, and which authenticates the user.

const jwt = require('jsonwebtoken');

function authenticateToken(allowedRoles) {
  return (req, res, next) = >{
    const authHeader = req.headers['authorization'];
    const token = authHeader && authHeader.split(' ')[1];

    if (!token) {
      return res.status(401).json({
        message: ‘No token provided'
      });
    }

    jwt.verify(token, process.env.JWT_SECRET, (err, user) = >{
      if (err) {
        return res.status(403).json({
          message: 'Invalid token'
        });
      }

      if (!allowedRoles.includes(user.role)) {
        return res.status(403).json({
          message: ‘You do not have the correct role'
        });
      }

      req.user = user;
      next();
    });
  };
}

module.exports = authenticateToken;

Protected route

Finally, we'll integrate these authentication routes with our express application in the index.js file.

app.get("/protected", authenticateToken(["admin"]), (req, res) => {
  res.status(200).json({ message: `Welcome Admin ${req.user.username}!` });
});

Here we have created a /protected route that uses authenticateToken to check if the user is authenticated.

If the user is authenticated, the server sends back a response saying "This is a Protected Route. Welcome [username]".

Here, [username] is replaced with the username of the authenticated user.

Test the endpoints

Sign-up

To validate the sign-up endpoint, we'll make a POST request to this route:

http://localhost:3000/auth/signup

With this header:

Content-Type : application/json

And the following JSON body:

{
    "username": "Arindam Majumder",
    "password": "071227",
    "roles":["admin"]
}

We got the token back as a response. We will copy the token as we'll need it in the next section.

Protected route

Now that we have obtained a JWT token from the login endpoint, we will test the protected route by including this token in the request headers.

For that, we'll make a GET request to the protected route URL http://localhost:3000/protected. In the request headers, we'll include the JWT token obtained from the login endpoint:

With this, we have successfully implemented JWT authentication in Node.js!

Implementing authorization with Cerbos

Now that we have added authentication to our project, we can now proceed authorization using the Cerbos PDP.

Launch the Cerbos container

We will begin by launching the Cerbos container via Docker.

In the base directory, use the following command to run the Docker container:

docker run --rm --name cerbos -d -v $(pwd)/cerbos/policies:/policies -p 3592:3592 -p 3593:3593 ghcr.io/cerbos/cerbos:0.34.0

And a quick docker ps to verify that the container persists.

For more information about the Cerbos container, see the official documentation.

Initialize the Cerbos client

Next, we set up the Cerbos client using the @cerbos/grpc library, which we first need to install:

npm install @cerbos/grpc

And we initialize the client with a few lines of code:

const { GRPC } = require("@cerbos/grpc");
const cerbos = new GRPC("localhost:3593", { tls: false });

Define a CRUD policy

After initializing the Cerbos client, we’ll define a simple CRUD policy in place for our application. Add this basic policy into the policies folder at cerbos/policies/contact.yaml.

---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: contact
  rules:
  - actions: ["read"]
    roles:
      - admin
      - user
    effect: EFFECT_ALLOW

  - actions: ["create"]
    roles:
      - admin
    effect: EFFECT_ALLOW

Access control middleware

Next, we'll create some middleware to check access for requests. In middleware/access.js:

const { GRPC } = require("@cerbos/grpc");
const cerbos = new GRPC("localhost:3593", { tls: false });

const jwtToPrincipal = ({ id, iat, roles = [], ...rest }) => {
  return {
    id: id,
    roles,
    attributes: rest,
  };
};

async function readAccess(req, res, next) {
  const decision = await cerbos.checkResource({
    principal: jwtToPrincipal(req.user),
    resource: {
      kind: "contact",
      id: req.user.id,
      attributes: req.user,
    },
    actions: ["read"],
  });

  if (decision.isAllowed("read")) {
      next();
    } else {
      return res.status(403).json({ error: "Unauthorized" });
    }

  }

  async function writeAccess(req, res, next) {
    const decision = await cerbos.checkResource({
      principal: jwtToPrincipal(req.user),
      resource: {
        kind: "contact",
        id: req.user.id,
        attributes: req.user,
      },
      actions: ["create"],
    });

    if (decision.isAllowed("create")) {
      next();
    } else {
      return res.status(403).json({ error: "Unauthorized" });
    }
  }

module.exports = {readAccess, writeAccess};

Here, the jwtToPrincipal function is a utility function that converts a JSON Web Token (JWT) payload into a Cerbos principal object. It extracts the sub (subject), iat (issued at), and roles properties from the JWT payload and assigns them to the corresponding properties of the principal object

The readAccess function is an asynchronous middleware function that checks if the current user has permission to read a contact resource. It uses the cerbos.checkResource method to make an authorization decision.

The writeAccess function is similar to the readAccess function, but it checks for permission to write to the contact resource instead of reading. It uses the "write" action in the cerbos.checkResource method.

Implement authorized routes

Finally, let's implement routes to check user access using Cerbos.

Import the required middleware functions for read and write access checks:

const {readAccess,writeAccess} = require("./middleware/access");

Update index.js file to include the following routes:

app.get("/read", userMiddleware, readAccess, (req, res) => {
  res.send("Read Access Granted");
});

app.post("/write", userMiddleware, writeAccess, (req, res) => {
  res.send("Write Access Granted");
});

And that’s it! By following these steps, we have successfully implemented authorization and RBAC in our Node.js application using Cerbos.

Test the authorized route

Now, we’ll test to see if the user has permission to do specific tasks.

To check if the user has write access, we'll make a POST request to http://localhost:3000/write with the following headers:

Content-Type: application/json
Authorization: JWT_TOKEN

The user with the admin role has access to this route.

Next, to check if the user has read access, we'll make a GET request to http://localhost:3000/read with the following headers:

Content-Type: application/json
Authorization: JWT_TOKEN

If successful, that will return as Read Access Granted as well.

Finally, let's check a user with the user role to see if it has write access or not. Make a POST request to http://localhost:3000/write with the following headers

Content-Type: application/json
`Authorization: JWT_TOKEN

As expected, we got an unauthorized response. That means the user doesn’t have access to that route.

Conclusion

In this article, we covered the basics of authentication and authorization, and how to integrate JWT authentication and Cerbos authorization into a Node.js application.

We Are Developers World Congress; an Engineer's Travelogue

Dan — Wed, 07 Aug 2024 14:33:53 +0000

Written by Cerbos engineer Sam Lock (connect on LinkedIn or GitHub)

Thursday

06:50

My alarm shouts in my ear that it’s time to wake up. I sit up and am momentarily confused, but then remember that I’m in Berlin, in a hotel room, and I’m staffing our company booth at a conference today. My body is aching; I wonder why, but then I remember the 50km I scooter’d across the city the day before. The scooters are electric but the Berlin streets are cobbled and unforgiving. The botanical gardens are nice, though.

I fall out of bed, stand up, glance at the coffee machine. It looks confusing to my sleep-addled brain. I glance at the time, it’s 6:52; “oh, I have loads of time”. I sit down again to catch my breath. A few seconds later, I glance at the time again: 7:10, “but how?”. I pick myself up and hurl myself into the bathroom.

The shower is angry and powerful; I desperately swing for the shower curtain as the torrent pushes me backwards with the force of a thousand rivers. Any residual sleepiness is washed away by adrenaline and the desire to live.

I’m clean and awake now. My bag is packed, I have my ticket ready to go. I glance at the coffee machine again; it looks less intimidating. I fill the reservoir, stab in a capsule, and press the button. It rumbles to life and spits coffee downwards in the general direction of the mug. The table is given a healthy dose, too. I stop briefly to admire the Jackson Pollock-esque artwork adorning the wooden top.

07:28

I feel more alert now. The coffee that made it into the mug has further lifted me from my haze and I head downstairs to meet my colleagues. I realise at this point that I forgot to have breakfast. I reason that I could probably do with skipping a meal and push it to the back of my mind. Not today, hunger.

Our team of four piles into a taxi. I’m kindly offered the front seat. The driver scrambles to clear the newspaper and pastry wrappers before I fold myself in. I’ve been on holiday for a little while, so open up Slack to peruse through the backlog of missed messages from the week prior as we head through the busy roads of rush-hour Berlin.

07:51

We arrive at Messe Berlin. Although I’ve been here the year prior, I’m once again impressed by the sheer size of the place. It’s early, but already there are eager crowds forming. We climb out the car and retrieve the various sacks of merch from the boot. We walk down the grand steps towards the entrance to pick up our passes and wristbands. I’m overcome by a feeling of power and belonging.

I follow my colleagues through the various exhibitor spaces towards our own. My fight-or-flight response kicks in as we pass a booth with a carnival hammer game. The attendee scores well; a couple of our team pledge to better the score later on. We discuss optimal swinging techniques but before we can come to a conclusion, we reach our own booth. Game time.

08:04

We pounce into action. One team member volunteers for a hunter-gatherer mission to find coffee. The remaining members start distributing merch around our allotted square of exhibitor space. There are four of us and two chairs. Thankfully, an unused booth behind us presents us with an additional chair. Only one weary stander. Thank you, conference.

We disappear off to have a swing of the hammer. Our CEO tops the leaderboard early on. Myself and another colleague are less pleased with our results. Probably rigged, I think to myself. Back to the booth.

With the distant thuds of the hammer ringing out, we settle in and get ready for the day as the first attendees start to appear.

“Hello! How are you? What’s Cerbos?”

“Well, tell me what you do, and I’ll see how it could apply…”

10:17

The conversations are rich and varied. Some have felt the pain of authorization and eagerly listen as we share the wonders of Cerbos. Others don’t understand authorization, but have seen our Cerbie plushies from afar. “How can I get one of those”, they ask. “You must care about Cerbos, first.” The denials are awkward, but necessary. Cerbies are finite and surprisingly expensive to produce. Some people come up and shout their desire for a Cerbie to my face. I weather the storm and stand my ground. “No”, I say, bravely.

Talking about authorization is thirsty work. I scour the halls for a water fountain, but alas, no water to be found. I ask a volunteer who offers me no clues but wishes me luck on my search. “Surely, it’s somewhere”. I eventually give up, find a coffee stand, and reluctantly pass over the €4.10 for a small bottle. I get a couple extra for my equally dehydrated colleagues. As I walk back to the stand, I debate with myself whether or not I should tell my boss how much I just spent on water.

13:08

Lunch beckons. I step outside and wait for my eyes to adjust to the light. It’s warm in Berlin; almost too warm. I spy my prize, the fabled “hotdog wrap” van from the year prior. Glorious, gravy and mashed potato filled things. I make haste, buy my food, and refuel. Back to the booth.

15:22

I’ve been tasked with a mission for doughnut retrieval. I’m briefed by a colleague; the doughnut deliverer has set off to the famous “Brammibal’s” (the best doughnut makers in Berlin?). I make a mental note, then return to authorization conversations and Cerbie denials.

16:02

The doughnuts are en route.

My hips start to get sore because I’m a delicate desk-sitter by profession. I do some ad-hoc yoga to limber up.

17:09

Call from the driver. Even closer. I suggest a location and set off across Messe, passing the hammer booth. The exhibitors' faces suggest that they regret their noisy choice of attraction. I continue for about 10 minutes in one direction, find a spot, share my location on Whatsapp, then set up camp.

17:27

Call from the driver. They’re nearby. “Did you see my location?”, I ask. “Yes, I’ll see you there soon”, they reply. Excellent.

17:31

Call from the driver: “I can’t see you”, they say. “Share your location?”, I suggest. 500 yards away. “Damn you”, I think to myself, before setting off in the opposite direction to meet with the confused driver.

I eventually find them, state my name, and claim my prize. “Can I go to the toilet?”, they ask. I’m puzzled. I’m not the toilet gatekeeper. “Probably”, I reply.

18:00

We officially transition to the “booth crawl” section of the day. A colleague procures some beers. They’re slightly warm but taste like liquid wheaty gold. The doughnuts are revealed. I eat one. They’re light and fluffy and delicious. More conversations are had. More people ask for Cerbies. We give out a few. I eat another doughnut. Then another.

19:30'ish

I feel some regret for the quantity of doughnuts I’ve consumed. I feel a bit poorly as we pack up the booth and head out to find a taxi to get back to the hotel, then each disappear off for a short, much needed rest in our rooms before dinner.

21:00'ish

I’m tasked with finding a restaurant so I scour Google maps and find the perfect one nearby. Traditional German food, classic wood furnishings; lovely. I brief my boss that they may be cash-only and he heads off to find some cash. We set off and eventually find the restaurant, but they’ve stopped serving food. I feel ashamed, but thankfully we find a burger joint nearby. They accept card payments.

The burgers were very good; we finish them off then return to the hotel. No hotel beers for this tired lot – straight off to bed.

Friday

06:50

My alarm shouts at me again. I’m bleary-eyed, but today I’m better prepared for the hell-shower and the over-excited coffee machine. I go about my morning routine and prepare for the day.

07:28am

I head downstairs for breakfast. Straight to the cereal bar. I add a spoonful from every jar to my bowl to form a single “super-cereal”. No hungry start for me today. I join my colleague and polish it off before getting some fruit to counteract my thus far beige breakfast.

08:00

Into a taxi and off to the conference. We know the drill – a colleague finds us some coffees and we settle down ready for day 2.

Rumours start to circulate of a little software bug that might be impacting some computers somewhere in the world. Meh – don’t think we need to worry about that.

08:07

We definitely do need to worry about that. We all struggle to check in via our airline apps for our various flights home later in the day, and passively watch on different news outlets as a simple (highly privileged) update brings the world to its knees. Oh well, we’ll talk about authorization until then.

10:42

It’s been a hectic couple of days and our t-shirt supplies are nearly depleted. Only a handful of size “S” remain.

I have an in-depth conversation with someone about their authorization needs. We’re both satisfied with the eventual outcome – they will go away and try to implement Cerbos and we will be happy to answer any questions that they might have. Great!

They ask for a t-shirt. “Sure!”, I say. “Are you [a] small?” I ask. “Yes, I am quite small”, they reply. I curse myself for an unfortunate choice of wording.

12:00

It’s raffle time. A crowd gathers around our booth for the chance to win our grand prize: a Super Nintendo System Lego set! My boss throws some Cerbies into the crowd to warm them up, much like a bouquet-toss at a wedding, and people scrap for them with a surprising level of urgency. People really do love our plushies. Thankfully no-one was hurt.

All the entries were placed into a virtual hat, and a name pulled. A delighted looking recipient came forward on the first draw and we handed it over.

14:23

More yoga. I’m no good at standing up it seems.

The exhibition halls have started to quieten down. People are running out of steam. Not us, though – we’ve depleted our merch-reserves, but the conversations are still flowing.

15:48

Time to go. I share a similar timed flight with our CEO, so we pack up together and head off. As we leave, he points out the water fountain just a stone’s throw from our booth. Whoops. We get in our Uber and anxiously make our way to Berlin Brandenburg to see what havoc CrowdStrike has unleashed upon the airport.

PM

None, it seems. Security and passport control is seamless. I and other travellers play a small game of plane Hokey Cokey as they struggle to find us one with working air conditioning. But we eventually lift off, and bid farewell to Berlin and to We Are Developers for another year.

See you all again next time ✌️

—

Cerbos is an open-source, scalable authorization layer for software applications. It simplifies access control by separating authorization logic from business logic, allowing developers to define and enforce complex policies with ease. Cerbos integrates seamlessly with existing applications and supports various environments, ensuring secure and efficient permission management.

If you have any questions or feedback, or to chat to us and other like-minded technologists, please join our Slack community!

Introduction to RBAC in Kubernetes

Dan — Tue, 30 Jul 2024 13:51:52 +0000

Guest article written by Tania Duggal.

In this article, you will learn what RBAC is, the key challenges and approaches to managing RBAC in Kubernetes, and how Cerbos can help you in your application security.

In Kubernetes, when a request comes to the API Server to create resources, it processes the request in different steps. It first checks from where a request is made and whether a user is valid or not. This process is called authentication. There are two categories of users: normal users and service accounts. Service accounts are managed internally by Kubernetes, and are used by applications that access the cluster, such as the Monitoring Application. Normal users are external entities that may include administrators, developers, and other humans.

After authentication, the next process is authorization for the requested action and permissions. While Kubernetes supports multiple authorization methods, the one we’ll concentrate on in this article is called RBAC.

What is RBAC?

RBAC stands for Role Based Access Control. It is a method through which we can control access to resources and actions based on the roles assigned to the users. In Kubernetes, RBAC is how the administrator can control and allow which actions the users can perform on which resources, respectively. RBAC is managed just like everything else in Kubernetes: as objects that can be described via YAML or kubectl. To enable RBAC, the --authorization-mode flag must be set to RBAC when starting the API server.

kube-apiserver --authorization-mode=RBAC

Core Objects of Kubernetes RBAC

The RBAC API declares four core objects. These are:

Role: It is a way of defining what actions users can perform within a namespace. This defines which actions such as get, list, create, delete, etc., can be performed on specific resources like pods, services, and deployments.
Cluster Role: This is similar to the role, but it is used for cluster-wide permissions. It means it is not limited to a specific namespace and can be used in all namespaces of the cluster.
RoleBinding: RoleBinding binds the role with one or more users, groups, and service accounts in a particular namespace. In this way, whatever permissions we have defined in a role get allotted to the users, groups, or service accounts.
ClusterRoleBinding: ClusterRoleBinding binds the ClusterRole to one or more users, groups, and service accounts throughout the cluster. This allows the permissions defined in ClusterRole to be assigned to users in all namespaces of the cluster.

How RBAC is implemented in Kubernetes

It depends on your requirements and what you want to create for your resources, whether it be a Role or a ClusterRole.

Create a Role and assign it with RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: default
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "list", "update", "delete", "create"]

We have permitted pods to get, list, update, delete, and create the resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devuser-developer-binding
subjects:
- kind: User
  name: dev-user # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

RoleBinding binds the developer Role to a user named dev-user in the default namespace.

Create a ClusterRole and assign it with ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-administrator
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["nodes"]
  verbs: ["get", "list", "delete", "create"]

We have permitted nodes to get, list, delete, and create the resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-role-binding
subjects:
- kind: User
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-administrator
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding binds the cluster-administrator ClusterRole to a user named cluster-admin in all namespaces.

Challenges in Kubernetes RBAC

Difficulty in Management: It's difficult to manage RBAC in Kubernetes when you have so many roles and permissions. Each user and service requires particular permission, which can be time-consuming and complex. As the number of users, applications, and namespaces grows, it becomes difficult to handle the RBAC configuration.

For example, if you have a team of developers in different namespaces, you must ensure that each developer can only access the resources that they need. Mistakenly, if any developer gets too many permissions, they can unintentionally modify other's resources.
Scalability Issues: As the organization grows, so does the number of users and roles. This growth is asymmetrical, and the challenge of scaling RBAC manually can quickly become overwhelming. It becomes a huge task to manage and define permissions for each employee. A minor error can lead to a security breach or any operational issue.
Manual Process: When you configure and define RBAC roles and permissions manually, it can be quite dangerous. Even a small mistake can lead to a security breach.

For example, if an administrator has to permit the developer only to read but mistakenly gives permission to him to write as well, then the developer can modify data, which can lead to vulnerabilities.
Logs Auditing and Compliance: It is necessary to maintain accurate and detailed records for auditing and compliance. To follow standards such as GDPR and HIPAA, you have to maintain detailed logs that show which users performed what actions and when. Kubernetes provides limited tools for RBAC auditing, which makes compliance challenging.

Approaches to Addressing Kubernetes RBAC Challenges

Implementing Principle of Least Privilege: Least Privilege means you have to give minimum permissions to the users they need to do their work. Too many permissions can result in security issues. You should follow the least privilege approach to enhance security.
Policy Management Tools: Managing too many policies can be difficult. You can use policy management tools to reduce the burden of managing policies. These tools can create, update, and manage policies for you and ensure RBAC policies are up-to-date and secure.
Namespaced Roles: You should use namespace roles to limit the scope of your resources. With a namespaced role, you can ensure that a user or service only gets access to the resources in that namespace that are necessary for their function. This isolation helps us prevent accidental access.
Auditing RBAC regularly: You should audit your RBAC configuration regularly. With regular lookups on these configurations, you can timely identify issues and fix them.

It's clear that managing Kubernetes access and permissions is quite complex, but it provides a robust security feature at the infrastructure level, and is well worth considering for your future deployments.

Bring powerful RBAC to your applications

Finally, if you're looking to bring that same infrastructure-level power to the application layer, you should check out Cerbos. The Cerbos Policy Decision Point (PDP) is the scalable, open source authorization layer for implementing roles and permissions at the application layer. It can be deployed easily as a sidecar alongside your Kubernetes-managed applications. Try it today!

Cerbos Hub: A complete authz management system

Dan — Thu, 25 Jul 2024 09:45:02 +0000

Good news everyone: Cerbos Hub is now generally available! In this post, we’re going to explain what Cerbos Hub is, why it's useful, and how it solves some of the hardest challenges with externalizing authorization.

Cerbos: Fine-grained authorization and access control

New to all of this? No problem. Cerbos is a scalable and extensible authorization service for developer, product and security teams. It enables teams to implement fine-grained authorization and access control in their applications, services, and infrastructure in an auditable, programmatic, and scalable way. Maybe you’ve heard of RBAC, ABAC, ReBAC, PBAC and so forth? That’s what Cerbos is all about.

The Cerbos open source Policy Decision Point (PDP) is a popular solution for technical teams who’ve made the decision to separate the authorization process from their core application code, freeing them up to concentrate on their core business. It can be deployed as a binary on metal, in a sidecar, as a service in a VM—anywhere on your infrastructure, any way you want.

Cerbos Hub: manage centrally, deploy anywhere

One of the great things about the PDP is how powerful and extensible it is. Cerbos Hub is designed from the ground up to help you harness that power and control that extensibility. The industry term is Policy Administration Point (PAP), but it can be thought of as a control plane. Cerbos Hub is all about unlocking the full potential of the PDPs by providing an intuitive user interface, collaborative policy management, and a powerful testing and deployment pipeline.

Simplified policy management

Cerbos Hub centralizes policy management no matter where or how your PDPs are deployed. With a managed CI/CD pipeline, you can deploy and test policies seamlessly across development, testing, and production environments. No more juggling tools and processes—Cerbos Hub coordinates the rollout of authorization policies across your apps, APIs, and infrastructure.

Whether your infrastructure is on-premise, cloud-based, or serverless, Cerbos adapts to your needs. It supports edge devices, security hardware, and even in-browser runtimes for frameworks like React and Angular through its Embedded Policy Decision Point capability. This means you can authorize anywhere, keeping your policies in sync regardless of the environment. And with Cerbos Hub, managing that synchronization is easier than ever!

Embedded PDP

As one of our engineers so eloquently put it: “This requires some explanation.” Traditionally, when you’re thinking about service delivery, you’re thinking about a binary running in a container or sitting on a virtual machine somewhere. That’s fine, but it’s not the only model.

If you want to perform authorization checks directly from the end-user device, that would mean both exposing your PDP to the Internet and inviting network latency with every call. Another approach is to run those authorization checks on the device, in the browser, or from the edge—that’s where Embedded PDP comes into play.

The Cerbos Embedded Policy Decision Point is a WebAssembly module that runs right in your application, putting authorization checks as close to the user as possible. This reduces your security footprint, improves latency, and unlocks powerful functionality; for example, you can embed authorization checks in your user interface to only render the buttons they actually need to see!

When you update your policies in Cerbos Hub, Embedded PDPs are automatically compiled and distributed to your end-users via global CDN. This simplifies updates and streamlines management of your policies no matter where your end users are.

Robust policy authoring and testing

Cerbos Hub's web IDE lets you collaboratively build and test policies right in your browser! Create policies in YAML with our useful templates, then use the playground to refine, validate, and test those authorization rules. And since everything is ultimately code, this can be tied into your existing deployment workflow, meaning that the validation and deployment of your policies becomes another step in your application management lifecycle. Git actions, artifact generation, automated build and deployment pipelines—it all fits!

However, authorization is more than just code—it’s a representation of how your business functions. Who can access what, where, when, and how, goes beyond deploying your stack. Cerbos Hub is the best way to get everybody involved; from operations, to HR, to accounts payable (and even your CISO), Hub’s collaborative policy-building tools give everybody the opportunity to speak the same language and concentrate on their requirements and business cases.

Get started today!

Ready to level up your authorization game? Try Cerbos Hub and experience the future of authorization management.

Easily keep your local git repo up to date

Dan — Fri, 12 Jul 2024 12:10:25 +0000

Here's how to keep your clone of a Git repository current with upstream quickly and efficiently. Just pop this snippet into the .git/config of your local checkout and you're good to go (some assembly required).

[remote "upstream"]
    url = <http url>
    fetch = +refs/heads/*:refs/remotes/upstream/*
[alias]
    refresh = "!git checkout main && git fetch upstream && git merge upstream/main main"

Run git refresh before you branch locally, and just like magic, you'll avoid merge conflicts and other irritating side effects. It's a bit dirty, but it'll do the job in most cases. 😉

Want to know more about what's going on here? Great!

First: why? A few of the open source projects I work on have very active repositories, and since they all favour trunk-based development, that means main gets updated frequently. Furthermore, they all prefer pull requests to be proposed from clones, as humans don't touch the primary repository directly.

This is a really common model, so nothing special; however I always forgot to rebase before branching, except when I didn't forget to rebase, because I'd forgotten how to rebase. (Git is fun!)

So instead of having to do a little dance every time, I figured: 💭 let the computer do the work. And while incantations are great, I'm cranky enough to want to know what it is the computer is doing on my behalf, so let's break it down:

[remote "upstream"]
    url = <http url>
    fetch = +refs/heads/*:refs/remotes/upstream/*

The [remote] block defines a remote repository, i.e. a repo that isn't on your computer. Here I've given it an arbitrary name (upstream). Arbitrary because it's only used in this configuration context, so go with your heart on this one.

Inside that block there's url = <http url>, which—you guessed it—defines the URL where the remote repository lives. This could be a link to Codeberg, GitHub, GitLab, or whatever y'all got going on.

Next is fetch, which literally tells git how to fetch updates from that remote repository. That's the easy part. What do those other bits mean?

The + tells git to "force" update the references. If you're familiar with Git, this means forcing the references even if the result is a non-fast-forward update. Remember at the top of the post when I said "It's a bit dirty"? This is what I'm talking about. But here's the thing: it's probably what you want anyway. 😇

The refs/heads/* part just tells git to get all the branches from the remote repo. Again: it's probably what you want.

Finally, :refs/remotes/upstream/* specifies where those fetched branches are going to be stored locally. There's a whole different blog post to be written about just this, but the tl;dr is we want to keep the upstream branches separate from the local branches, because things get crazy graph-theory style if we don't. 😝

OK, now the part you've all been waiting for: the actual command!

[alias]
    refresh = "!git checkout main && git fetch upstream && git merge upstream/main main"

The [alias] block defines, well, an alias. It's basically a shortcut that lets us run arbitrary commands or sequences (including, notably, shell commands) so that we don't have to write them out by hand each time. In this case, the alias is refresh; the idea here being that we can type git refresh on the shell and it runs the command sequence, thus simplifying our lives somewhat. And some is better than none.

Also: remember at the top of the post when I said "It's a bit dirty"? This shell command is actually what I'm talking about. 🥸 Let's be legends…

The ! right at the start of the sequence tells git to treat the whole thing as a shell command, so whatever comes next will just be executed like we typed it out.

First we make sure that we're on the main branch in our local repo by running git checkout main. It's possible that your repo uses a different name for trunk ("master" was popular for a long time), but "main" is common.

Then we git fetch upstream to nab that fresh upstream data from the remote repository. Remember upstream? It's the remote repository we defined previously. Ah what fun we had.

Finally, we merge the changes from the main branch of upstream into the main branch of our local repository. That's literally how to read git merge upstream/main main. 🧠

And that's it! A couple of lines gets us a quick, reusable, fairly reliable method of keeping our local repo up to date.

Hope that helps! Let me know!

BONUS: You might also be wondering what those && are for in between each of the commands. The Very Correct Definition is that && is a "logical AND operator". What it's used for in this case is a way to chain a series of shell commands into a sequence, whereby the next command will only be called if the current one was successful. This way, we don't end up doing horrible things to our local repo if when things go wrong.

Microsoft Entra External ID & Cerbos ✨

Dan — Wed, 26 Jun 2024 13:18:37 +0000

👋 Looking to level up your authentication (authn) and authorization (authz) game? Here's a great tutorial that dives into integrating Microsoft Entra External ID for seamless external authentication and Cerbos for top-notch, fine-grained authorization. You’ll learn about adding authentication to your external-facing apps, how to write policies, and what a policy decision point is. With clear steps, sample code, and just enough YAML to meet your daily quota, you'll learn to create secure and scalable solutions that are actually usable in the real world. Check out the full guide here!

As an added bonus, this is actually part two of a three-part series. If you’re not entirely sure what authentication and authorization are (or just want a refresher before diving into the tutorial), you should definitely check out the first part, too. 😄

Questions? Comments? Hit us up in our Community Slack—let's get that conversation going!

Behind the Helm (September 2023)

Dan — Mon, 08 Jan 2024 09:01:29 +0000

This is the web edition of the Behind the Helm, Scaleway's monthly Kubernetes newsletter. For the best Kubernetes news in your inbox every month, subscribe today!

Hello lovely subscribers!

September is wrapping up, and autumn is fast approaching. This month’s edition of Behind The Helm is here with its usual round-up of blog posts, podcasts and events news to keep you up to date with the cloud native world.

Blogs & news

The legacy K8s repositories installable through yum and apt are now frozen as of September 13th; for new updates to these repositories you’ll need to pull from the new registry at k8s.io.

Author Eyal Bukchin has written an excellent blog post comparing three local development tools for Kubernetes: Telepresence, Gefyra, and mirrord. Check it out to learn all about these tools and how they can improve your development experience!

Podcast episodes

The Kubernetes Podcast has a couple of excellent episodes out this month, including an interview with Grace Nguyen about the 1.28 release. Grace was the release lead for this version, so if you want a peek behind the scenes at what actually goes into a release cycle, be sure to give it a listen!

Events

Kubernetes Community Days UK is happening on the 17th and 18th October. If you’ll be near London around then, definitely consider attending!

May your deployments be smooth and your pipelines never fail.

Eli & the Scaleway team

Behind the Helm (August 2023)

Dan — Mon, 04 Sep 2023 09:36:22 +0000

This is the web edition of the Behind the Helm, Scaleway's monthly Kubernetes newsletter. For the best Kubernetes news in your inbox every month, subscribe today!

Hello lovely subscribers!

I hope you’ve had a great summer so far. At Scaleway, the latest additions to our changelog have all been about databases; it’s clearly the summer of data.

Kubernetes 1.28 is out! This edition brings us better recovery from unexpected node shutdown, longer lead times between API server and node version updates, and a whole host of features entering the alpha phase.

Marino Wijay and Matt Turner joined David Flanagan and Laura Sanatamaria for another episode of Cloud Native Compass, this time around Istio’s new Ambient Mesh offering. Give it a listen if you want to stay on the cutting edge of the service mesh world!

Last week’s edition of the Scaleway Sessions featured Thibault Lengagne from Padok, taking us through two different attack scenarios on a K8s cluster used to deploy a vulnerable web app. We had an absolute blast chatting with Thibault; you can check out the recording here.

On that episode we also talked about a number of tools that are out there to help developers keep their clusters safe, including using Kyverno to double check that your pods really do only have the permissions they need. If you’ve watched the latest Scaleway Sessions linked above, read this blog post from Kyverno to know more about how to mitigate one of the vulnerabilities we exploited!

Lastly, we at Scaleway would like to note with great sadness the passing of Kris Nóva, a trailblazing developer, community builder and Kubernetes contributor. Her work in distributed systems and open-source development has left an enormous legacy, and she will be much missed.

May your deployments be smooth and your pipelines never fail,

Eli & the Scaleway team

PS. I’ve been on vacation this month, so there’s no crossword this time around—stay tuned for the next edition!

Behind the Helm (July 2023)

Dan — Thu, 03 Aug 2023 22:00:00 +0000

This is the web edition of the Behind the Helm, Scaleway's monthly Kubernetes newsletter. For the best Kubernetes news in your inbox every month, subscribe today!

Hi, lovely subscribers!

I hope you’ve had a great summer so far. At Scaleway, we’ve been hard at work releasing new features - check out our changelog!

Argonaut have released a technical exploration of their CI pipelines, which is absolutely fascinating. If you’d like a peek under the hood of one of the most popular deployment tools for K8s, this is a must-read.

IstioCon will be happening on the 25th & 26th of September, with a mix of virtual and in-person content scheduled. If you want to keep up with the movers and shakers in the service mesh world, give it a look. In the meantime, you can read about Istio’s authentication and authorization policies in this cool article from InfraCloud!

Also from InfraCloud is this primer on MLOps - if you’ve been wondering about whether machine learning technology has a place in your workflow, now is the time to find out.

Our Kubernetes meetup, KubeTalks, is taking a summer break - the next edition will be on the 28th September at our Paris office!

Finally, if your work is slowing down over the summer, and you find yourself with some time spare to catch up on everything cloud-native, you can never go wrong with the CNCF’s excellent course of Online Programs.

May your deployments be smooth and your pipelines never fail,
Eli & the rest of the Scaleway team

p.s. It’s too warm to think very hard right now, so this month’s crossword isn’t cryptic! Enjoy 🙂

Behind the Helm (June 2023)

Dan — Thu, 29 Jun 2023 22:00:00 +0000

This is the web edition of the Behind the Helm, Scaleway's monthly Kubernetes newsletter. For the best Kubernetes news in your inbox every month, subscribe today!

Hello lovely subscribers!

It’s June, and with the new month comes a new edition of Behind The Helm. We’ve got our usual round-up of blog posts, podcasts and events news to keep you up to date with the cloud native world.

Blogs & news

First up, we’ve got some tooling news: Red Hat has brought Podman to the desktop with version 1.0 of their Community Edition! This release can help businesses streamline OpenShift workflows, and swiftly onboard developers who are new to cloud native.

Next is a fascinating read by the folks at OpenTelemetry, focusing on runtime observability in K8s. Check it out, and bring your debugging to the next level with your newly acquired tracing superpowers.

The awesome folks over at Inheaden connected 250,000 IoT devices to the cloud using K8s; read the deep dive on our blog!

Podcast episodes

The Changelog podcast covered the hallway track at the Linux Foundation’s Open Source Summit last month, and this month they’ve released their last episode of that coverage — including some very cool guests.

If you want to keep up to date with all the WASM hype, check out this episode of the Kubernetes Podcast with Justin Cormack, the CTO of Docker.

Events

With summer coming, our Lille office is in full bloom. We’ll take advantage of its gorgeous terrace to host an edition of KubeTalks, our K8s-focused meetup. This event will be in French, and we’ll welcome Stephane Dessein, CTO of Le Fourgon, along with Bruno Flament, DevSecOps Kubernetes at Whispeak, who’ll discuss Kubernetes service traceability. Save your spot!

Registration is now open for KubeCon + CloudNativeCon in Chicago this November! Book your tickets, book your hotel—get hype.

Finally, our DevRel team will also be attending DevOpsDays Amsterdam if any of you are there, we’d love to hang out! Come grab us for a chat and a coffee.

That’s all for now (apart from the crossword, of course) — see you all in July!

Yours,
Eli & the Scaleway team

Behind the Helm (May 2023)

Dan — Thu, 08 Jun 2023 07:00:00 +0000

This is the web edition of the Behind the Helm, Scaleway's monthly Kubernetes newsletter. For the best Kubernetes news in your inbox every month, subscribe today!

Hello lovely subscribers!

It’s been something of a quiet month in the Kubernetes world (is such a thing even possible?) as we all recover from a hectic April. Nonetheless, we’ve got a round-up of news and tidbits for you to enjoy on your coffee break.

With version 1.27 having been released last month, Google’s Kubernetes Podcast interviewed Xander Grzywisnk, the release lead for 1.27. If you want to know all about the ins and outs of complex software releases, give it a listen.

Kubernetes v1.27.2 was released on the 17th March! As a patch, it’s mostly bug fixes and error handling updates; no major feature releases, but plenty of quality-of-life upgrades. You can read about each of them in more detail on the official K8s blog.

Toronto celebrated its first KubeHuddle on the 17th and 18th, bringing together speakers and community members from around the world. KubeHuddle is a community-run conference series which began in Edinburgh last year, aiming to provide a space for beginners and experts alike to share knowledge and make connections.

For anyone who’d like to get in on all the conference hype without leaving the comfort of your own home, PlatformCon is fast approaching! On the 8th and 9th of June you’ll be able to see talks from DevOps and platform engineering leaders; it’s completely free and completely virtual. What’s not to love?

As for in-person conferences, our very own Devrel team will be off to DevOpsDays Amsterdam in June! We’re looking forward to seeing some awesome talks, meeting colleagues from across the industry, and making new friends. If you’ll be there, let us know so we can keep an eye out!

As always, we’ve attached this month’s crossword. This one is cryptic, but you can pester me on Twitter for hints!

May your CI pipelines never fail,

Yours,

Eli & the rest of the Scaleway team

p.s. Here’s this month’s cryptic crossword!