-
-
Notifications
You must be signed in to change notification settings - Fork 320
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
Fix SELinux label of bootstrap-secrets on non-bootstrapping controllers #808
Fix SELinux label of bootstrap-secrets on non-bootstrapping controllers #808
Conversation
CHANGES.md
Outdated
@@ -33,6 +33,8 @@ Notable changes between versions. | |||
|
|||
### Fedora CoreOS | |||
|
|||
* Fix SELinux label of bootstrap-secrets on non-bootstrapping controllers ([#808](https://github.com/poseidon/typhoon/pull/808)) |
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.
can you move to latest, this section is for v1.18.8
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.
@dghubble I thought v1.18.8 is on the same level with Fedora CoreOS since they are both prefixed with ###. It turns out that v1.18.8 should be prefixed with ##
I realized I only tested on v1.18.6. So I launched another testing cluster on v1.18.8 and found additional type label needs to be fixed as well.
On the controllers that don't run
This has been fixed in the latest commit. |
This is similar to the race in #708, but more limited. The label has a chance of appearing on non-bootstrap controllers in multi-controller clusters on the first boot from disk. Its also resolved on any restart of the kubelet.service (service, reboot, auto-update) for the duration of a cluster lifecycle. The randomness of appearance stems from the same race with the first kubelet start. Manually setting the context like this should eliminate its chance of happening during this window. Thanks |
…roller (poseidon#808) * Fix race condition for bootstrap-secrets SELinux context on non-bootstrap controllers in multi-controller FCOS clusters * On first boot from disk on non-bootstrap controllers, adding bootstrap-secrets races with kubelet.service starting, which can cause the secrets assets to have the wrong label until kubelet.service restarts (service, reboot, auto-update) * This can manifest as `kube-apiserver`, `kube-controller-manager`, and `kube-scheduler` pods crashlooping on spare controllers on first cluster creation
There's already a merged PR addressing the same problem on the controller that runs
bootstrap
service. However, on other controllers, Docker podskube-apiserver
,kube-scheduler
, andkube-controller-manager
still cannot read files from/etc/kubernetes/bootstrap-secrets
(on host) due to the wrong SELinux file label (specificallyuser
field).On the controller that has run
bootstrap
service:On the controllers that don't run
bootstrap
service:See the difference in
user
field (system_u
vsunconfined_u
). This PR updates the user field tosystem_u
on all controllers. Onaws/fedora-coreos
, I've verified this fixes all the permission denials on files under/etc/kubernetes/secrets
(container) fromkube-apiserver
,kube-scheduler
, andkube-controller-manager
containers.