Customer configs - Existing EKS Cluster

We have a customer who wants to install app in their existing EKS cluster using airgap bundle.
After providing them the installation instruction they came back with below questions.

For security and compliance reasons we need to provide annotations, Pod SecurityContext, Container SecurityContext, k8s service annotations, Pod Label. How do we achive this for KotsAdmin and Application? Can we update the manifest files for KotsAdmin and Application before installation?

Can someone guide me on how to achieve this as part of installation?

Hi ! Great question.
One option: kubectl kots install has a flag --strict-security-context that can be used. Our documentation details also other additional flags that can be used.

Other option: The customer can also generate the manifest using the kots admin-console generate-manifests command. That should give them 100% flexibility to change them to their own needs. Do know that if they change the manifests and it breaks kotsadm we might not be able to support.

Thanks @jdewinne.

There are no flags for labels or other things. So I am assuming only option is generating the manifest.
I have also asked them to provide a spec of these customizations. I will post it here once available.

This is the security SPEC customer wants to apply. How does --strict-security-context works in below context?

  serviceAccountName: <non-default-K8s-serviceaccount-name>
    fsGroup: <min: 1000 max: 65535>
  - name: <container-name>
      privileged: false
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsGroup: <min: 1000 max: 65535>
      runAsNonRoot: true
      runAsUser: <min: 1000 max: 65535>
        - ALL

The command line flags allow you to tell KOTS to be a bit more restrictive with what it requires/expects. This include minimal-rbac which can help if the cluster scoped permissions aren’t desired.

However, those are the only options implemented today. The product manager of KOTS has confirmed they have seen requests for more direct customization including labels, annotations, etc. Until those are available modifying the manifests from generate-manifest as described above is the only way to do very specific customizations.

If you would like to talk to our product team to ensure they understand your use case for future feature additions please use → support → Request a Feature and you formally request new features for your use case.

I have the same ticket open, tagged as sc::59455