Restrict access to Secrets

[pleshakov]

NGINX Gateway Fabric has read access to all Secrets in the cluster -- https://github.com/nginxinc/nginx-gateway-fabric/blob/6d4cfd7f0de32e9f98dae358cb6cec93529109a5/deploy/manifests/nginx-gateway.yaml#L34

This means if NGINX Gateway Fabric is compromised, an attacker can get access to all Secrets in the cluster.

Let's consider restricting access. For example, to only read from a certain namespace(s). Other ideas are welcomed!

[brianehlert]

This comes from a least privilege security policy and stance.
It is less about the future possibility that the controller process might be compromised but rather that it should not be doing anything with any secrets beyond those necessary to serve its functions or the applications it is serving.

It is not uncommon for customers to now take the stance of assuming they are compromised. And in this point of view the object is always to reduce the impacts of any such compromise.

The capability to scope secrets and secret access gives an auditable way (through producing configuration) to prove a stance like this.

[sjberman]

@pleshakov The only way I can think of using RBAC to restrict watching Secrets is using namespace-based Roles instead of including Secrets in the Clusterrole. This means either a user would have to create these Roles, or we would need a flag in our helm chart where a user can specify a list of namespaces, in which case we create Roles in those namespaces to watch Secrets. This would obviously only apply to the helm chart installation method.