You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: a widely recognized "work around" to simply run newgrp kvm which allows the image-bulder user to then access /dev/kvm - but this is not ideal, either. If the user runs the newgrp kvm command, all new files created after that point will have group-ownership of kvm. This may not be a bad scenario though.
2/ Provides steps for user management for user:image-builder introduces a number of challenges - which happen to have OS-specific solutions. I.e. group sudo exists in Ubuntu, but not RHEL.
This either requires some sort of case statement to determine current OS, or move the user management steps to the OS-specific tabs in the instructions.
What you expected to happen:
I believe a better approach should be identified and the documentation updated.
This likely will mean that the /dev/kvm flie is not modified, and the image-builder user will need to logout/login for the shell to recognize that image-builder belongs to the kvm group.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
EKS Anywhere Release:
EKS Distro Release:
The text was updated successfully, but these errors were encountered:
jaradtke-aws
changed the title
Procedure for OS Image Build does not follow security best-practice
Align procedure for OS Image Build with security best-practices
Mar 15, 2024
What happened:
The EKS Anywhere documentation does the following
1/ makes recommendation to modify the default filesystem permissions
Referencing the Build Bare Metal Node Images page as an example:
https://anywhere.eks.amazonaws.com/docs/osmgmt/artifacts/#build-bare-metal-node-images
The doc recommends the following
Originally the file has the following permissions (Ubuntu 20.04 as an example)
Places that would require an update (filename in output)
Note: a widely recognized "work around" to simply run
newgrp kvm
which allows the image-bulder user to then access /dev/kvm - but this is not ideal, either. If the user runs thenewgrp kvm
command, all new files created after that point will have group-ownership of kvm. This may not be a bad scenario though.2/ Provides steps for user management for user:image-builder introduces a number of challenges - which happen to have OS-specific solutions. I.e. group
sudo
exists in Ubuntu, but not RHEL.This either requires some sort of
case statement
to determine current OS, or move the user management steps to the OS-specific tabs in the instructions.What you expected to happen:
I believe a better approach should be identified and the documentation updated.
This likely will mean that the /dev/kvm flie is not modified, and the image-builder user will need to logout/login for the shell to recognize that image-builder belongs to the kvm group.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
The text was updated successfully, but these errors were encountered: