Skip to content
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

Align procedure for OS Image Build with security best-practices #7846

Open
jaradtke-aws opened this issue Mar 14, 2024 · 0 comments
Open

Align procedure for OS Image Build with security best-practices #7846

jaradtke-aws opened this issue Mar 14, 2024 · 0 comments

Comments

@jaradtke-aws
Copy link
Member

jaradtke-aws commented Mar 14, 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

   sudo chmod 666 /dev/kvm
   sudo chown root:kvm /dev/kvm

Originally the file has the following permissions (Ubuntu 20.04 as an example)

~$ ls -l /dev/kvm
crw-rw----+ 1 root kvm 10, 232 Mar 14 15:28 /dev/kvm

Places that would require an update (filename in output)

$ grep -r "chmod 666" *
docs/content/en/docs/osmgmt/artifacts.md:   sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md:   sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md:   sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md:   sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md:   sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md:   sudo chmod 666 /dev/kvm

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:
@jaradtke-aws 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant