-
Notifications
You must be signed in to change notification settings - Fork 1.3k
HLD for persistent local user management #2018
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
/azp run |
|
No pipelines are associated with this pull request. |
bc68d29 to
62d56bc
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
62d56bc to
fd6aea7
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
fd6aea7 to
7c4b7d3
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
7c4b7d3 to
3c56ccb
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
3c56ccb to
db52f3b
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
db52f3b to
6653490
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
6653490 to
793f412
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
793f412 to
bf17e02
Compare
|
/azp run |
5f08f1c to
4a02cf2
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
This implementation addresses the User Management HLD requirements for centralized user administration in SONiC. sonic-net/SONiC#2018 **1. YANG Model & Configuration Schema:** - Added sonic-user.yang model defining LOCAL_USER and LOCAL_ROLE_SECURITY_POLICY tables - Integrated user management into CONFIG_DB schema with role-based configuration - Added DEVICE_METADATA.local_user_management feature flag **2. User Management Daemon (userd):** - Implemented C++ daemon using SWSS framework for CONFIG_DB integration - Added user lifecycle management (create/update/delete/enable/disable) - Implemented role-based group assignment (administrator, operator roles) - Added SSH key management with proper file permissions - Integrated PAM faillock configuration using Jinja2 templates **3. CLI Interface:** - Extended sonic-utilities with 'config user' and 'show user' commands - Added user import functionality to migrate existing system users - Added role-based user management with proper validation **4. Build System Integration:** - Added sonic-host-services package with userd daemon and systemd service - Integrated user management into SONiC image build process - Added template-based configuration generation for init_cfg.json - Added build dependencies for JSON processing and password hashing
@vitaliibylinka PRs with implementation details have been posted. |
4a02cf2 to
fe06f5f
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
spandan-nexthop
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Just added some comments/questions.
|
@qiluo-msft can you please help signoff on this feature? |
This implementation addresses the User Management HLD requirements for centralized user administration in SONiC. sonic-net/SONiC#2018 nexthop-ai/private-sonic-host-services#54 nexthop-ai/private-sonic-utilities#120 **1. YANG Model & Configuration Schema:** - Added sonic-user.yang model defining LOCAL_USER and LOCAL_ROLE_SECURITY_POLICY tables - Integrated user management into CONFIG_DB schema with role-based configuration - Added DEVICE_METADATA.local_user_management feature flag **2. User Management Daemon (userd):** - Implemented C++ daemon using SWSS framework for CONFIG_DB integration - Added user lifecycle management (create/update/delete/enable/disable) - Implemented role-based group assignment (administrator, operator roles) - Added SSH key management with proper file permissions - Integrated PAM faillock configuration using Jinja2 templates **3. CLI Interface:** - Extended sonic-utilities with 'config user' and 'show user' commands - Added user import functionality to migrate existing system users - Added role-based user management with proper validation **4. Build System Integration:** - Added sonic-host-services package with userd daemon and systemd service - Integrated user management into SONiC image build process - Added template-based configuration generation for init_cfg.json - Added build dependencies for JSON processing and password hashing Tested for all the features that are implemented.
fe06f5f to
cb6b0d2
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
cb6b0d2 to
c1032c8
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
| |:---:|:--------------:|:-----------:|:----------------------------------------------------------------------------------------------------------------------------------------------------:| | ||
| | 1.0 | June 16, 2025 | Manoharan Sundaramoorthy | Initial HLD | | ||
|
|
||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently the local users that are created are not persistent across upgrades. This HLD proposes to manage the users across upgrades by storing the configuration in CONFIG_DB and a daemon to manage them in Linux.
-> For this requirement, is it not better to migrate the users from one partition to another partition during upgrade operation instead of exposing the users & password keys in the CONFIG_DB, filtering them in the tech bundle for security reasons?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There were few things that we had considered for this:
- SSH keys - we would have to create the user directories and the authorized_keys to set this up. It would be possible with scripts but would be cumbersome.
- We would not know which were local users and which were from RADIUS / TACACS.
- We wont be able to port another device (incase device has to be replaced).
|
Password hashes are also considered sensitive data since they can be used for reverse-engineering to get the password. Normally, /etc/shadow is only readable to root-level user. Making this change in SONiC essentially expose the /etc/shadow file content to general users and breaks the security policy of Linux. |
| - `/etc/sonic/config_db.json` file permissions changed from `644` to `640` (root:redis) | ||
| - Password hashes only visible in show commands when run with `sudo` privileges | ||
| - `show user` displays usernames only, `sudo show user` displays hashes | ||
| - `show runningconfiguration` redacts password_hash fields unless run with `sudo` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the user just writes a script/process to connect to the running CONFIG_DB and read content? Right now, there is no table-level protection in redis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think currently a user only has to be part of the docker group to view the redis database.
admin@sonic:~$ sudo su - newusername
$ groups
newusername docker
$ redis-cli
127.0.0.1:6379> KEYS *
1) "GEARBOX_TABLE_KEY_SET"
2) "PORT_TABLE:Ethernet96"
3) "PORT_TABLE:Ethernet80"
4) "PORT_TABLE:Ethernet88"
5) "PORT_TABLE:Ethernet16"
...
Can/should this be changed so only users who are part of the redis group can view the db?
I believe the CLI show command will only show password hashes when the user is root. I believe the file And it will need to be changed to this I don't see the code to do that in this PR? I would expect something like the following code at the end of generate_config() ( |
Currently the local users that are created are not persistent across upgrades. This HLD proposes to manage the users across upgrades by storing the configuration in CONFIG_DB and a daemon to manage them in Linux.
Implementation Pull requests: