Add ability to pass 'dnsConfig' and 'securityContext' attributes in the 'operator' deployment resource.

[mihkelparna1]

Fixes #2070

Description

• Add ability to pass 'dnsConfig' and 'securityContext' attributes in the 'operator' deployment resource.

Checklist

• No secrets, sensitive information, or unrelated changes
• Lint checks passing (make lint)
• Generated assets in-sync (make validate-generated-assets)
• Go mod artifacts in-sync (make validate-modules)
• Test cases are added for new code paths

Testing

Tested out by rendering out all options ( Fields set, fields unset, rendering both options )

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[rajathagasthya]

/ok-to-test 62fc72b

[rajathagasthya]

@mihkelparna1 Would you be able to address the review comments so we can get this PR merged soon? Thanks!

[rajathagasthya]

/ok-to-test 064b47b

[rajathagasthya]

Testing steps

Additive dnsConfig

Adds search domains and a custom nameserver on top of the cluster DNS. dnsPolicy
left empty so it falls back to k8s default (ClusterFirst).

operator:
  dnsConfig:
    nameservers:
      - 1.1.1.1
    searches:
      - corp.example.com
    options:
      - name: ndots
        value: "2"
      - name: timeout
        value: "1"
  securityContext:
    runAsNonRoot: true
    runAsUser: 65532
    runAsGroup: 65532
    fsGroup: 65532
    seccompProfile:
      type: RuntimeDefault

dnsPolicy: None

Forces the pod to ignore cluster DNS entirely. Useful to confirm the new dnsPolicy
template branch works.

operator:
  dnsPolicy: None
  dnsConfig:
    nameservers:
      - 8.8.8.8
      - 8.8.4.4
    searches:
      - svc.cluster.local
      - cluster.local
    options:
      - name: ndots
        value: "5"

[rahulait]

Thanks for the PR @mihkelparna1. Is this change required only for gpu-operator deployment? We have a bunch of other operands provisioned by gpu-operator once installed, so they should also get blocked if kyverno/OPA wants them to be set before admitting resources. Are you not seeing them blocked in your case? Trying to make sense as to why only gpu-operator deployment (seen during helm rendering) needs this and not the rest of the operands (rendered later on by gpu-operator pod).