SNMPv3 configuration¶
SNMPv3 only
This page is only relevant if you are using SNMPv3 authentication. If your devices use SNMPv2c or SNMPv1, you can skip this page entirely.
Configuration of SNMPv3, when supported by the monitored devices, is the most secure choice available for authentication and data privacy. We recommend using SNMPv3 whenever possible.
Each set of credentials is stored as a Kubernetes Secret object and referenced by name in values.yaml.
This allows the secret to be created once — including automation by third-party password managers — then consumed without storing sensitive data in plain text.
# <secretname>=Arbitrary name of the secret often the same as the username or prefixed with "sc4snmp-"
# <namespace>=Namespace used to install sc4snmp
# <username>=the SNMPv3 Username
# <key>=key note must be at least 8 char long subject to target limitations
# <authProtocol>=One of SHA (SHA1) or MD5
# <privProtocol>=One of AES or DES
# Note MD5 and DES are considered insecure but must be supported for standards compliance
microk8s kubectl create -n <namespace> secret generic <secretname> \
--from-literal=userName=<username> \
--from-literal=authKey=<key> \
--from-literal=privKey=<key> \
--from-literal=authProtocol=<authProtocol> \
--from-literal=privProtocol=<privProtocol>
Configured credentials can be used in poller and trap services. In service configuration, secretname needs to be provided.
For poller:
poller:
usernameSecrets:
- secret_name
For traps:
traps:
usernameSecrets:
- secret_name
All SNMPv3 secrets are managed through a single secrets.json file stored in a folder on the host.
Prerequisites¶
Create a folder to store the secrets file. Inside this folder, create a secrets.json file that contains all SNMPv3 secrets.
{
"secret_name": {
"username": "user1",
"privprotocol": "AES",
"privkey": "privkey1",
"authprotocol": "SHA",
"authkey": "authkey1",
"contextengineid": "engineid1"
}
}
Note
The name of json file should be secrets.json. Username, authprotocol and authkey are mandatory parameters.
Configuration¶
In the .env file, set the path to the local folder containing the secrets.json:
SECRET_FOLDER_PATH=/absolute/path/to/secrets/folder
Secrets usage for worker-poller and worker-trap can be controlled by flags in .env:
ENABLE_TRAPS_SECRETS=true
ENABLE_WORKER_POLLER_SECRETS=true
Creating a new secret¶
Add an entry to secrets.json, then inside the docker_compose directory run:
sudo docker compose up -d
Updating existing secret¶
Update the required fields (e.g., keys, protocols, username) for any existing secret inside secrets.json, then run:
docker compose up -d --force-recreate <service_name>
Deleting a secret¶
Delete its entry from secrets.json, then run:
docker compose up -d --force-recreate <service_name>
Migration steps¶
Managing SNMPv3 secrets previously required updating docker compose files using the manage_secrets.py script. From SC4SNMP 1.15.0, this process has been simplified and can manage all SNMPv3 secrets using a single secrets.json file.
1. For setups not yet migrated to latest version¶
First, delete all existing secrets from docker-compose.yaml using manage_secrets.py with the following flags:
| Flag | Description |
|---|---|
--secret_name |
Secret name |
--path_to_compose |
Absolute path to directory with docker compose files |
--delete |
Set this flag to true to delete the secret |
This will delete the secret with a given name from all docker compose files. If this secret hasn’t been deleted from .env
file, it will be removed from there.
2. For setups already migrated to latest version¶
Manually delete the secrets from the docker-compose.yaml file under the worker-poller and worker-trap services. Remove the corresponding entries from the .env file.
After deleting the secrets, follow the above steps to configure secrets.