Hextra theme (#1)
* Adapt theme * Update Contents to match with new theme * chore: few updates * adapt HomePage * Add icons and french version * fix fr homepage * Fix Netlab view * Fix Netlab articles * devpod post * French version of DevPod * my_first_lab
BIN
content/documentation/VXLAN/Beginners/media_layers.png
Normal file
|
After Width: | Height: | Size: 28 KiB |
BIN
content/documentation/VXLAN/Beginners/transports.png
Normal file
|
After Width: | Height: | Size: 29 KiB |
151
content/documentation/VXLAN/Beginners/vxlan-for-beginners.fr.md
Normal file
@@ -0,0 +1,151 @@
|
||||
---
|
||||
title: "VXLAN pour les débutants"
|
||||
date: 2024-08-01T20:00:00+02:00
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
## Comprendre VLAN et VXLAN : Simplifié pour les non-techniciens
|
||||
|
||||
Dans le monde rapide de la technologie, comprendre les concepts de réseau peut être intimidant, surtout si vous n'êtes pas un expert en la matière.
|
||||
Aujourd'hui, nous allons décomposer deux concepts de réseau importants : **VLAN** et **VXLAN**, en utilisant des analogies simples et des explications claires.
|
||||
Nous aborderons également leurs limites, leurs cas d’usage concrets, ainsi que quelques notions techniques pour les plus curieux.
|
||||
|
||||
Allons-y ! 🚀
|
||||
|
||||
## Qu'est-ce qu'un VLAN ? 🏢
|
||||
|
||||
**VLAN (Virtual Local Area Network)**, ou Réseau Local Virtuel, c'est comme organiser un grand immeuble de bureaux avec plusieurs départements : Marketing, Ventes, RH, et Informatique. Pour maintenir l'ordre, chaque département obtient son propre étage. De cette manière, les personnes du Marketing restent à leur étage, celles des Ventes au leur, et ainsi de suite.
|
||||
|
||||
Un **VLAN** fonctionne de manière similaire pour les réseaux informatiques. Il divise un grand réseau physique en réseaux plus petits et isolés. Chaque VLAN est comme un étage séparé pour un département, permettant aux dispositifs au sein du même VLAN de communiquer facilement, tout en gardant le trafic séparé des autres VLAN.
|
||||
|
||||
### Points clés sur le VLAN ✅
|
||||
|
||||
- **Séparation :** Garde les différents groupes (comme les départements) séparés.
|
||||
- **Efficacité :** Réduit le trafic inutile et les potentiels problèmes de réseau.
|
||||
- **Sécurité :** Limite l'accès et renforce la sécurité en isolant les groupes.
|
||||
|
||||
### Limites du VLAN ⚠️
|
||||
|
||||
- **Limite d’ID :** Historiquement, un VLAN est identifié sur 12 bits, permettant jusqu’à 4094 VLANs (de 1 à 4094). Pour une grande entreprise ou un datacenter, cela peut s’avérer insuffisant.
|
||||
- **Isolation locale :** Les VLANs sont plutôt conçus pour un usage local (un même site ou un ensemble de switches connectés localement). Dès qu’on veut étendre ce concept à plusieurs sites, on a besoin de solutions plus avancées.
|
||||
|
||||
## Qu'est-ce que le VXLAN ? 🌆
|
||||
|
||||
**VXLAN (Virtual Extensible LAN)** va plus loin. Imaginez que votre entreprise grandisse et s'étende à plusieurs immeubles à travers la ville. Vous voulez toujours que les départements se sentent comme s'ils étaient sur leurs propres étages, même s'ils sont maintenant répartis dans différents endroits. Pour ce faire, vous créez un système virtuel qui connecte tous les étages à travers les bâtiments, de sorte que le Marketing au 3e étage d'un bâtiment soit toujours virtuellement connecté au Marketing du 3e étage d'un autre bâtiment.
|
||||
|
||||
Le **VXLAN** fait cela pour les réseaux. Il étend les VLANs à travers plusieurs emplacements physiques en utilisant une technique appelée **tunneling**. Ainsi, les dispositifs dans le même VLAN peuvent communiquer comme s'ils étaient sur le même réseau local, même s'ils sont éloignés géographiquement.
|
||||
|
||||
### Points clés sur le VXLAN ⭐
|
||||
|
||||
- **Évolutivité :** Étend les réseaux à différents emplacements, et dépasse la limite de 4094 VLANs.
|
||||
- **Flexibilité :** Permet des conceptions de réseau plus grandes et dynamiques.
|
||||
- **Connectivité :** Assure une communication fluide à travers des réseaux dispersés.
|
||||
|
||||
## Plongée technique dans le VXLAN 🔍
|
||||
|
||||
Le **VXLAN** a été développé pour répondre aux limites des VLANs traditionnels (scalabilité, étendue géographique). Il utilise un identifiant de réseau VXLAN (**VNI**) de 24 bits pour identifier jusqu'à **16 millions** de segments logiques, surpassant ainsi largement la limite de 4094 VLANs.
|
||||
|
||||
En raison de la virtualisation, les tables d'adresses MAC dans les datacenters peuvent devenir très grandes, tandis que les switches physiques ont des capacités limitées. Le VXLAN répond à ce défi en utilisant l’encapsulation **MAC-in-UDP**, permettant de transporter des trames Ethernet (couche 2) à travers un réseau IP (couche 3).
|
||||
|
||||
### Comment ça marche ? 🤔
|
||||
|
||||
L’objectif du **VXLAN** est de **prolonger la couche 2** à travers un réseau de couche 3 (IP). Cela revient à « tromper » la couche 3 pour faire croire à l’utilisateur ou à la machine virtuelle qu’il est toujours dans le même réseau local (couche 2).
|
||||
|
||||
> **En clair :** On encapsule les trames Ethernet (couche 2) dans un paquet UDP (couche 4), lui-même transporté par IP (couche 3).
|
||||
|
||||

|
||||
|
||||
> [!NOTE]**Les couches “matérielles”**
|
||||
>
|
||||
> - La couche **Liaison (2)** est communément gérée par des switches.
|
||||
> - La couche **Réseau (3)** est communément gérée par des routeurs.
|
||||
|
||||
En encapsulant la couche 2 dans la couche 3, on profite des avantages du routage IP (souplesse, scalabilité) tout en conservant l’isolation et la simplicité de la couche 2 pour les applications et machines virtuelles.
|
||||
|
||||
### VXLAN expliqué par l’analogie du transport de conteneurs 🚚 🚂
|
||||
|
||||
#### 1. Les camions (couches basses)
|
||||
|
||||
Imaginez des camions sur la route. Leur mission est d’acheminer des conteneurs (vos données) d’un point A à un point B. Ces camions représentent la **couche Ethernet** (niveau 2), où chaque véhicule (frame) possède une « plaque d’immatriculation » (adresse MAC).
|
||||
|
||||
#### 2. Le train (tunnel VXLAN)
|
||||
|
||||
Quand il s’agit de couvrir de plus longues distances ou de traverser des infrastructures variées, charger les camions sur un train devient plus efficace. Ici, **le train représente VXLAN** : il encapsule les camions (frames Ethernet) dans un wagon (le tunnel). Chaque train est identifié par un **VNI (VXLAN Network Identifier)**, un peu comme un numéro de convoi pour chaque ligne de fret.
|
||||
|
||||
#### 3. Les voies ferrées (réseau IP)
|
||||
|
||||
Le train roule sur des rails (le **réseau IP**, couche 3). Les voies ferrées sont déjà construites et gérées pour trouver le meilleur itinéraire : elles assurent la convergence des routes et peuvent rediriger le trafic en cas de problème (panne, congestion, etc.). De la même façon, le réseau IP choisit automatiquement le chemin le plus optimal pour transporter les paquets VXLAN.
|
||||
|
||||
### Points clés à retenir
|
||||
|
||||
- **Superposition (Overlay)** : VXLAN est un système de transport « par-dessus » la couche 3 (les rails). Il permet d’interconnecter plusieurs réseaux de niveau 2 (les camions) comme s’ils n’en formaient qu’un seul.
|
||||
- **Double adressage** :
|
||||
- Les camions (frames Ethernet) s’identifient via des **adresses MAC** (plaque d’immatriculation).
|
||||
- Le train (tunnel VXLAN) utilise les **adresses IP** (plan de route) pour circuler sur les rails.
|
||||
- **Isolation et segmentation** : Comme plusieurs trains peuvent rouler sur la même ligne ferroviaire, il est possible d’exploiter différents tunnels VXLAN (chacun avec son VNI) sur la même infrastructure IP.
|
||||
- **Élasticité et fiabilité** : En s’appuyant sur la couche 3, VXLAN profite de toutes les optimisations du routage IP (recalcul d’itinéraires, tolérance aux pannes, etc.).
|
||||
|
||||

|
||||
|
||||
## Cas d'usage concrets 🏭
|
||||
|
||||
- **Multi-datacenter :** Pour connecter plusieurs centres de données géographiquement dispersés, tout en gardant la sensation d’un réseau unique au niveau 2.
|
||||
- **Cloud hybride :** Étendre un réseau d’entreprise vers un fournisseur de cloud public ou privé sans reconfigurer tout le plan d’adressage.
|
||||
- **Migration de machines virtuelles :** Permettre la migration (VM Mobility) entre sites distants sans perdre la connectivité de couche 2.
|
||||
- **Virtualisation massive :** Dans les environnements très denses (par ex. des centaines de milliers de machines virtuelles), l’identifiant VNI de 24 bits est indispensable.
|
||||
|
||||
## Contrôle du VXLAN : BGP EVPN et autres protocoles 🤝
|
||||
|
||||
Dans les déploiements modernes, surtout en datacenter, le VXLAN n’est pas simplement configuré de manière statique. Il est souvent associé à un **contrôle de plan** via le protocole **BGP EVPN (Ethernet VPN)**.
|
||||
|
||||
- **BGP EVPN :** Permet d’échanger les informations de tables MAC et IP entre les équipements, facilitant l’automatisation et l’évolutivité.
|
||||
- **Autres technologies :** Historiquement, on pouvait croiser d’autres protocoles d’overlay (NVGRE, STT), mais VXLAN s’est imposé comme standard de fait.
|
||||
|
||||
## Considérations de performance ⚙️
|
||||
|
||||
- **Surcharge d’encapsulation :** Le VXLAN ajoute un en-tête supplémentaire (8 octets + en-tête UDP/IP). Cela peut impacter la **taille maximale de trame (MTU)** et il faut souvent configurer un **Jumbo MTU** (généralement 9000 octets) pour éviter la fragmentation des paquets.
|
||||
- **Résilience du réseau IP :** La fiabilité du tunnel VXLAN dépend de la qualité du réseau IP sous-jacent (routes, congestion, etc.).
|
||||
|
||||
## Exemple de configuration (pour les plus curieux) 💡
|
||||
|
||||
Voici un **extrait simplifié** d’une configuration VXLAN sur un équipement Cisco NX-OS (les syntaxes varient selon les constructeurs) :
|
||||
|
||||
```plaintext
|
||||
interface nve1
|
||||
no shutdown
|
||||
source-interface loopback1
|
||||
member vni 5001
|
||||
ingress-replication protocol static
|
||||
mcast-group 239.1.1.1
|
||||
```
|
||||
|
||||
- **interface nve1 :** On crée une interface “NVE” (Network Virtualization Endpoint) pour gérer l'encapsulation VXLAN.
|
||||
- **source-interface loopback1 :** L’adresse IP de l’interface loopback1 sera utilisée pour établir les tunnels.
|
||||
- **member vni 5001 :** On associe un VNI (VXLAN Network Identifier) à notre overlay réseau.
|
||||
|
||||
*Note :* Dans les environnements plus complexes, on configure également le plan de contrôle (par ex. BGP EVPN).
|
||||
|
||||
## En résumé 🎯
|
||||
|
||||
- **VLAN**
|
||||
C’est comme avoir des étages séparés pour différents départements dans un bâtiment, en gardant leurs activités isolées. 🏢
|
||||
\- **Limite majeure** : 4094 VLANs maximum et une portée souvent limitée à un même site.
|
||||
|
||||
- **VXLAN**
|
||||
C’est comme connecter ces étages séparés à travers plusieurs bâtiments, tout en gardant l’illusion qu’ils se trouvent dans un même immeuble. 🌆
|
||||
\- **Avantages clés** : Énorme capacité d’adressage (16 millions de segments), extension L2 sur L3, flexibilité pour la virtualisation et le multi-site.
|
||||
|
||||
Le **VXLAN** répond aux besoins d'isolation à grande échelle, dépasse les limitations des tables d'adresses MAC des commutateurs et permet un déploiement flexible des services. De plus, associé à un plan de contrôle efficace (BGP EVPN), il simplifie grandement la gestion des réseaux modernes en **overlay**.
|
||||
|
||||
### Conclusion 🏁
|
||||
|
||||
En bref, si vous recherchez une **segmentation de base** pour votre réseau local, un **VLAN** est largement suffisant. Mais dès lors que vous voulez relier plusieurs sites, créer un réseau hautement virtualisé, ou dépasser la limite traditionnelle de 4094 VLANs, le **VXLAN** devient incontournable.
|
||||
|
||||
Que vous soyez un passionné de **Lab réseau**, un ingénieur NetOps, ou tout simplement curieux des dessous de l’infrastructure informatique, comprendre ces deux notions vous aidera à mieux appréhender la magie qui se déroule lorsque vos données circulent de plus en plus loin, tout en conservant l’illusion d’être “chez soi” sur le même réseau local !
|
||||
|
||||
> [!TIP] **Envie d’aller plus loin ?**
|
||||
>
|
||||
> - Regardez du côté du **BGP EVPN** pour le plan de contrôle du VXLAN.
|
||||
> - Explorez la **configuration Jumbo MTU** pour optimiser vos performances.
|
||||
> - Comparez VXLAN avec d’autres protocoles (NVGRE, GENEVE) pour comprendre les choix de design réseau.
|
||||
153
content/documentation/VXLAN/Beginners/vxlan-for-beginners.md
Normal file
@@ -0,0 +1,153 @@
|
||||
---
|
||||
title: "VXLAN for Beginners"
|
||||
date: 2024-08-01T20:00:00+02:00
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
## Understanding VLAN and VXLAN: Simplified for Non-Technicians
|
||||
|
||||
In the fast-paced world of technology, understanding networking concepts can be intimidating, especially if you’re not an expert in the field.
|
||||
|
||||
Today, we’ll break down two important network concepts: **VLAN** and **VXLAN**, using simple analogies and clear explanations.
|
||||
|
||||
We’ll also cover their limitations, real-world use cases, and some technical points for the more curious readers.
|
||||
|
||||
Let’s go! 🚀
|
||||
|
||||
## What is a VLAN? 🏢
|
||||
|
||||
**VLAN (Virtual Local Area Network)** is like organizing a large office building with multiple departments: Marketing, Sales, HR, and IT. To keep things orderly, each department gets its own floor. This way, Marketing stays on its floor, Sales stays on theirs, and so on.
|
||||
|
||||
A **VLAN** works similarly for computer networks. It divides a large physical network into smaller, isolated networks. Each VLAN is like a separate floor for a department, allowing devices within the same VLAN to communicate easily while keeping traffic separate from other VLANs.
|
||||
|
||||
### Key points about VLAN ✅
|
||||
|
||||
- **Segregation:** Keeps different groups (like departments) separate.
|
||||
- **Efficiency:** Reduces unnecessary traffic and potential network issues.
|
||||
- **Security:** Limits access and enhances security by isolating groups.
|
||||
|
||||
### VLAN Limitations ⚠️
|
||||
|
||||
- **ID Limit:** Historically, a VLAN is identified by a 12-bit field, allowing up to 4094 VLANs (1 to 4094). For a large company or a datacenter, this might be insufficient.
|
||||
- **Local Isolation:** VLANs are primarily designed for local use (on the same site or a connected set of switches). Extending this concept to multiple sites requires more advanced solutions.
|
||||
|
||||
## What is VXLAN? 🌆
|
||||
|
||||
**VXLAN (Virtual Extensible LAN)** goes further. Imagine your company grows and expands to multiple office buildings across the city. You still want each department to feel as if it’s on its own floor, even though they’re now spread out across different locations. To do this, you create a virtual system that connects all floors across buildings so that Marketing on the 3rd floor of one building is still virtually connected to Marketing on the 3rd floor of another building.
|
||||
|
||||
**VXLAN** does this for networks. It extends VLANs across multiple physical locations using a technique called **tunneling**. This allows devices in the same VLAN to communicate as if they were on the same local network, even if they’re geographically distant.
|
||||
|
||||
### Key points about VXLAN ⭐
|
||||
|
||||
- **Scalability:** Extends networks to different locations and surpasses the 4094 VLAN limit.
|
||||
- **Flexibility:** Enables larger, more dynamic network designs.
|
||||
- **Connectivity:** Ensures seamless communication across dispersed networks.
|
||||
|
||||
## Technical Dive into VXLAN 🔍
|
||||
|
||||
**VXLAN** was developed to address the limitations of traditional VLANs (scalability, geographic reach). It uses a **VNI** (VXLAN Network Identifier) with 24 bits to identify up to **16 million** logical segments, far exceeding the 4094 VLAN limit.
|
||||
|
||||
Due to virtualization, MAC address tables in datacenters can grow very large, while physical switches have limited capacity. VXLAN addresses this challenge by using **MAC-in-UDP** encapsulation, allowing Ethernet frames (Layer 2) to be transported over an IP network (Layer 3).
|
||||
|
||||
### How does it work? 🤔
|
||||
|
||||
The goal of **VXLAN** is to **extend Layer 2** across a Layer 3 (IP) network. Essentially, it “tricks” Layer 3 into believing that the user or virtual machine is still on the same local (Layer 2) network.
|
||||
|
||||
> **In simple terms:** Ethernet frames (Layer 2) are encapsulated inside a UDP packet (Layer 4), which is then carried by IP (Layer 3).
|
||||
|
||||

|
||||
|
||||
> [!NOTE] **The “Physical” Layers**
|
||||
>
|
||||
> - The **Link Layer (Layer 2)** is typically managed by switches.
|
||||
> - The **Network Layer (Layer 3)** is typically managed by routers.
|
||||
|
||||
By encapsulating Layer 2 inside Layer 3, you benefit from the advantages of IP routing (flexibility, scalability) while preserving the isolation and simplicity of Layer 2 for applications and virtual machines.
|
||||
|
||||
### VXLAN Explained by the Container Transport Analogy 🚚 🚂
|
||||
|
||||
#### 1. Trucks (lower layers)
|
||||
|
||||
Imagine trucks on the road. Their job is to transport containers (your data) from Point A to Point B. These trucks represent the **Ethernet layer** (Layer 2), where each vehicle (frame) has a “license plate” (MAC address).
|
||||
|
||||
#### 2. The Train (VXLAN tunnel)
|
||||
|
||||
When it’s time to travel longer distances or through different infrastructures, loading the trucks onto a train becomes more efficient. Here, **the train represents VXLAN**: it encapsulates the trucks (Ethernet frames) into a wagon (the tunnel). Each train is identified by a **VNI (VXLAN Network Identifier)**, much like a convoy number for each freight line.
|
||||
|
||||
#### 3. The Railway Tracks (IP network)
|
||||
|
||||
The train runs on rails (the **IP network**, Layer 3). The railroad is already built and managed to find the best path; it ensures route convergence and can reroute traffic in case of issues (breakdowns, congestion, etc.). Similarly, the IP network automatically selects the optimal path to transport VXLAN packets.
|
||||
|
||||
### Key Takeaways
|
||||
|
||||
- **Overlay:** VXLAN is a transport system “on top of” Layer 3 (the rails). It interconnects multiple Layer 2 networks (the trucks) as if they were just one.
|
||||
- **Dual Addressing:**
|
||||
- Trucks (Ethernet frames) are identified by **MAC addresses** (license plates).
|
||||
- The train (VXLAN tunnel) uses **IP addresses** (routing plans) to travel on the rails.
|
||||
- **Isolation and Segmentation:** Just like multiple trains can run on the same railway line, you can have several VXLAN tunnels (each with its own VNI) over the same IP infrastructure.
|
||||
- **Elasticity and Reliability:** By relying on Layer 3, VXLAN takes advantage of all IP routing optimizations (route recalculations, fault tolerance, etc.).
|
||||
|
||||

|
||||
|
||||
## Real-World Use Cases 🏭
|
||||
|
||||
- **Multi-datacenter:** For connecting multiple geographically dispersed data centers while preserving the feel of a single Layer 2 network.
|
||||
- **Hybrid Cloud:** Extending a corporate network to a public or private cloud provider without reconfiguring the entire address plan.
|
||||
- **Virtual Machine Migration:** Enabling VM mobility between distant sites without losing Layer 2 connectivity.
|
||||
- **Massive Virtualization:** In highly dense environments (e.g., hundreds of thousands of virtual machines), the 24-bit VNI is indispensable.
|
||||
|
||||
## VXLAN Control: BGP EVPN and Other Protocols 🤝
|
||||
|
||||
In modern deployments, especially in data centers, VXLAN isn’t just configured statically. It’s often paired with a **control plane** via **BGP EVPN (Ethernet VPN)**.
|
||||
|
||||
- **BGP EVPN:** Exchanges MAC and IP table information between devices, facilitating automation and scalability.
|
||||
- **Other Technologies:** Historically, other overlay protocols (NVGRE, STT) existed, but VXLAN has become the de facto standard.
|
||||
|
||||
## Performance Considerations ⚙️
|
||||
|
||||
- **Encapsulation Overhead:** VXLAN adds an extra header (8 bytes + UDP/IP header). This can affect the **Maximum Transmission Unit (MTU)** size, often requiring **Jumbo MTU** (usually 9000 bytes) to avoid packet fragmentation.
|
||||
- **Resilience of the IP Network:** The tunnel’s reliability depends on the underlying IP network’s quality (routes, congestion, etc.).
|
||||
|
||||
## Example Configuration (for the curious) 💡
|
||||
|
||||
Below is a **simplified excerpt** of a VXLAN configuration on a Cisco NX-OS device (syntax can vary by vendor):
|
||||
|
||||
```plaintext
|
||||
interface nve1
|
||||
no shutdown
|
||||
source-interface loopback1
|
||||
member vni 5001
|
||||
ingress-replication protocol static
|
||||
mcast-group 239.1.1.1
|
||||
```
|
||||
|
||||
- **interface nve1:** Creates an “NVE” (Network Virtualization Endpoint) interface to handle VXLAN encapsulation.
|
||||
- **source-interface loopback1:** The IP address of loopback1 is used to establish tunnels.
|
||||
- **member vni 5001:** Associates a specific VXLAN Network Identifier (VNI) with the overlay network.
|
||||
|
||||
*Note:* In more complex environments, the control plane (e.g., BGP EVPN) is also configured.
|
||||
|
||||
## Summary 🎯
|
||||
|
||||
- **VLAN**
|
||||
It’s like having separate floors for different departments in a building, keeping their activities isolated. 🏢
|
||||
\- **Major limitation:** A maximum of 4094 VLANs and scope often limited to a single site.
|
||||
|
||||
- **VXLAN**
|
||||
It’s like connecting those separate floors across multiple buildings while maintaining the illusion they’re in one building. 🌆
|
||||
\- **Key advantages:** Huge addressing capability (16 million segments), L2 extension over L3, flexibility for virtualization and multi-site.
|
||||
|
||||
**VXLAN** addresses the need for large-scale isolation, overcomes the limitations of switch MAC address tables, and allows for flexible deployment of services. Paired with an efficient control plane (BGP EVPN), it greatly simplifies the management of modern overlay networks.
|
||||
|
||||
### Conclusion 🏁
|
||||
|
||||
In short, if you need **basic segmentation** for your local network, **VLAN** is more than enough. But as soon as you want to connect multiple sites, build a highly virtualized network, or exceed the traditional 4094 VLAN limit, **VXLAN** becomes essential.
|
||||
|
||||
Whether you’re a **network lab** enthusiast, a NetOps engineer, or simply curious about the underlying infrastructure, understanding these two concepts will help you better grasp the magic that happens when your data travels farther and farther while preserving the illusion of being “at home” on the same local network!
|
||||
|
||||
> [!TIP] **Want to learn more?**
|
||||
>
|
||||
> - Check out **BGP EVPN** for VXLAN’s control plane.
|
||||
> - Look into **Jumbo MTU configuration** to optimize performance.
|
||||
> - Compare VXLAN with other protocols (NVGRE, GENEVE) to understand network design choices.
|
||||
0
content/documentation/VXLAN/_index.fr.md
Normal file
0
content/documentation/VXLAN/_index.md
Normal file
16
content/documentation/_index.fr.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Documentation
|
||||
cascade:
|
||||
type: docs
|
||||
|
||||
---
|
||||
<!-- markdownlint-disable MD033 MD034-->
|
||||
|
||||
{{< hextra/hero-subtitle >}}
|
||||
Documentation complète et guides pratiques étape par étape
|
||||
{{< /hextra/hero-subtitle >}}
|
||||
|
||||
{{< cards >}}
|
||||
{{< card link="https://containerlab.dev/install/" title="ContainerLab" subtitle="Comment Installer ContainerLab" icon="endpoints" >}}
|
||||
{{< card link="https://devpod.sh" title="DevPod" subtitle="Une manière simple de déployer Lab" icon="git" >}}
|
||||
{{< /cards >}}
|
||||
16
content/documentation/_index.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Documentation
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
<!-- markdownlint-disable MD033 MD034-->
|
||||
|
||||
{{< hextra/hero-subtitle >}}
|
||||
Comprehensive Documentation and Step-by-Step "How-To" Guides
|
||||
{{< /hextra/hero-subtitle >}}
|
||||
|
||||
{{< cards >}}
|
||||
{{< card link="https://containerlab.dev/install/" title="ContainerLab" subtitle="How to install ContainerLab" icon="endpoints" >}}
|
||||
{{< card link="https://devpod.sh" title="DevPod" subtitle="Easy way to deploy Lab" icon="git" >}}
|
||||
{{< /cards >}}
|
||||
317
content/documentation/devpod/_index.fr.md
Normal file
@@ -0,0 +1,317 @@
|
||||
---
|
||||
title: "DevPod sur AWS"
|
||||
date: 2025-02-11T20:00:00+02:00
|
||||
weight: 1
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
## Sources
|
||||
|
||||
- [DevPod](https://devpod.sh/docs/what-is-devpod) ⚙️
|
||||
- [DevContainer](https://containers.dev) 🐳
|
||||
|
||||
## Introduction 🚀
|
||||
|
||||
Dans cet article, je souhaite présenter un outil fantastique qui fait partie de la même famille que GitPod et Codespaces : **DevPod** ! Il vous permet de créer des environnements de développement sans effort — sans se retrouver bloqué par un fournisseur. 🔒❌
|
||||
|
||||
DevPod est basé sur l'architecture **DevContainer** et utilise les spécifications contenues dans un fichier [devcontainer.json](https://containers.dev) pour lancer votre environnement de développement. Personnellement, je l'utilise pour déployer rapidement des maquette réseau avec ContainerLab. 💻🧰
|
||||
|
||||
## Qu'est-ce qu'un DevContainer ? 🤔
|
||||
|
||||
Un conteneur de développement (souvent appelé « dev container ») vous permet d'utiliser un conteneur comme un environnement de développement complet. (Consultez la documentation officielle de [containers.dev](https://containers.dev) pour plus de détails.)
|
||||
|
||||
Décomposons cela :
|
||||
|
||||
Avez-vous déjà entendu l'expression « Ça marche sur ma machine » ? Si vous êtes développeur, vous avez sans doute rencontré ce problème en collaborant avec d'autres. Mais devinez quoi ? Les **DevContainers** résolvent le problème de la dérive des environnements en fournissant des environnements Docker cohérents et reproductibles. Adieu les maux de tête liés à l'installation ! 💆♀️
|
||||
|
||||
Avec les DevContainers, il vous suffit de :
|
||||
|
||||
1. Un dossier `.devcontainer` dans votre projet.
|
||||
2. Un fichier `devcontainer.json` qui indique à VS Code comment configurer le conteneur.
|
||||
3. Docker installé localement
|
||||
|
||||
La pierre angulaire du DevContainer est le fichier `devcontainer.json`. Par exemple :
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "Python DevContainer",
|
||||
"image": "mcr.microsoft.com/devcontainers/python:3.10",
|
||||
"features": {
|
||||
"docker-in-docker": "latest"
|
||||
},
|
||||
"extensions": [
|
||||
"ms-python.python",
|
||||
"ms-azuretools.vscode-docker"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**Que se passe-t-il ici ?** 🕵️♀️
|
||||
|
||||
- **"image"** – Cela utilise un environnement Python 3.10 prêt à l'emploi.
|
||||
- **"features"** – Cela ajoute la prise en charge de Docker dans le conteneur.
|
||||
- **"extensions"** – Installe des extensions utiles pour Python et Docker dans VS Code.
|
||||
|
||||
Les DevContainers sont formidables pour le développement local, mais parfois vous avez besoin de plus de puissance — peut-être que vos charges de travail sont énormes, ou que vous souhaitez exécuter des laboratoires spécialisés. C'est là qu'intervient **DevPod**. 💪
|
||||
**Pour pouvoir déployer facilement des laboratoires sur le Cloud**
|
||||
|
||||
## Qu'est-ce que DevPod ? 🤖
|
||||
|
||||
**DevPod** est un outil open-source qui vous permet de lancer des environnements de développement soit sur votre machine locale, soit dans le cloud de votre choix. Imaginez une version auto-hébergée et ultra-personnalisable de GitHub Codespaces. 🎉
|
||||
|
||||
Dans mes aventures quotidiennes en réseau, je déploie des configurations basées sur ContainerLab avec des DevContainers sur AWS. Voyons comment vous pouvez utiliser DevPod pour faire exactement cela (les détails sur ContainerLab suivront dans un autre article, promis !). 😜
|
||||
|
||||
## Fournisseur AWS 🌐
|
||||
|
||||
DevPod utilise des **Providers** (fournisseurs), qui sont des modules de configuration définissant où et comment DevPod lance votre environnement. Voici la liste des fournisseurs :
|
||||
|
||||

|
||||
|
||||
Nous allons nous concentrer sur le **Provider AWS** — bien qu'il existe de nombreuses options de configuration :
|
||||
|
||||

|
||||
|
||||
Avant de paniquer devant tous ces réglages, ne vous inquiétez pas. Si vous ne faites que quelques expérimentations, les valeurs par défaut conviennent généralement. 🙌
|
||||
|
||||
> [!NOTE] **Les avantages de l'open-source** 🎁
|
||||
>
|
||||
> Le fait que DevPod soit open-source signifie que vous pouvez jeter un œil sous le capot pour voir exactement comment il fonctionne. Consultez le code AWS [ici](https://github.com/loft-sh/devpod-provider-aws/tree/main) si vous êtes curieux.
|
||||
|
||||
## Fonctionnement du code AWS
|
||||
|
||||
Examinons ce que fait DevPod sur AWS en regardant le [code aws.go](https://github.com/loft-sh/devpod-provider-aws/blob/main/pkg/aws/aws.go). À un niveau global, il gère :
|
||||
|
||||
1. **Initialisation** : Lecture de la configuration et mise en place des clients du SDK AWS (avec des identifiants personnalisés si nécessaire).
|
||||
2. **Réseautage** : Recherche ou création du sous-réseau, VPC et groupes de sécurité appropriés.
|
||||
3. **Sélection de l'AMI** : Choix d'une AMI adaptée (par défaut, une image Ubuntu 22.04 récente) et détermination du périphérique racine.
|
||||
4. **Configuration IAM** : Vérification qu'un rôle d'instance approprié et un profil d'instance existent, avec les politiques associées.
|
||||
5. **Cycle de vie de l'instance** : Création, démarrage, arrêt, vérification du statut et suppression des instances.
|
||||
6. **Injection de données utilisateur** : Génération d'un script (encodé en Base64) qui configure l'instance (ajoute des utilisateurs et des clés SSH) au premier démarrage.
|
||||
7. **DNS optionnel** : Gestion des enregistrements Route 53 pour l'instance si la configuration l'exige.
|
||||
|
||||
De mon point de vue, deux points se distinguent comme étant potentiellement les plus critiques :
|
||||
|
||||
- **(#4) Configuration IAM**
|
||||
- **(#6) Injection de données utilisateur**
|
||||
|
||||
### Pourquoi les points #4 et #6 sont-ils « délicats » ?
|
||||
|
||||
- **Configuration IAM** est principalement gérée par la fonction `CreateDevpodInstanceProfile`. Elle crée un rôle nommé `devpod-ec2-role` qui peut effectuer les opérations suivantes :
|
||||
- **Opérations EC2** : Par exemple, il peut décrire ou arrêter des instances — en particulier l'instance qui lui est associée.
|
||||
- **Opérations SSM** : En attachant la politique AmazonSSMManagedInstanceCore, l'instance peut être gérée par AWS Systems Manager.
|
||||
- **Opérations KMS (optionnel)** : Si configuré, il peut exécuter `kms:Decrypt` sur une clé KMS spécifique, ce qui est utile pour gérer les données de session ou les secrets.
|
||||
|
||||
- **Injection de données utilisateur** est essentiellement un script de démarrage inséré dans l'instance sous forme de Base64. Ce script configure un utilisateur `devpod` avec des droits sudo, crée les dossiers SSH et insère votre clé publique dans le fichier approprié. Dans le code, [cela ressemble à](https://github.com/loft-sh/devpod-provider-aws/blob/9d2730c34ecee40cb42596c602381b92ad9c6682/pkg/aws/aws.go#L967-L980) :
|
||||
|
||||
```bash
|
||||
useradd devpod -d /home/devpod
|
||||
mkdir -p /home/devpod
|
||||
if grep -q sudo /etc/groups; then
|
||||
usermod -aG sudo devpod
|
||||
elif grep -q wheel /etc/groups; then
|
||||
usermod -aG wheel devpod
|
||||
fi
|
||||
|
||||
echo "devpod ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/91-devpod
|
||||
mkdir -p /home/devpod/.ssh
|
||||
echo " + string(publicKey) + " >> /home/devpod/.ssh/authorized_keys
|
||||
chmod 0700 /home/devpod/.ssh
|
||||
chmod 0600 /home/devpod/.ssh/authorized_keys
|
||||
chown -R devpod:devpod /home/devpod
|
||||
```
|
||||
|
||||
Comme DevPod est open-source, vous pouvez facilement vérifier par vous-même. C'est un excellent outil d'apprentissage si vous souhaitez comprendre tous les rouages ! 🔩
|
||||
|
||||
## Rôles et politiques IAM
|
||||
|
||||
Vous devrez créer un utilisateur IAM et lui attacher une politique IAM qui accorde juste assez de permissions pour DevPod. Par exemple :
|
||||
|
||||
- **Actions EC2 :**
|
||||
- Description : `ec2:DescribeSubnets`, `ec2:DescribeVpcs`, `ec2:DescribeImages`, `ec2:DescribeInstances`, `ec2:DescribeSecurityGroups`
|
||||
- Gestion des instances : `ec2:RunInstances`, `ec2:StartInstances`, `ec2:StopInstances`, `ec2:TerminateInstances`, `ec2:CancelSpotInstanceRequests`
|
||||
- Groupes de sécurité & Tags : `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTags`
|
||||
- **Actions IAM :**
|
||||
- `iam:GetInstanceProfile`, `iam:CreateRole`, `iam:PutRolePolicy`, `iam:AttachRolePolicy`, `iam:CreateInstanceProfile`, `iam:AddRoleToInstanceProfile`
|
||||
- **Route 53 (optionnel) :**
|
||||
- `route53:ListHostedZones`, `route53:GetHostedZone`, `route53:ChangeResourceRecordSets`
|
||||
|
||||
## Configuration AWS 🏗️
|
||||
|
||||
J'utilise généralement la console web AWS pour configurer cela, mais vous pouvez tout à fait le faire via la CLI.
|
||||
|
||||
### Étape 1 : Connectez-vous à la console AWS
|
||||
|
||||
1. Rendez-vous sur [AWS Management Console](https://aws.amazon.com/console/).
|
||||
2. Utilisez un compte disposant des droits appropriés pour créer des ressources IAM.
|
||||
|
||||
### Étape 2 : Créer une politique IAM personnalisée
|
||||
|
||||
#### **A. Accédez à la console IAM**
|
||||
|
||||
- Dans le menu AWS, trouvez **IAM**.
|
||||
|
||||
#### **B. Créer une nouvelle politique**
|
||||
|
||||
1. Cliquez sur **Policies** dans le menu de gauche.
|
||||
2. Cliquez sur **Create policy**.
|
||||
|
||||
#### **C. Passez à l'onglet JSON**
|
||||
|
||||
- Collez quelque chose comme ceci, en ajustant si nécessaire :
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Actions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeInstances",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:RunInstances",
|
||||
"ec2:StartInstances",
|
||||
"ec2:StopInstances",
|
||||
"ec2:TerminateInstances",
|
||||
"ec2:CancelSpotInstanceRequests",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteTags"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMActions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:CreateRole",
|
||||
"iam:PutRolePolicy",
|
||||
"iam:AttachRolePolicy",
|
||||
"iam:CreateInstanceProfile",
|
||||
"iam:AddRoleToInstanceProfile"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "Route53Actions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"route53:ListHostedZones",
|
||||
"route53:GetHostedZone",
|
||||
"route53:ChangeResourceRecordSets"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- Cliquez sur **Next** (les tags sont optionnels), puis sur **Next: Review**.
|
||||
|
||||
#### **D. Vérifier et créer**
|
||||
|
||||
1. Nommez-la `DevpodToolPolicy` (ou comme vous le souhaitez).
|
||||
2. Ajoutez une description facultative.
|
||||
3. Cliquez sur **Create policy**.
|
||||
|
||||
### Étape 3 : Créer ou mettre à jour l'utilisateur IAM
|
||||
|
||||
#### **A. Créer un nouvel utilisateur (si nécessaire)**
|
||||
|
||||
1. Cliquez sur **Users** dans IAM.
|
||||
2. Cliquez sur **Add user**.
|
||||
3. Donnez-lui un nom (par exemple, `devpod-tool-user`).
|
||||
4. Choisissez **Programmatic access** si vous souhaitez un accès via la CLI. 🤖
|
||||
5. Cliquez sur **Next**.
|
||||
|
||||
#### **B. Attacher votre nouvelle politique**
|
||||
|
||||
1. Sur la page des permissions, choisissez **Attach policies directly**.
|
||||
2. Cochez `DevpodToolPolicy`.
|
||||
3. Cliquez sur **Create**.
|
||||
4. Et voilà !
|
||||
|
||||
### Étape 4 : Vérifier et c'est fini
|
||||
|
||||
Retournez dans **Users** → **devpod-tool-user** → **Permissions** pour confirmer que `DevpodToolPolicy` est bien attachée. ✅
|
||||
|
||||
### Étape 5 : Utilisez ces identifiants
|
||||
|
||||
- Si vous avez créé un utilisateur programmatique, n'oubliez pas de noter l'**Access Key ID** et le **Secret Access Key**.
|
||||
|
||||

|
||||
|
||||
**Bonus** : Notez votre **ID VPC** (dans la section VPC sur AWS). Vous en aurez besoin lors de la configuration de DevPod.
|
||||
|
||||
## Configurer DevPod 🛠️
|
||||
|
||||
### 1. Configurer le profil AWS
|
||||
|
||||
```bash
|
||||
aws configure --profile Devpod
|
||||
```
|
||||
|
||||
Lorsqu'on vous le demande :
|
||||
|
||||
1. L'Access Key ID
|
||||
2. Le Secret Access Key
|
||||
3. La région par défaut (par exemple, `eu-west-1`)
|
||||
4. Le format de sortie (je le laisse généralement vide)
|
||||
|
||||
### 2. Ajouter le profil à DevPod
|
||||
|
||||
1. Dans DevPod, créez un nouveau provider et choisissez **AWS**.
|
||||
2. Sélectionnez la **région AWS** (par exemple, `eu-west-1`).
|
||||
3. Développez les options AWS.
|
||||
4. **Taille du disque AWS** : par exemple, 40 GB pour commencer.
|
||||
5. **Type d'instance** : par exemple, `t2.small`.
|
||||
6. **Profil AWS** : sélectionnez `Devpod` (ou le nom que vous avez choisi).
|
||||
7. **ID VPC AWS** : ajoutez votre VPC.
|
||||
8. Vous pouvez laisser le reste par défaut.
|
||||
|
||||
Cliquez sur **Add Provider**.
|
||||
|
||||

|
||||
|
||||
## Tester un déploiement 🧪
|
||||
|
||||
### Déployer
|
||||
|
||||
Nous allons effectuer un test rapide en utilisant l'une des images Docker préconstruites :
|
||||
|
||||
1. Rendez-vous dans **Workspaces** dans DevPod.
|
||||
2. Cliquez sur **Create Workspace**.
|
||||
3. Choisissez votre nouveau provider **AWS**.
|
||||
4. Choisissez votre IDE préféré (VS Code, etc.).
|
||||
5. À droite, sélectionnez un exemple de démarrage rapide (par exemple, Python). 🐍
|
||||
6. Cliquez sur **Create Workspace**.
|
||||
|
||||

|
||||
|
||||
Attendez quelques instants, et votre environnement basé sur le cloud apparaîtra dans VS Code. 🎊
|
||||
|
||||

|
||||
|
||||
### Arrêter
|
||||
|
||||
Lorsque vous n'utilisez pas l'environnement, cliquez sur **Stop** pour éteindre l'instance EC2. Vous ne paierez que pour le stockage — aucun temps de calcul. Idéal pour votre portefeuille. 💰
|
||||
|
||||

|
||||
|
||||
### Supprimer
|
||||
|
||||
Supprimer le workspace supprime toutes les ressources AWS associées à cet environnement, vous ne paierez donc pas un centime. Mais vous devrez redéployer si vous souhaitez l'utiliser à nouveau. ♻️
|
||||
|
||||

|
||||
|
||||
## Conclusion 💡
|
||||
|
||||
En combinant **DevContainers** et **DevPod** sur **AWS**, vous pouvez créer des environnements de développement flexibles et autogérés qui évoluent avec votre croissance — sans être enfermé dans des plateformes spécifiques à un fournisseur. Dites adieu aux problèmes du « Ça marche sur ma machine ! » et accueillez un codage sans friction. 🚀✨
|
||||
|
||||
Amusez-vous bien ! 🎉
|
||||
317
content/documentation/devpod/_index.md
Normal file
@@ -0,0 +1,317 @@
|
||||
---
|
||||
title: "DevPod on AWS"
|
||||
date: 2025-02-11T20:00:00+02:00
|
||||
weight: 1
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
## Sources
|
||||
|
||||
- [DevPod](https://devpod.sh/docs/what-is-devpod) ⚙️
|
||||
- [DevContainer](https://containers.dev) 🐳
|
||||
|
||||
## Introduction 🚀
|
||||
|
||||
In this article, I’d like to showcase a fantastic tool that sits in the same family as GitPod and Codespaces: **DevPod**! It empowers you to create development environments effortlessly—without getting locked into any particular vendor. 🔒❌
|
||||
|
||||
DevPod is based on **DevContainer** architecture and uses the specs found in a [devcontainer.json](https://containers.dev) file to spin up your dev setup. Personally, I love it for quickly and reliably deploying Network Labs with ContainerLab. 💻🧰
|
||||
|
||||
## What a DevContainer Is 🤔
|
||||
|
||||
A development container (often called a “dev container”) lets you use a container as a full-featured dev environment. (Check out the official [containers.dev documentation](https://containers.dev) for more details.)
|
||||
|
||||
Let’s break it down:
|
||||
|
||||
Have you ever heard the phrase “It works on my machine”? If you’re a developer, you’ve probably run headfirst into this problem when collaborating with others. But guess what? **DevContainers** solve the mystery of environment drift by providing consistent, reproducible Docker-based environments. Bye-bye setup headaches! 💆♀️
|
||||
|
||||
Using DevContainers, you just need:
|
||||
|
||||
1. A `.devcontainer` folder in your project.
|
||||
2. A `devcontainer.json` file that tells VS Code how to configure the container.
|
||||
3. Docker installed locally
|
||||
|
||||
The backbone of the DevContainer is the `devcontainer.json` file. For example:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "Python DevContainer",
|
||||
"image": "mcr.microsoft.com/devcontainers/python:3.10",
|
||||
"features": {
|
||||
"docker-in-docker": "latest"
|
||||
},
|
||||
"extensions": [
|
||||
"ms-python.python",
|
||||
"ms-azuretools.vscode-docker"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**What’s happening here?** 🕵️♀️
|
||||
|
||||
- **"image"** – This uses a Python 3.10 environment that’s ready to go.
|
||||
- **"features"** – This adds Docker support inside the container.
|
||||
- **"extensions"** – Installs useful Python and Docker extensions in VS Code.
|
||||
|
||||
DevContainers are awesome for local dev, but sometimes you need more muscle—maybe your workloads are huge, or you want to run specialized labs. That’s where **DevPod** comes in. 💪
|
||||
**To be able to deployed lab easily on Cloud**
|
||||
|
||||
## What DevPod Is 🤖
|
||||
|
||||
**DevPod** is an open-source tool that lets you spin up dev environments either on your local machine or in the cloud of your choice. Imagine a self-hosted, super-customizable version of GitHub Codespaces. 🎉
|
||||
|
||||
In my day-to-day networking escapades, I deploy ContainerLab-based setups with DevContainers on AWS. Let’s see how you can use DevPod to do exactly that (ContainerLab details will follow in another post, I promise!). 😜
|
||||
|
||||
## AWS Provider 🌐
|
||||
|
||||
DevPod uses **Providers**, which are like configuration modules that define where and how DevPod launches your environment. Here’s the Provider list:
|
||||
|
||||

|
||||
|
||||
We’ll focus on the **AWS Provider**—though there are many config options:
|
||||
|
||||

|
||||
|
||||
Before you freak out at all those toggles, don’t worry. If it’s just you tinkering, the defaults are usually fine. 🙌
|
||||
|
||||
> [!NOTE] **Open Source Perks** 🎁
|
||||
>
|
||||
> Being open-source means you can pop the hood and see exactly how DevPod works. Check out the AWS code [here](https://github.com/loft-sh/devpod-provider-aws/tree/main) if you’re curious.
|
||||
|
||||
## How the AWS Code Works
|
||||
|
||||
Let’s break down what DevPod will do on AWS by looking at the [aws.go code](https://github.com/loft-sh/devpod-provider-aws/blob/main/pkg/aws/aws.go). From a high-level, it handles:
|
||||
|
||||
1. **Initialization**: Reading configuration and setting up AWS SDK clients (with custom credentials if needed).
|
||||
2. **Networking**: Finding or creating the appropriate subnet, VPC, and security groups.
|
||||
3. **AMI Selection**: Choosing a suitable AMI (defaulting to a recent Ubuntu 22.04 image) and determining the root device.
|
||||
4. **IAM Setup**: Ensuring an appropriate instance role and instance profile exist, complete with policies.
|
||||
5. **Instance Lifecycle**: Creating, starting, stopping, checking status, and deleting instances.
|
||||
6. **User Data Injection**: Generating a script (embedded as Base64) that configures the instance (sets up users and SSH keys) on first boot.
|
||||
7. **Optional DNS**: Managing Route 53 records for the instance if the configuration calls for it.
|
||||
|
||||
From my perspective, two points stand out as potentially the most critical:
|
||||
|
||||
- **(#4) IAM Setup**
|
||||
- **(#6) User Data Injection**
|
||||
|
||||
### Why are #4 and #6 “Tricky”?
|
||||
|
||||
- **IAM Setup** is primarily handled by the `CreateDevpodInstanceProfile` function. It creates a role named `devpod-ec2-role` that can do the following:
|
||||
- **EC2 Operations**: For example, it can describe or stop instances—particularly the instance associated with itself.
|
||||
- **SSM Operations**: By attaching the AmazonSSMManagedInstanceCore policy, the instance can be managed by AWS Systems Manager.
|
||||
- **KMS Operations (Optional)**: If configured, it can perform `kms:Decrypt` on a specific KMS key, helpful for handling session data or secrets.
|
||||
|
||||
- **User Data Injection** is basically a startup script inserted into the instance as Base64. That script sets up a `devpod` user with sudo rights, creates SSH folders, and plops your public key in place. In the code, [it looks like](https://github.com/loft-sh/devpod-provider-aws/blob/9d2730c34ecee40cb42596c602381b92ad9c6682/pkg/aws/aws.go#L967-L980):
|
||||
|
||||
```bash
|
||||
useradd devpod -d /home/devpod
|
||||
mkdir -p /home/devpod
|
||||
if grep -q sudo /etc/groups; then
|
||||
usermod -aG sudo devpod
|
||||
elif grep -q wheel /etc/groups; then
|
||||
usermod -aG wheel devpod
|
||||
fi
|
||||
|
||||
echo "devpod ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/91-devpod
|
||||
mkdir -p /home/devpod/.ssh
|
||||
echo " + string(publicKey) + " >> /home/devpod/.ssh/authorized_keys
|
||||
chmod 0700 /home/devpod/.ssh
|
||||
chmod 0600 /home/devpod/.ssh/authorized_keys
|
||||
chown -R devpod:devpod /home/devpod
|
||||
```
|
||||
|
||||
Since DevPod is open source, you can easily check this out yourself. It’s a great learning tool if you’re curious about the nuts and bolts! 🔩
|
||||
|
||||
## IAM Roles and Policies
|
||||
|
||||
You’ll need to set up an IAM user and attach an IAM policy that grants just enough permissions for DevPod. For example:
|
||||
|
||||
- **EC2 Actions:**
|
||||
- Describe: `ec2:DescribeSubnets`, `ec2:DescribeVpcs`, `ec2:DescribeImages`, `ec2:DescribeInstances`, `ec2:DescribeSecurityGroups`
|
||||
- Manage Instances: `ec2:RunInstances`, `ec2:StartInstances`, `ec2:StopInstances`, `ec2:TerminateInstances`, `ec2:CancelSpotInstanceRequests`
|
||||
- Security Groups & Tags: `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTags`
|
||||
- **IAM Actions:**
|
||||
- `iam:GetInstanceProfile`, `iam:CreateRole`, `iam:PutRolePolicy`, `iam:AttachRolePolicy`, `iam:CreateInstanceProfile`, `iam:AddRoleToInstanceProfile`
|
||||
- **Route 53 (Optional):**
|
||||
- `route53:ListHostedZones`, `route53:GetHostedZone`, `route53:ChangeResourceRecordSets`
|
||||
|
||||
## AWS Configuration 🏗️
|
||||
|
||||
I typically use the AWS web console to set this up, but you can absolutely do it all via CLI.
|
||||
|
||||
### Step 1: Log in to the AWS Console
|
||||
|
||||
1. Head to [AWS Management Console](https://aws.amazon.com/console/).
|
||||
2. Use an account with the proper rights to create IAM resources.
|
||||
|
||||
### Step 2: Create a Custom IAM Policy
|
||||
|
||||
#### **A. Go to the IAM Console**
|
||||
|
||||
- In the AWS menu, find **IAM**.
|
||||
|
||||
#### **B. Create a New Policy**
|
||||
|
||||
1. Click **Policies** on the left.
|
||||
2. Press **Create policy**.
|
||||
|
||||
#### **C. Switch to the JSON Tab**
|
||||
|
||||
- Paste in something like this, adjusting if needed:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Actions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeInstances",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:RunInstances",
|
||||
"ec2:StartInstances",
|
||||
"ec2:StopInstances",
|
||||
"ec2:TerminateInstances",
|
||||
"ec2:CancelSpotInstanceRequests",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteTags"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMActions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:CreateRole",
|
||||
"iam:PutRolePolicy",
|
||||
"iam:AttachRolePolicy",
|
||||
"iam:CreateInstanceProfile",
|
||||
"iam:AddRoleToInstanceProfile"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "Route53Actions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"route53:ListHostedZones",
|
||||
"route53:GetHostedZone",
|
||||
"route53:ChangeResourceRecordSets"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- Click **Next** (tags optional), then **Next: Review**.
|
||||
|
||||
#### **D. Review and Create**
|
||||
|
||||
1. Name it `DevpodToolPolicy` (or whatever you like).
|
||||
2. Optional description.
|
||||
3. Click **Create policy**.
|
||||
|
||||
### Step 3: Create/Update the IAM User
|
||||
|
||||
#### **A. Create a New User (If Needed)**
|
||||
|
||||
1. Click **Users** in IAM.
|
||||
2. **Add user**.
|
||||
3. Name it (e.g., `devpod-tool-user`).
|
||||
4. Choose **Programmatic access** if you want CLI access. 🤖
|
||||
5. **Next**.
|
||||
|
||||
#### **B. Attach Your New Policy**
|
||||
|
||||
1. On the permissions page, pick **Attach policies directly**.
|
||||
2. Check `DevpodToolPolicy`.
|
||||
3. Click **Create**.
|
||||
4. That’s it!
|
||||
|
||||
### Step 4: Verify & Done
|
||||
|
||||
Head back to **Users** → **devpod-tool-user** → **Permissions** to confirm `DevpodToolPolicy` is attached. ✅
|
||||
|
||||
### Step 5: Use Those Credentials
|
||||
|
||||
- If you created a programmatic user, make sure you note the **Access Key ID** and **Secret Access Key**.
|
||||
|
||||

|
||||
|
||||
**Bonus**: Keep track of your **VPC ID** (under the VPC service in AWS). You’ll need it when setting up DevPod.
|
||||
|
||||
## Configure DevPod 🛠️
|
||||
|
||||
### 1. Configure AWS Profile
|
||||
|
||||
```bash
|
||||
aws configure --profile Devpod
|
||||
```
|
||||
|
||||
When prompted:
|
||||
|
||||
1. Access Key ID
|
||||
2. Secret Access Key
|
||||
3. Default region (e.g., `eu-west-1`)
|
||||
4. Output format (I usually leave it blank.)
|
||||
|
||||
### 2. Add Profile to DevPod
|
||||
|
||||
1. In DevPod, create a new provider and pick **AWS**.
|
||||
2. Select the **AWS region** (e.g., `eu-west-1`).
|
||||
3. Expand AWS options.
|
||||
4. **AWS Disk Size**: maybe 40GB to start.
|
||||
5. **Instance Type**: e.g., `t2.small`.
|
||||
6. **AWS Profile**: select `Devpod` (or the name you chose).
|
||||
7. **AWS VPC ID**: add your VPC.
|
||||
8. You can leave the rest as defaults.
|
||||
|
||||
Click **Add Provider**.
|
||||
|
||||

|
||||
|
||||
## Testing a Deployment 🧪
|
||||
|
||||
### Deploy
|
||||
|
||||
We’ll run a quick test using one of the prebuilt Docker images:
|
||||
|
||||
1. Go to **Workspaces** in DevPod.
|
||||
2. Click **Create Workspace**.
|
||||
3. Pick your new **AWS** provider.
|
||||
4. Choose your preferred IDE (VS Code, etc.).
|
||||
5. On the right, pick a quickstart example (e.g., Python). 🐍
|
||||
6. Click **Create Workspace**.
|
||||
|
||||

|
||||
|
||||
Wait a few moments, and your cloud-based environment will pop up in VS Code. 🎊
|
||||
|
||||

|
||||
|
||||
### Stop
|
||||
|
||||
When you’re not using it, click **Stop** to shut down the EC2 instance. You’ll only pay for storage—no compute time. Great for the wallet. 💰
|
||||
|
||||

|
||||
|
||||
### Delete
|
||||
|
||||
Deleting the workspace removes all AWS resources for that environment, so you won’t pay a dime. But you’ll have to redeploy if you want to use it again. ♻️
|
||||
|
||||

|
||||
|
||||
## Conclusion 💡
|
||||
|
||||
By combining **DevContainers** and **DevPod** on **AWS**, you can build flexible, self-managed dev environments that scale as you grow—without getting boxed in by vendor-specific platforms. Wave goodbye to “It works on my machine!” woes, and say hello to frictionless coding. 🚀✨
|
||||
|
||||
Happy building and exploring! 🎉
|
||||
BIN
content/documentation/devpod/aws_options.png
Normal file
|
After Width: | Height: | Size: 188 KiB |
BIN
content/documentation/devpod/delete_instance.png
Normal file
|
After Width: | Height: | Size: 42 KiB |
BIN
content/documentation/devpod/devpod_user.png
Normal file
|
After Width: | Height: | Size: 186 KiB |
BIN
content/documentation/devpod/new_provider.png
Normal file
|
After Width: | Height: | Size: 117 KiB |
BIN
content/documentation/devpod/new_worskapce.png
Normal file
|
After Width: | Height: | Size: 243 KiB |
BIN
content/documentation/devpod/provider.png
Normal file
|
After Width: | Height: | Size: 184 KiB |
BIN
content/documentation/devpod/stopped_instance.png
Normal file
|
After Width: | Height: | Size: 36 KiB |
BIN
content/documentation/devpod/vscode.png
Normal file
|
After Width: | Height: | Size: 211 KiB |
316
content/documentation/stepca.fr.md
Normal file
@@ -0,0 +1,316 @@
|
||||
---
|
||||
title: "Gestionnaire de Certificats Auto-Hébergé"
|
||||
date: 2024-08-01T20:00:00+02:00
|
||||
weight: 2
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
## 🔗 Sources
|
||||
|
||||
- [📖 Documentation Officielle](https://smallstep.com/docs/tutorials/)
|
||||
- [🛠️ Step-CA en tant que Service systemd](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
|
||||
- [🔐 Gestion des Certificats avec OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)
|
||||
|
||||
## 🤖 À propos de Step-CA
|
||||
|
||||
Step-CA est un ensemble d'outils astucieux développé par Smallstep, une entreprise spécialisée dans la gestion sécurisée des identités et l'automatisation des certificats. 🚀
|
||||
Sa mission ? Simplifier la mise en place et la gestion de vos propres autorités de certification (AC) avec facilité et sécurité !
|
||||
|
||||
### Principales fonctionnalités
|
||||
|
||||
1. **Gestion des Autorités de Certification** 🔑
|
||||
Configurez et gérez facilement vos propres AC. Créez des AC racines et intermédiaires, délivrez des certificats et gérez les révocations comme un pro.
|
||||
|
||||
2. **Gestion Sécurisée des Clés** 🛡️
|
||||
Respecte les bonnes pratiques pour le stockage et la gestion sécurisés des clés, garantissant que vos clés cryptographiques restent protégées contre les accès non autorisés.
|
||||
|
||||
3. **Automatisation et Scalabilité** ⚙️
|
||||
Idéal pour les déploiements de petite à grande envergure. Profitez des API et intégrations qui automatisent la délivrance, le renouvellement et la révocation des certificats pour un cycle de vie sans accrocs.
|
||||
|
||||
4. **Sécurité Renforcée** 🔒
|
||||
Grâce à l'utilisation d'algorithmes et de protocoles cryptographiques modernes, Step-CA prend en charge les certificats X.509 conformes aux normes de l'industrie, offrant un chiffrement robuste et des signatures numériques.
|
||||
|
||||
5. **Intégration avec l'Infrastructure** 🌐
|
||||
S'intègre parfaitement avec vos outils et systèmes existants. Prend en charge diverses méthodes d'authentification telles que nom d'utilisateur/mot de passe, MFA et fournisseurs d'identité externes.
|
||||
|
||||
6. **Auditabilité et Conformité** 📜
|
||||
Avec des capacités complètes de journalisation et d'audit, vous pouvez suivre les activités des certificats et satisfaire aux exigences de conformité en toute simplicité.
|
||||
|
||||
7. **API Conviviales pour les Développeurs** 👩💻👨💻
|
||||
Des API et SDK conçus pour les développeurs facilitent l'intégration de la gestion des certificats dans vos applications et flux de travail personnalisés.
|
||||
|
||||
**En résumé :** Step-CA de Smallstep est conçu pour rendre la gestion des autorités de certification à la fois ludique et sans tracas. Grâce à ses fonctionnalités sécurisées, scalables et conviviales, vous pouvez gérer facilement le cycle de vie de vos certificats tout en protégeant votre infrastructure !
|
||||
|
||||
## 🚀 Installation
|
||||
|
||||
### 🔧 Installation Binaire
|
||||
|
||||
#### 1. Step CLI
|
||||
|
||||
```bash
|
||||
wget https://dl.step.sm/gh-release/cli/docs-cli-install/v0.24.3/step-cli_0.24.3_amd64.deb
|
||||
sudo dpkg -i step-cli_0.24.3_amd64.deb
|
||||
```
|
||||
|
||||
#### 2. Step-CA
|
||||
|
||||
```bash
|
||||
wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_0.24.1_amd64.deb
|
||||
sudo dpkg -i step-ca_0.24.1_amd64.deb
|
||||
```
|
||||
|
||||
#### 3. Création d'un Utilisateur Spécifique
|
||||
|
||||
```bash
|
||||
adduser adminCA
|
||||
```
|
||||
|
||||
#### Configuration
|
||||
|
||||
```bash
|
||||
$ step ca init --password-file=password.txt
|
||||
✔ Type de déploiement : Autonome
|
||||
Quel nom souhaitez-vous donner à votre nouvelle PKI ?
|
||||
✔ (ex. Smallstep) : Lab
|
||||
✔ (ex. ca.example.com[,10.1.2.3,etc.]) : ca.lab.loc, localhost, 192.168.1.101
|
||||
À quelle IP et sur quel port votre nouvelle AC sera-t-elle liée ? (:443 se lie à 0.0.0.0:443). 1.101
|
||||
✔ (ex. :443 ou 127.0.0.1:443) : :443
|
||||
Quel nom souhaitez-vous donner au premier provisionneur de l'AC ?
|
||||
✔ (ex. vous@smallstep.com) : contact@lab.loc
|
||||
Choisissez un mot de passe pour vos clés AC et le premier provisionneur.
|
||||
✔ [laissez vide et nous en générerons un] :
|
||||
|
||||
Génération du certificat racine... fait ! 🎉
|
||||
Génération du certificat intermédiaire... fait ! 🎊
|
||||
|
||||
✔ Certificat racine : /home/adminCA/.step/certs/root_ca.crt
|
||||
✔ Clé privée racine : /home/adminCA/.step/secrets/root_ca_key
|
||||
✔ Empreinte du certificat racine : 7d754397c6897aa87d21e33c64daad7be087dc6fe18bf04627848ae1c8e26a4f
|
||||
✔ Certificat intermédiaire : /home/adminCA/.step/certs/intermediate_ca.crt
|
||||
✔ Clé privée intermédiaire : /home/adminCA/.step/secrets/intermediate_ca_key
|
||||
✔ Dossier de la base de données : /home/adminCA/.step/db
|
||||
✔ Configuration par défaut : /home/adminCA/.step/config/defaults.json
|
||||
✔ Configuration de l'Autorité de Certification : /home/adminCA/.step/config/ca.json
|
||||
|
||||
Votre PKI est prête ! Pour générer des certificats pour des services individuels, consultez `step help ca`.
|
||||
|
||||
💌 **RETROACTION**
|
||||
L'utilitaire step n'est pas instrumenté pour les statistiques d'utilisation. Il ne contacte pas un serveur central. Toutefois, vos retours sont très précieux ! N'hésitez pas à nous écrire à feedback@smallstep.com, rejoindre les Discussions GitHub ou nous rejoindre sur Discord à [https://u.step.sm/discord](https://u.step.sm/discord).
|
||||
```
|
||||
|
||||
Démarrer Step-CA :
|
||||
|
||||
```bash
|
||||
step-ca .step/config/ca.json
|
||||
```
|
||||
|
||||
#### Activer ACME
|
||||
|
||||
```bash
|
||||
$ step ca provisioner add acme --type ACME
|
||||
✔ Configuration de l'AC : /home/adminCA/.step/config/ca.json
|
||||
|
||||
Succès ! La configuration de votre `step-ca` a été mise à jour. Pour prendre en compte la nouvelle configuration, envoyez un SIGHUP (kill -1 <pid>) ou redémarrez le processus step-ca. 🎉
|
||||
```
|
||||
|
||||
#### Exécuter Step-CA en tant que Service systemd
|
||||
|
||||
Créez un fichier :
|
||||
|
||||
```bash
|
||||
vim /etc/systemd/system/step-ca.service
|
||||
```
|
||||
|
||||
Copiez-collez ce qui suit :
|
||||
|
||||
```config
|
||||
[Unit]
|
||||
Description=step-ca
|
||||
After=syslog.target network.target
|
||||
|
||||
[Service]
|
||||
User=adminCA
|
||||
Group=adminCA
|
||||
ExecStart=/bin/sh -c '/bin/step-ca /home/adminCA/.step/config/ca.json --password-file=/home/step/.step/pwd >> /var/log/step-ca/output.log 2>&1'
|
||||
Type=simple
|
||||
Restart=on-failure
|
||||
RestartSec=10
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Créez le répertoire de logs :
|
||||
|
||||
```bash
|
||||
mkdir -p /var/log/step-ca
|
||||
chown -R adminCA:adminCA /var/log/step-ca
|
||||
```
|
||||
|
||||
Rechargez le démon systemd :
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload
|
||||
systemctl start step-ca.service
|
||||
```
|
||||
|
||||
### 🐳 Installation avec Docker
|
||||
|
||||
```bash
|
||||
docker run -it -v step:/home/step \
|
||||
-p 9000:9000 \
|
||||
-e "DOCKER_STEPCA_INIT_NAME=Lab" \
|
||||
-e "DOCKER_STEPCA_INIT_DNS_NAMES=caserver.lab.loc,localhost,192.168.1.101" \
|
||||
-e "DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT=true" \
|
||||
-e "DOCKER_STEPCA_INIT_ACME=true" \
|
||||
smallstep/step-ca
|
||||
```
|
||||
|
||||
## 🔑 Accès à l'AC avec un Autre Client
|
||||
|
||||
> **NOTE :**
|
||||
> Adaptez le port en fonction de votre installation :
|
||||
>
|
||||
> - **Binaire :** port **443**
|
||||
> - **Docker :** port **9000**
|
||||
|
||||
Installez le Step CLI :
|
||||
|
||||
```bash
|
||||
wget https://dl.step.sm/gh-release/cli/docs-cli-install/v0.24.3/step-cli_0.24.3_amd64.deb
|
||||
sudo dpkg -i step-cli_0.24.3_amd64.deb
|
||||
```
|
||||
|
||||
Initialisez votre AC :
|
||||
|
||||
```bash
|
||||
step ca bootstrap --ca-url https://caserver.lab.loc:$PORT/ --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887
|
||||
```
|
||||
|
||||
> **ASTUCE :**
|
||||
> Pour obtenir l'**empreinte**, exécutez simplement :
|
||||
>
|
||||
> ```bash
|
||||
> step certificate fingerprint $(step path)/certs/root_ca.crt
|
||||
> ```
|
||||
>
|
||||
> Pour Docker, consultez les logs du conteneur.
|
||||
|
||||
Exemple de sortie :
|
||||
|
||||
```bash
|
||||
admin@User:~$ step ca bootstrap --ca-url https://caserver.lab.loc:$PORT --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887
|
||||
Le certificat racine a été enregistré dans /home/admin/.step/certs/root_ca.crt.
|
||||
La configuration de l'autorité a été enregistrée dans /home/admin/.step/config/defaults.json.
|
||||
```
|
||||
|
||||
Installez le certificat :
|
||||
|
||||
```bash
|
||||
step certificate install $(step path)/certs/root_ca.crt
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **ASTUCE :**
|
||||
> **Installation sur Debian :**
|
||||
>
|
||||
> - Copiez les fichiers CRT individuels (format PEM) dans `/usr/local/share/ca-certificates/`
|
||||
> - Les fichiers doivent appartenir à `root:root` avec les droits `644`
|
||||
> - Assurez-vous que le paquet `ca-certificates` est installé (sinon, installez-le)
|
||||
> - Ensuite, exécutez en tant que root :
|
||||
>
|
||||
> ```bash
|
||||
> # /usr/sbin/update-ca-certificates
|
||||
> ```
|
||||
>
|
||||
> Tous les certificats seront consolidés dans : `/etc/ssl/certs/ca-certificates.crt`
|
||||
|
||||
---
|
||||
|
||||
### 📝 Obtenir un Certificat
|
||||
|
||||
```bash
|
||||
admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key
|
||||
✔ Provisionneur : contact@lab.loc (JWK) [kid: chyGkrZqp-BGSHUZ8v3jsPipegt2JLcC7y6RPq4OOkU]
|
||||
Veuillez entrer le mot de passe pour déchiffrer la clé du provisionneur :
|
||||
✔ AC : https://caserver.lab.loc:443
|
||||
✔ Certificat : srv.crt
|
||||
✔ Clé Privée : srv.key
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **ASTUCE :**
|
||||
> Pour effectuer un test de santé :
|
||||
>
|
||||
> ```bash
|
||||
> curl https://caserver.lab.loc:443/health -k
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
Il pourrait être nécessaire de personnaliser le fichier `ca.json` pour augmenter la durée minimale de validité des certificats. Voici la structure du répertoire :
|
||||
|
||||
```bash
|
||||
.
|
||||
|-- certs
|
||||
| |-- intermediate_ca.crt
|
||||
| `-- root_ca.crt
|
||||
|-- config
|
||||
| |-- ca.json
|
||||
| `-- defaults.json
|
||||
|-- db
|
||||
| |-- 000000.vlog
|
||||
| |-- 000020.sst
|
||||
| |-- KEYREGISTRY
|
||||
| |-- LOCK
|
||||
| `-- MANIFEST
|
||||
|-- secrets
|
||||
| |-- intermediate_ca_key
|
||||
| |-- password
|
||||
| `-- root_ca_key
|
||||
`-- templates
|
||||
```
|
||||
|
||||
Exemple de fichier `ca.json` :
|
||||
|
||||
```json
|
||||
{
|
||||
"root": "/home/step/certs/root_ca.crt",
|
||||
"federatedRoots": null,
|
||||
"crt": "/home/step/certs/intermediate_ca.crt",
|
||||
"key": "/home/step/secrets/intermediate_ca_key",
|
||||
"address": ":9000",
|
||||
"insecureAddress": "",
|
||||
"dnsNames": [
|
||||
"caserver.lab.loc",
|
||||
"caserver",
|
||||
"localhost",
|
||||
"192.168.1.200"
|
||||
],
|
||||
"logger": {
|
||||
"format": "text"
|
||||
},
|
||||
"db": {
|
||||
"type": "badgerv2",
|
||||
"dataSource": "/home/step/db",
|
||||
"badgerFileLoadingMode": ""
|
||||
},
|
||||
"authority": {
|
||||
"enableAdmin": true,
|
||||
"claims": {
|
||||
"maxTLSCertDuration": "4380h"
|
||||
}
|
||||
},
|
||||
"tls": {
|
||||
"cipherSuites": [
|
||||
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
|
||||
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
|
||||
],
|
||||
"minVersion": 1.2,
|
||||
"maxVersion": 1.3,
|
||||
"renegotiation": false
|
||||
}
|
||||
}
|
||||
316
content/documentation/stepca.md
Normal file
@@ -0,0 +1,316 @@
|
||||
---
|
||||
title: "Self-Hosted Certificate Manager"
|
||||
date: 2024-08-01T20:00:00+02:00
|
||||
weight: 2
|
||||
cascade:
|
||||
type: docs
|
||||
---
|
||||
|
||||
## 🔗 Sources
|
||||
|
||||
- [📖 Official Documentation](https://smallstep.com/docs/tutorials/)
|
||||
- [🛠️ Step-CA as a systemd Service](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
|
||||
- [🔐 OpenSSL Certificate Management](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)
|
||||
|
||||
## 🤖 About Step-CA
|
||||
|
||||
Step-CA is a nifty toolkit developed by Smallstep, a company that’s all about secure identity management and certificate automation. 🚀 Its mission? To simplify setting up and managing your own certificate authorities (CAs) with ease and security!
|
||||
|
||||
### Key Features
|
||||
|
||||
1. **Certificate Authority Management** 🔑
|
||||
Easily set up and manage your own CAs. Create root and intermediate CAs, issue certificates, and handle revocations like a pro.
|
||||
|
||||
2. **Secure Key Management** 🛡️
|
||||
Best practices for secure key storage and management, ensuring your cryptographic keys stay safe and sound from unauthorized access.
|
||||
|
||||
3. **Automation and Scalability** ⚙️
|
||||
Perfect for both small-scale and enterprise deployments. Enjoy APIs and integrations that automate certificate issuance, renewal, and revocation for a seamless lifecycle.
|
||||
|
||||
4. **Enhanced Security** 🔒
|
||||
Using modern cryptographic algorithms and protocols, Step-CA supports industry-standard X.509 certificates, offering robust encryption and digital signatures.
|
||||
|
||||
5. **Integration with Infrastructure** 🌐
|
||||
Integrates smoothly with your existing tools and systems. Supports various authentication methods like username/password, MFA, and external identity providers.
|
||||
|
||||
6. **Auditability and Compliance** 📜
|
||||
With comprehensive logging and auditing capabilities, you can track certificate activities and meet compliance requirements with ease.
|
||||
|
||||
7. **Developer-Friendly APIs** 👩💻👨💻
|
||||
Developer-centric APIs and SDKs make it a breeze to integrate certificate management into your custom applications and workflows.
|
||||
|
||||
**In a nutshell:** Step-CA from Smallstep is designed to make certificate authority management fun and hassle-free. With its secure, scalable, and user-friendly features, you can easily manage your certificate lifecycle while keeping your infrastructure safe and sound!
|
||||
|
||||
## 🚀 Installation
|
||||
|
||||
### 🔧 Binary Installation
|
||||
|
||||
#### 1. Step CLI
|
||||
|
||||
```bash
|
||||
wget https://dl.step.sm/gh-release/cli/docs-cli-install/v0.24.3/step-cli_0.24.3_amd64.deb
|
||||
sudo dpkg -i step-cli_0.24.3_amd64.deb
|
||||
```
|
||||
|
||||
#### 2. Step-CA
|
||||
|
||||
```bash
|
||||
wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_0.24.1_amd64.deb
|
||||
sudo dpkg -i step-ca_0.24.1_amd64.deb
|
||||
```
|
||||
|
||||
#### 3. Create a Specific User
|
||||
|
||||
```bash
|
||||
adduser adminCA
|
||||
```
|
||||
|
||||
#### Configuration
|
||||
|
||||
```bash
|
||||
$ step ca init --password-file=password.txt
|
||||
✔ Deployment Type: Standalone
|
||||
What would you like to name your new PKI?
|
||||
✔ (e.g. Smallstep): Lab
|
||||
✔ (e.g. ca.example.com[,10.1.2.3,etc.]): ca.lab.loc, localhost, 192.168.1.101
|
||||
What IP and port will your new CA bind to? (:443 will bind to 0.0.0.0:443).1.101
|
||||
✔ (e.g. :443 or 127.0.0.1:443): :443
|
||||
What would you like to name the CA's first provisioner?
|
||||
✔ (e.g. you@smallstep.com): contact@lab.loc
|
||||
Choose a password for your CA keys and first provisioner.
|
||||
✔ [leave empty and we'll generate one]:
|
||||
|
||||
Generating root certificate... done! 🎉
|
||||
Generating intermediate certificate... done! 🎊
|
||||
|
||||
✔ Root certificate: /home/adminCA/.step/certs/root_ca.crt
|
||||
✔ Root private key: /home/adminCA/.step/secrets/root_ca_key
|
||||
✔ Root fingerprint: 7d754397c6897aa87d21e33c64daad7be087dc6fe18bf04627848ae1c8e26a4f
|
||||
✔ Intermediate certificate: /home/adminCA/.step/certs/intermediate_ca.crt
|
||||
✔ Intermediate private key: /home/adminCA/.step/secrets/intermediate_ca_key
|
||||
✔ Database folder: /home/adminCA/.step/db
|
||||
✔ Default configuration: /home/adminCA/.step/config/defaults.json
|
||||
✔ Certificate Authority configuration: /home/adminCA/.step/config/ca.json
|
||||
|
||||
Your PKI is all set! To generate certificates for individual services, check out `step help ca`.
|
||||
|
||||
💌 **FEEDBACK**
|
||||
The step utility is not instrumented for usage statistics. It doesn’t phone home. But your feedback is super valuable! Feel free to drop us a line at feedback@smallstep.com, join GitHub Discussions, or hop into our Discord at [https://u.step.sm/discord](https://u.step.sm/discord).
|
||||
```
|
||||
|
||||
Start CA Step:
|
||||
|
||||
```bash
|
||||
step-ca .step/config/ca.json
|
||||
```
|
||||
|
||||
#### Enable ACME
|
||||
|
||||
```bash
|
||||
$ step ca provisioner add acme --type ACME
|
||||
✔ CA Configuration: /home/adminCA/.step/config/ca.json
|
||||
|
||||
Success! Your `step-ca` config has been updated. To pick up the new configuration, SIGHUP (kill -1 <pid>) or restart the step-ca process. 🎉
|
||||
```
|
||||
|
||||
#### Run Step-CA as a systemd Service
|
||||
|
||||
Create a file:
|
||||
|
||||
```bash
|
||||
vim /etc/systemd/system/step-ca.service
|
||||
```
|
||||
|
||||
Copy and paste the following:
|
||||
|
||||
```config
|
||||
[Unit]
|
||||
Description=step-ca
|
||||
After=syslog.target network.target
|
||||
|
||||
[Service]
|
||||
User=adminCA
|
||||
Group=adminCA
|
||||
ExecStart=/bin/sh -c '/bin/step-ca /home/adminCA/.step/config/ca.json --password-file=/home/step/.step/pwd >> /var/log/step-ca/output.log 2>&1'
|
||||
Type=simple
|
||||
Restart=on-failure
|
||||
RestartSec=10
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Create the log directory:
|
||||
|
||||
```bash
|
||||
mkdir -p /var/log/step-ca
|
||||
chown -R adminCA:adminCA /var/log/step-ca
|
||||
```
|
||||
|
||||
Reload the daemon:
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload
|
||||
systemctl start step-ca.service
|
||||
```
|
||||
|
||||
### 🐳 Docker Installation
|
||||
|
||||
```bash
|
||||
docker run -it -v step:/home/step \
|
||||
-p 9000:9000 \
|
||||
-e "DOCKER_STEPCA_INIT_NAME=Lab" \
|
||||
-e "DOCKER_STEPCA_INIT_DNS_NAMES=caserver.lab.loc,localhost,192.168.1.101" \
|
||||
-e "DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT=true" \
|
||||
-e "DOCKER_STEPCA_INIT_ACME=true" \
|
||||
smallstep/step-ca
|
||||
```
|
||||
|
||||
## 🔑 Access to CA with Another Client
|
||||
|
||||
> **NOTE:**
|
||||
> Adjust the port based on your installation:
|
||||
>
|
||||
> - **Binary:** port **443**
|
||||
> - **Docker:** port **9000**
|
||||
|
||||
Install the Step CLI:
|
||||
|
||||
```bash
|
||||
wget https://dl.step.sm/gh-release/cli/docs-cli-install/v0.24.3/step-cli_0.24.3_amd64.deb
|
||||
sudo dpkg -i step-cli_0.24.3_amd64.deb
|
||||
```
|
||||
|
||||
Bootstrap your CA:
|
||||
|
||||
```bash
|
||||
step ca bootstrap --ca-url https://caserver.lab.loc:$PORT/ --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887
|
||||
```
|
||||
|
||||
> **TIP:**
|
||||
> To get the **fingerprint**, simply run:
|
||||
>
|
||||
> ```bash
|
||||
> step certificate fingerprint $(step path)/certs/root_ca.crt
|
||||
> ```
|
||||
>
|
||||
> For Docker, check the container logs.
|
||||
|
||||
Example output:
|
||||
|
||||
```bash
|
||||
admin@User:~$ step ca bootstrap --ca-url https://caserver.lab.loc:$PORT --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887
|
||||
The root certificate has been saved in /home/admin/.step/certs/root_ca.crt.
|
||||
The authority configuration has been saved in /home/admin/.step/config/defaults.json.
|
||||
```
|
||||
|
||||
Install the certificate:
|
||||
|
||||
```bash
|
||||
step certificate install $(step path)/certs/root_ca.crt
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **TIP:**
|
||||
> **Debian Installation:**
|
||||
>
|
||||
> - Copy individual CRT (PEM format) files to `/usr/local/share/ca-certificates/`
|
||||
> - Files must be owned by `root:root` with mode `644`
|
||||
> - Ensure the package `ca-certificates` is installed (if not, install it)
|
||||
> - Then run as root:
|
||||
>
|
||||
> ```bash
|
||||
> # /usr/sbin/update-ca-certificates
|
||||
> ```
|
||||
>
|
||||
> All certificates will be consolidated at: `/etc/ssl/certs/ca-certificates.crt`
|
||||
|
||||
---
|
||||
|
||||
### 📝 Get a Certificate
|
||||
|
||||
```bash
|
||||
admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key
|
||||
✔ Provisioner: contact@lab.loc (JWK) [kid: chyGkrZqp-BGSHUZ8v3jsPipegt2JLcC7y6RPq4OOkU]
|
||||
Please enter the password to decrypt the provisioner key:
|
||||
✔ CA: https://caserver.lab.loc:443
|
||||
✔ Certificate: srv.crt
|
||||
✔ Private Key: srv.key
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **TIP:**
|
||||
> To perform a health check:
|
||||
>
|
||||
> ```bash
|
||||
> curl https://caserver.lab.loc:443/health -k
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
It might be necessary to customize the `ca.json` file to increase the minimum duration of the certificate validity. Check out the folder structure below:
|
||||
|
||||
```bash
|
||||
.
|
||||
|-- certs
|
||||
| |-- intermediate_ca.crt
|
||||
| `-- root_ca.crt
|
||||
|-- config
|
||||
| |-- ca.json
|
||||
| `-- defaults.json
|
||||
|-- db
|
||||
| |-- 000000.vlog
|
||||
| |-- 000020.sst
|
||||
| |-- KEYREGISTRY
|
||||
| |-- LOCK
|
||||
| `-- MANIFEST
|
||||
|-- secrets
|
||||
| |-- intermediate_ca_key
|
||||
| |-- password
|
||||
| `-- root_ca_key
|
||||
`-- templates
|
||||
```
|
||||
|
||||
Example `ca.json` file:
|
||||
|
||||
```json
|
||||
{
|
||||
"root": "/home/step/certs/root_ca.crt",
|
||||
"federatedRoots": null,
|
||||
"crt": "/home/step/certs/intermediate_ca.crt",
|
||||
"key": "/home/step/secrets/intermediate_ca_key",
|
||||
"address": ":9000",
|
||||
"insecureAddress": "",
|
||||
"dnsNames": [
|
||||
"caserver.lab.loc",
|
||||
"caserver",
|
||||
"localhost",
|
||||
"192.168.1.200"
|
||||
],
|
||||
"logger": {
|
||||
"format": "text"
|
||||
},
|
||||
"db": {
|
||||
"type": "badgerv2",
|
||||
"dataSource": "/home/step/db",
|
||||
"badgerFileLoadingMode": ""
|
||||
},
|
||||
"authority": {
|
||||
"enableAdmin": true,
|
||||
"claims": {
|
||||
"maxTLSCertDuration": "4380h"
|
||||
}
|
||||
},
|
||||
"tls": {
|
||||
"cipherSuites": [
|
||||
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
|
||||
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
|
||||
],
|
||||
"minVersion": 1.2,
|
||||
"maxVersion": 1.3,
|
||||
"renegotiation": false
|
||||
}
|
||||
}
|
||||
```
|
||||