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.

Sign up for GitHub

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

Jump to bottom

Assigning RuntimeDefault AppArmor profile to pods/containers when strict security is enabled breaks on hosts w/o AppArmor #1120

Closed
jfroy opened this issue Sep 30, 2024 · 3 comments
Closed

Assigning RuntimeDefault AppArmor profile to pods/containers when strict security is enabled breaks on hosts w/o AppArmor #1120

jfroy opened this issue Sep 30, 2024 · 3 comments
Labels
bug Something isn't working waiting for release The change was merged to upstream, but wasn't released yet.

Comments

@jfroy
Copy link
Contributor

jfroy commented Sep 30, 2024

The operator assigns the special RuntimeDefault AppArmor profile on pods and containers when strict security is enabled. On any hosts where AppArmor is not enabled, the pod will be rejected by kubelet's AppArmor admission handler, with the error "Cannot enforce AppArmor: AppArmor is not enabled on the host". This needs to be made configurable, as not all clusters will have AppArmor enabled on all hosts.
@jfroy jfroy changed the title Assigning non-unconfined AppArmor profile to pods/containers when strict security is enabled breaks on hosts w/o AppArmor Assigning RuntimeDefault AppArmor profile to pods/containers when strict security is enabled breaks on hosts w/o AppArmor Sep 30, 2024
@jfroy jfroy changed the title Assigning RuntimeDefault AppArmor profile to pods/containers when strict security is enabled breaks on hosts w/o AppArmor Assigning RuntimeDefault AppArmor profile to pods/containers when strict security is enabled breaks on hosts w/o AppArmor Sep 30, 2024
@f41gh7 f41gh7 added the bug Something isn't working label Oct 1, 2024
@f41gh7
Copy link
Collaborator

f41gh7 commented Oct 9, 2024

Maybe, it's better to remove default AppArmor value. Main motivation for it adding it was default security rules for cloud providers.
As far as I understand, azure provides preset of configured validation rules ( runAsRoot false and others). But reality is AppArmor and Selinux are not widely supported ( windows hosts don't have such option).

@suhasagasthya
Copy link

Same issue faced! AppArmor is blocking pods on hosts that dont have appArmor enabled, we dont use appArmor in our environments.
+1 to remove the appArmor value from the default security context or pass it as an env to enable if needed only.
image

f41gh7 added a commit that referenced this issue Oct 15, 2024
@f41gh7
build/security: removes AppArmorProfile and SeccompProfile from defaults
e301383 
It allow to use strictSecurity with hosts without AppArmor and Seccomp (windows nodes for instance).
This change doesn't affect security, neither adds breaking changes, since AppArmor and Seccomp are rarely used.
And set by default to the same values, as operator added.

Related issue #1120

Signed-off-by: f41gh7 <nik@victoriametrics.com>
@f41gh7 f41gh7 mentioned this issue Oct 15, 2024
Merged
f41gh7 added a commit that referenced this issue Oct 15, 2024
@f41gh7
build/security: removes AppArmorProfile and SeccompProfile from defau…
a62852a 
…lts (#1129)

It allow to use strictSecurity with hosts without AppArmor and Seccomp (windows nodes for instance).
This change doesn't affect security, neither adds breaking changes, since AppArmor and Seccomp are rarely used.
And set by default to the same values, as operator added.

Related issue #1120

Signed-off-by: f41gh7 <nik@victoriametrics.com>
@f41gh7 f41gh7 added the waiting for release The change was merged to upstream, but wasn't released yet. label Oct 15, 2024
@f41gh7
Copy link
Collaborator

f41gh7 commented Oct 15, 2024

Issue must be fixed at v0.48.4 release

@f41gh7 f41gh7 closed this as completed Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working waiting for release The change was merged to upstream, but wasn't released yet.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jfroy @f41gh7 @suhasagasthya