Fix allow privilege escalation#49
Merged
Merged
Conversation
When upgrading from older SDI versions, the pos file at /var/tmp/diagnostics-fluentd-sdi.log.pos may have been created by a container running as a different UID (e.g., 999). The new version runs as a different UID (e.g., 100 or 1000), causing permission denied errors. This fix adds an init container that runs chmod 666 on the pos file before the main fluentd container starts, making it writable by any UID. The init container: - Runs as root with privileged security context and spc_t SELinux type - Only modifies permissions if the file exists - Uses minimal resources (10m CPU, 10Mi memory) Also refactors the security context patching into helper functions: - patchPodSecurityContext: handles pod-level security context - patchContainerSecurityContext: handles container-level security context - ensureFluentdInitContainer: injects the permission fix init container The code now removes runAsUser: 0 if previously set, letting containers run as their intended UID while still having the init container fix permissions beforehand.
SDI 3.3.290 changed the vartmp volume from hostPath to emptyDir, which eliminates the permission issues that required our security patches. Running in privileged mode with spc_t SELinux on the new version actually causes the fluentd 'have_capability?' error. This change: - Adds isVartmpHostPath() to detect volume type - Adds cleanupFluentdPatches() to revert our patches when emptyDir is detected - Only applies security patches (privileged, spc_t, init container) for hostPath - Automatically cleans up patches during upgrade from 3.3.265 to 3.3.290 Behavior by volume type: - hostPath (SDI 3.3.265): Apply privileged mode, init container for chmod 666 - emptyDir (SDI 3.3.290+): Remove patches, let container run as non-privileged
The updateExistingRouteCA function was detecting certificate changes but never calling Client.Update() to persist the change to the cluster. This meant that after an SDI upgrade, even if the ca-bundle.pem secret changed, the route's DestinationCACertificate was never updated. Changes: - Add Client.Update() call when certificate differs - Add info log when certificate is updated - Change "unchanged" log to V(1) debug level - Wrap update error with context
0026a6e to
c5c19fd
Compare
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #49 +/- ##
=========================================
Coverage ? 13.08%
=========================================
Files ? 10
Lines ? 1032
Branches ? 0
=========================================
Hits ? 135
Misses ? 884
Partials ? 13
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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
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.
No description provided.