Manage SELinux booleans about security-profiles-operator HOT 10 CLOSED

I don't think we'd explicitly need a CRD for this. I think it would be appropriate to add such a configuration to the SPOD CRD instead.

from security-profiles-operator.

@JAORMX is there a list of booleans we should support? Or should we just use a plain map of enabled/disabled booleans and error with an event if they're not supported?

from security-profiles-operator.

I don't have a list ready from the top of my head. The tricky thing is that a given system might have many. It would surely be easier just to take a plain map and issue an event if it's not supported. But that doesn't provide for great usability, as an administrator wouldn't have a good notion of what's available. On the other hand, adding the available booleans as a status would also be quite overwhelming. I don't have a good answer for this... The best thing I can think of is having the SPOD output the booleans to a configmap, and store the config map reference in the SPOD's status.

If we merely want to have support for folks easily toggling booleans, the plain map is the best I can think of.

from security-profiles-operator.

@saschagrunert I think the best thing is to come up with concrete examples of what folks would normally need to toggle and optimize for that in the beginning.

from security-profiles-operator.

@JAORMX sounds good to me! I'm not sure if the list of available booleans would vary across systems, then we could not plainly sync them from a config map or status field.

Having a plain map which the SPO tries to enforce seems the best way forward, though.

from security-profiles-operator.

@saschagrunert the booleans will vary accross systems depending on what policy they're based on. Basically, there are two main SELinux base policy groups out there:

• Upstream SELinux-based
• Fedora-based

They have variations in how policies are implemented and some booleans may also vary.

The ConfigMap outputting the booleans could be merely a status implementation... if nothing else.

from security-profiles-operator.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

from security-profiles-operator.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

from security-profiles-operator.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

from security-profiles-operator.

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

from security-profiles-operator.