Allow configuring credentials with ENV

[antoinekh]

Allow configuring credentials for save command via env variables (with fallback to default)

Description

We are using Containerlab to simulate our full production configuration with vr based devices, including user management. As part of this process, we modify or remove the default user that Containerlab relies on for device access.

After removing or changing the default user, the containerlab save command no longer works, and startup configurations are not saved anymore.

Problem

The save command appears to rely on the default credentials configured by Containerlab. When those credentials are modified or removed (to better reflect production setups), the command fails and configurations are no longer persisted.

Proposed Enhancement

Allow defining credentials via the node env system so that Containerlab can use custom authentication when interacting with nodes.

Reference documentation:
https://containerlab.dev/manual/nodes/#env

Example (conceptual):

nodes:
  r1:
    kind: <kind>
    env:
      CLAB_USERNAME: myuser
      CLAB_PASSWORD: mypassword

Expected Behavior

• If custom credentials are defined via environment variables, Containerlab should use them for operations such as save.
• If no custom credentials are defined, Containerlab should fall back to the default username/password behavior.
• This would allow users to remove or modify the default user without breaking lifecycle operations.

Benefits

• Enables production-like authentication models in lab environments.
• Removes dependency on default credentials.
• Improves flexibility and security alignment with real-world deployments.

Is this something that could be supported?
Alternatively, is there a recommended approach to handle this use case?

[antoinekh]

If it's accepted, I'm willing to take on the development and do a PR.

[sacckth]

Just as a note this is not only a "VR" kind problem. Some container NOSes that don't have a direct CLI console do require this feature (i.e. Nokia SR-OS). We just didn't have the appetite to tackle this, as there is no single shoe fits all solution. Let's see what others say. It doesn't seem a bad idea to me. We should at least agree with a standard set of ENV vars to handle this feature on a per Kind basis.

[antoinekh]

I have a working solution that I am using on my lab.
Username and password are now defined with env by priority:
default > groups > kind > host > hardcoded default password

PR soon