Security: Use OS keychain or encryption for storing credentials in config file instead of plain text

[Vaishnav88sk]

Describe the bug

Following up on a comment from #503 (comment) by @Harsh4902, the CLI currently stores credentials in the local configuration file in plain text.

Specifically, looking at pkg/config/localconfig.go, the LocalConfig struct stores AuthToken and RefreshToken inside the User struct, and ClientSecret inside the Auth struct. These are serialized directly to a YAML file (typically ~/.config/microcks/config).

If the file permissions on the config file are not strictly locked down, or if a malicious script gets read access to the user's home directory, these credentials can be easily stolen.

Expected behavior

CLI tools typically avoid storing access tokens, refresh tokens, and client secrets in plain text. Instead, we should consider:

1. Using the operating system's native secure keystore/keychain (e.g., macOS Keychain, Windows Credential Manager, Linux Secret Service) using a library like zalando/go-keyring or 99designs/keyring.
2. As a fallback, strictly enforcing 0600 permissions on the config file so that only the file owner can read it (though native keystore is much preferred).

Actual behavior

No response

How to Reproduce?

No response

Microcks version or git rev

No response

Install method (docker-compose, helm chart, operator, docker-desktop extension,...)

No response

Additional information

Proposed Solution

1. Integrate a keychain library like github.com/zalando/go-keyring.
2. When saving a configuration (in pkg/config/localconfig.go), extract AuthToken, RefreshToken, and ClientSecret from the struct.
3. Save these extracted secrets securely into the OS keychain, using the server name or user context as the service key.
4. Replace the struct values with a placeholder (e.g., keychain-stored) before writing the remaining configuration to the YAML file.
5. When reading the configuration, dynamically fetch the secrets from the keychain back into the struct.

Impact

Storing credentials securely will prevent local token theft and align microcks-cli with industry best practices for CLI security.

[Vaishnav88sk]

Just to add some context regarding the implementation, if we decide to move forward with the OS keychain approach, there are two main architectural challenges to keep in mind:

1. Backward Compatibility (Existing Users)

If the CLI suddenly switches to only look for secrets in the OS Keychain, everyone currently authenticated will be logged out upon upgrading, as their secrets will still be in the old plain text YAML file.

• Mitigation: The implementation will need a migration path. When ReadLocalConfig is called, if it finds a real token (instead of a keychain-stored placeholder), it should seamlessly migrate that token to the OS keychain, and then save the placeholder back to the YAML file.

2. Headless / CI Environments

OS Keychains (like macOS Keychain or Linux Secret Service) are designed for desktop environments. If microcks-cli runs in a headless Docker container or a CI pipeline (e.g., GitHub Actions), there is usually no keychain available, and libraries like go-keyring will throw an error.

• Mitigation:
  • The CLI should gracefully handle the "keychain not found" error.
  • It could provide an opt-out flag/env variable (e.g., MICROCKS_NO_KEYCHAIN=true) to fallback to the legacy YAML behavior.
  • Alternatively, it can rely on the fact that users in CI/CD environments typically authenticate using Environment Variables (e.g., MICROCKS_CLIENT_SECRET=...) anyway, bypassing the local config file entirely.

[Vaishnav88sk]

/keep-open
/priority-low