Support for Configuring imagePullSecrets for Collector and Agents without ServiceAccount

[dvdlevanon]

Component(s)

collector, auto-instrumentation

Is your feature request related to a problem? Please describe.

Both the Collector and the Agent (sidecar) require images to be available, and in scenarios where these images are stored in private Docker registries, there is no native support to configure imagePullSecrets directly in the Operator (or via CRDs).

Currently, various GitHub issues have been raised regarding this limitation, and the suggested workaround has been to use service accounts with pull permissions. However, this approach is not always feasible due to the following reasons:

• Lack of Control: As a DevOps engineer, I do not have control over the service accounts used by different teams. Modifying service accounts often requires additional permissions and coordination, which is not always possible.
• Operational Complexity: Teams are hesitant or unable to modify service accounts due to security policies and operational constraints. This leads to significant delays and complexities in deploying monitoring solutions.

Referenced GitHub issues highlighting similar concerns:
Issue #2521
Issue #2161
Issue #1340
Issue #1153
Issue #846

Describe the solution you'd like

The ability to configure imagePullSecrets directly within the CRDs for both the Collector and Instrumentation or from the Operator command line arguments, just like the Image parameter.

This change would significantly streamline the process of deploying OpenTelemetry components in environments where private Docker registries are used, and service account modifications are not feasible or not easy.

Benefits:

• Ease of Configuration: Allowing imagePullSecrets to be set directly in the CRDs will make it easier for DevOps engineers to manage and deploy monitoring infrastructure without needing elevated permissions.
• Security Compliance: This approach aligns with security best practices by limiting the need for broad service account modifications and adhering to the principle of least privilege.
• Operational Efficiency: Simplifies the deployment process, reducing operational overhead and facilitating faster rollout of monitoring solutions across teams.

Describe alternatives you've considered

No response

Additional context

I do not have any issues implementing this feature and am ready to contribute the necessary changes. However, I need assurance that the solution will be accepted and merged. It is important to recognize that relying solely on service accounts is not sufficient for all use cases. Approval to proceed with this enhancement will enable me to address the limitations effectively.

I appreciate your attention to this matter and look forward to a resolution that will enhance the flexibility and usability of the OpenTelemetry Operator.

Thank you for your consideration.

[jaronoff97]

@dvdlevanon thank you for bringing this up including your specific use case. We're going to discuss this at our next sig meeting which is at 12:00PM EST this coming thursday the 118th, if you could attend that would be great.

[pavolloffay]

The ability to configure imagePullSecrets directly within the CRDs for both the Collector and Instrumentation or from the Operator command line arguments, just like the Image parameter.

Would adding imagePullSecret to the collector and instrumentation CRD work as well for you?

[dvdlevanon]

Yes @pavolloffay - as long as we don't need to update other team's service account its fine.

@jaronoff97 Thanks, I would like to join, where can I get a link to join?

[jaronoff97]

@dvdlevanon you can find a link at the top of this doc :)