Expose pod security context per component

[rubenvp8510]

No description provided.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.10%. Comparing base (c39140e) to head (1cd1cdb).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1029      +/-   ##
==========================================
+ Coverage   73.08%   73.10%   +0.02%     
==========================================
  Files         106      106              
  Lines        6624     6630       +6     
==========================================
+ Hits         4841     4847       +6     
  Misses       1493     1493              
  Partials      290      290              

Flag	Coverage Δ
unittests	73.10% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[andreasgerstmayr]

I think we should also set it on the compactor component

[rubenvp8510]

@andreasgerstmayr do you think we need to put a default value?

[andreasgerstmayr]

@andreasgerstmayr do you think we need to put a default value?

We do set a default security context on the containers, for example here:

tempo-operator/internal/manifests/ingester/ingester.go

Line 128 in c39140e

SecurityContext: manifestutils.TempoContainerSecurityContext(),

It has some common fields, but is not the same type. I'm not sure if we should set any defaults (RunAsNonRoot maybe? but that could break if users use a custom Tempo image).

Do you think the container security context should also be customizable? Then we should plan in advance and give the two different security contexts a distinctive name, for example containerSecurityContext and podSecurityContext in the CRD.

[rubenvp8510]

@andreasgerstmayr do you think we need to put a default value?

We do set a default security context on the containers, for example here:

tempo-operator/internal/manifests/ingester/ingester.go

Line 128 in c39140e

SecurityContext: manifestutils.TempoContainerSecurityContext(),

It has some common fields, but is not the same type. I'm not sure if we should set any defaults (RunAsNonRoot maybe? but that could break if users use a custom Tempo image).

Do you think the container security context should also be customizable? Then we should plan in advance and give the two different security contexts a distinctive name, for example containerSecurityContext and podSecurityContext in the CRD.

I would say we can preserve this without any default value for now. and agree on the renaming.