Limit access to datasets to specific pods running specific images about datashim

[mrsabath]

What if your admission controller simply injects the following annotations into the user's pod:

      annotations:
        admission.trusted.identity/inject: "true"
        tsi.secrets: |
             - tsi.secret/name: "<dataset>_accessKeyID"
               tsi.secret/constraints: "region,images"
               tsi.secret/local-path: "tsi-secrets/<dataset>_accessKeyID"
             - tsi.secret/name: "<dataset>_secretAccessKey"
               tsi.secret/constraints: "region,images"
               tsi.secret/local-path: "tsi-secrets/<dataset>_secretAccessKey"

where the constraints are defined by the level of security to be imposed for this data set (e.g. only containers in specific region and from a specific image can access this data object)

And TSI would obtain the secrets from Vault and inject them to the user's container at the location specifed by tsi.secret/local-path

What do you think @YiannisGkoufas ?

[vpavlin]

Why/How is the image the deciding factor? Should it be rather whether the user is supposed to have access to this dataset?

Or maybe there is a use case that is not obvious at first glance - can you elaborate?

[mrsabath]

@vpavlin, intially, we are trying to address the simples scenario, to make sure only images that pass the compliance requirements, e.g vularabilty scan, are able to access the dataset. The example when access to the datasets depends on the userid is more challanging, just because Kubernetes was designed with a notion that users sharing a particular namespace can also share the resources in that namespace. We need to re-think this use-case whether it actually makes sense to do that. Separating the access on the namespace level is trivial, however, when different users share a namespace, it becomes tricky.

[srikumar003]

Would be interesting to take this up but is not planned currently.