Identity aware sockets#
A major improvement to our "published ports" feature has landed in 0.12.0. Now it is possible to create Identity Aware sockets for any port of your lab.
Identity Aware sockets is a feature of mysocketio service that allows you to let in only authorized users. Authorization is possible via multiple OAuth providers and can be configured to let in users with specific emails and/or with specific domains.
Check out how easy it is to create identity aware tunnels with containerlab:
With this enhancement it is now possible to create long-running secure tunnels which only the authorized users will be able to access.
On-demand veth plumbing#
Sometimes it is needed to add some additional connections after the lab has been deployed. Although the labs are quickly to re-spin, sometimes one find themselves in the middle of the use case configuration and there is a need to add another connection between the nodes.
tools veth command it is now possible to add veth pairs between container<->container, containers<->host and containers<->bridge nodes. Now you can add modify your lab connections without redeploying the entire lab[^2].
Safer ways to write clab files#
Containerlab got its own JSON Schema that governs the structure of the topology definition files. If you name your topo file as
*.clab.yml then some editors like VS Code will automatically provide auto-suggestions and linting for your clab files.
Yes, from now on we will call our topo files as clab-files.
Create TLS certificates effortlessly#
With the new commands
tools cert ca create and
tools cert sign it is now possible to create CA and node certificates with just two commands embedded into containerlab. Start from here if you always wanted to be able to reduce the number of openssl commands.
We also added a lab that pictures the net positive effect of having those commands when creating TLS certificates for secured gNMI connectivity.
It is imperative to create a nice automation flow that goes from infra deployment to the subsequent configuration automation. When containerlab finishes its deployment job we now create an ansible inventory file for a deployed lab.
With this inventory file the users can start their configuration management playbooks and configure the lab for a use case in mind.
Smart MTU for management network#
Default MTU value for the management network will now be inherited from the MTU of the
docker0 bridge interface. Thus, if you configured your docker daemon for a custom MTU, it will be respected by containerlab.
Running nodes in
When management network name is set to
bridge, containerlab nodes will be run in the default docker network named
bridge. This is the network where containers end up connecting when you do
docker run, so running the lab in the default docker network makes it easy to connect your lab with the workloads that have been started by someone else.
When a new release comes out we let you know next time you deploy a lab, a tiny message will pop up in the log saying that a new one is ready to make your labs even more efficient and easy.
INFO 🎉 New containerlab version 0.12.0 is available! Release notes: https://containerlab.srlinux.dev/rn/0.12.0 Run 'containerlab version upgrade' to upgrade or go check other installation options at https://containerlab.srlinux.dev/install/
Saving SR OS config#
This is implemented via Netconf's
<copy-config> RPC that is executed against SR OS node.
- Added support for user-defined node labels which can convey metadata for a given node.
- Container node needs to support live interface attachment.
- New TLS certificate logic for SR Linux nodes. If the CA files and node cert exist, the re-deployment of a lab won't issue new certificates and will reuse the existing ones.
- Additional node property
network-modehas been added which allows to deploy the node in the host networking mode.
- If the changes containerlab makes to LLDP/TX-offload on the management bridge fail, they won't prevent the lab from proceed deploying.