Unable to specify securityContext.fsGroup needed for AWS OIDC authentication of the pod

[jalkjaer]

Since the flink containers runs as user flink, its currently impossible to use EKS serviceAccount/IAM role "binding" directly. The problem is described in this external-dns PR
Solution is to set the securityContext.fsGroup to a group id that the flink user belongs to (so that mounted files belongs to that gid ). The CRD doesn't allow that atm. My current workaround is to extend the flink image so it runs root (USER root, plus modifying the docker-entrypoint.sh script)
It would also be nice if the CRD allowed overriding the serviceAccount used instead of just the namespace default sa.

[Jeffwan]

Can you update deployment and add securityContext.fsGrou to achieve that?

[jalkjaer]

As a manual workaround that obviously work (fsGroup: 9999) and could be applied as a patch
But I'll stick to my current workaround as that doesn't introduce an additional step which can't be performed by kustomize / helm (i think)

[stylius]

securityContext is also necessary to mount persistent storage provisioned with volumeClaimTemplate by non-root apps. Flink runs as uid 9999 and gid 9999 and by default does not have write permissions to those volumeClaimTemplates.

Ugly workaround is to run an initcontainer to set the permissions recursively before running Flink, but it would be much more elegant if securityContext support is added.

[jalkjaer]

Its now supported in the master version. The helm chart in master is missing some permissions and for some reason the CRD doesn't actually declare the new fields, but they are mentioned here
https://github.com/GoogleCloudPlatform/flink-on-k8s-operator/blob/master/docs/crd.md
I have hacked something together locally, which is not really in a state for a PR, but you can try to bump the operator image to
gcr.io/flink-operator/flink-operator:v1beta1-8
since it doesn't seem to be strictly validating you FlinkCluster resource against the deployed CDR