SecurityContext vs PodSecurityContext in the target allocator CR

[jaronoff97]

Component(s)

operator

What happened?

Description

Right now, the securityContext for the TA is using the PodSecurityContext. This naming creates a problem. The PodSecurityContext object has these fields. The SecurityContext object has these fields. Unfortunately, there is a difference in these fields, here's the distinct set:

PODSECURITYCONTEXT

SupplementalGroups []int64 `json:"supplementalGroups,omitempty" protobuf:"varint,4,rep,name=supplementalGroups"`
FSGroup *int64 `json:"fsGroup,omitempty" protobuf:"varint,5,opt,name=fsGroup"`
Sysctls []Sysctl `json:"sysctls,omitempty" protobuf:"bytes,7,rep,name=sysctls"`
FSGroupChangePolicy *PodFSGroupChangePolicy `json:"fsGroupChangePolicy,omitempty" protobuf:"bytes,9,opt,name=fsGroupChangePolicy"`

SECURITYCONTEXT

Capabilities *Capabilities `json:"capabilities,omitempty" protobuf:"bytes,1,opt,name=capabilities"`
Privileged *bool `json:"privileged,omitempty" protobuf:"varint,2,opt,name=privileged"`
ReadOnlyRootFilesystem *bool `json:"readOnlyRootFilesystem,omitempty" protobuf:"varint,6,opt,name=readOnlyRootFilesystem"`
AllowPrivilegeEscalation *bool `json:"allowPrivilegeEscalation,omitempty" protobuf:"varint,7,opt,name=allowPrivilegeEscalation"`
ProcMount *ProcMountType `json:"procMount,omitempty" protobuf:"bytes,9,opt,name=procMount"`

Although there is a difference here, I would argue that the current bug is that our fields are misnamed and this breaking change is actually a bug fix. I believe we should adjust the TA to embed the fields the same way the collector does in the current version.

Kubernetes Version

n/a

Operator version

n/a

Collector version

n/a

Environment information

n/a

Log output

n/a

Additional context

n/a

[jaronoff97]

Closed by #2492, follow up todo in #2495