Open
Conversation
New CIS controls added: - CIS 5.2.2, 5.2.3, 5.2.4: Sudo hardening (pty, logging, password policies) - CIS 5.4.3.3: Default umask 027 configuration - Service hardening: Mask apport and rpcbind services - CIS 1.5.x: Coredump restrictions via systemd - CIS 2.1.x: NTP time synchronization All new functions use idempotent patterns (file overwrites or grep guards). Preserves all existing main branch hardening including AppArmor, rsyslog, AIDE, kernel hardening, and SSH Level 2 controls. Co-Authored-By: Oz <oz-agent@warp.dev>
sumitmishra-spectro
force-pushed
the
cis-harden-v3
branch
from
c86ead7 to
c2b2471
Compare
Co-Authored-By: Oz <oz-agent@warp.dev>
NTP configuration should be handled externally, not in image hardening. Co-Authored-By: Oz <oz-agent@warp.dev>
sumitmishra-spectro
changed the title
No longer needed - using standard provider-kubeadm image. Co-Authored-By: Oz <oz-agent@warp.dev>
arunbalasc
reviewed
Mar 3, 2026
arunbalasc
left a comment
arunbalasc
left a comment
There was a problem hiding this comment.
@sumit Mishra one question on cis changes, if the default-umask is done, then all permission problems will get fixed by default without requiring any specific code to change permissions?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
New CIS controls added:
CIS 5.2.2, 5.2.3, 5.2.4: Sudo Hardening
• 5.2.2 (use_pty): Forces sudo to run commands in a pseudo-terminal. This prevents attackers from using sudo to run background processes that persist after the session ends, and enables better logging.
• 5.2.3 (logfile): Logs all sudo commands to /var/log/sudo.log for audit trail and forensic analysis.
• 5.2.4 (password policies): Disables targetpw, rootpw, runaspw - ensures users authenticate with their own password, not the target user's or root's password.
No risk: These are logging and auth improvements. sudo still works normally; commands just run in a PTY and get logged. Most systems already use own-password auth.
CIS 5.4.3.3: Default umask 027
Sets the default file permission mask so new files are created with:
• Owner: read/write/execute
• Group: read/execute only
• Others: no access
No risk: Only affects newly created files. Existing files unchanged. Applications that need world-readable files explicitly set permissions anyway.
Service Hardening: Disable apport and rpcbind
• apport: Ubuntu's crash reporting service - can leak sensitive information in crash dumps
• rpcbind: Required for NFS/NIS - if not using these, it's an unnecessary attack surface (port 111)
No risk: Palette/Kubernetes doesn't use NFS mounts or NIS authentication. Crash reporting to Ubuntu is not needed in production. Neither service is required for cluster operation.
CIS 1.5.x: Coredump Restrictions
Disables core dumps via systemd (Storage=none, ProcessSizeMax=0). Core dumps can contain:
• Passwords in memory
• Encryption keys
• Sensitive application data
No risk: Core dumps are only useful for debugging crashes. In production, you don't want them (security risk + disk space). Kubernetes components have their own logging; core dumps aren't needed for troubleshooting.
All new functions use idempotent patterns (file existence checks, grep guards, or file overwrites) to prevent duplicate entries.