search

tetratelabs / tetrate-service-bridge-sandbox

Deploy Tetrate Service Bridge Demo on Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) and/or Elastic Kubernetes Service (EKS) using Terraform
Apache License 2.0
12 stars 10 forks source link

Allow explicitly setting the cluster names #221

Closed nacx closed 9 months ago

nacx commented 1 year ago

Right now the cluster names for the TSB cluster objects are generated from the cloud and cluster id. We should allow configuring the cluster names in the top-level variables so that the TSB objects have predictable names known beforehand. This would allow users write policies and configurations such as authz policies like in https://github.com/tetrateio/tetrate-service-bridge-sandbox/issues/169, or workspace namespace selectors that include cluster names, without having to change them depending on how the infrastructure was deployed.

smarunich commented 1 year ago

none of authz policies (aside of RBAC) should rely on a physical abstracts like cluster or namespace i.e. Management Plane should abstract and assist, that goes to the point of workspace or tenant should include cluster object and technically it does not make sense that we do have cluster as outbound of band construct within TSB.

I do hear the ask though, it does make sense - but at this stage the benefit to it - it is a workaround of the product functionality.

nacx commented 1 year ago

No, those statements are not true.

Clusters are valid API objects and related to service accounts that configure what gitops can do: own the org, just a tenant, etc. It is very valid to have those as part of custom authz policies.

Clusters in Workspaces selectors are very valid constructs. Environments that expand multiple clusters but not the entire fleet are very real, and it is not a product workaround. It is a lack of flexibility of this repo that for no good reason .makes it harder to model those environments.

smarunich commented 1 year ago

Hard-coding in demos is a fine approach, but hard-coding in a general is not, that is why I have decided to have a cluster names to be generated, as I simply could :)

nacx commented 1 year ago

Hard-coding in demos is a fine approach, but hard-coding in a general is not

Why is it not OK to configure a workspace to capture concrete clusters? I think it is a very real use case.

smarunich commented 1 year ago

addressed as part of https://github.com/smarunich/tetrate-service-express-sandbox, I will back port it here...