Fix(image missing)
- Removing English - Start new post
This commit is contained in:
darnodo
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
@@ -1,153 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
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 >}}
|
||||
@@ -1,317 +0,0 @@
|
||||
---
|
||||
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! 🎉
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 188 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 186 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 117 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 243 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 184 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 211 KiB |
@@ -1,312 +0,0 @@
|
||||
---
|
||||
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
|
||||
}
|
||||
}
|
||||
```
|
||||
Reference in New Issue
Block a user