@tchughesiv @franciscojavierarceo @dmartinol when you get a chance, could you please provide review/feedback on this PR? Thanks!

@redhatHameed one thing that's not obvious to me is how the test.py script makes use of the service account that is being used to connect to the feature store. I'm assuming it's automatically using some environment variable somewhere or something like that, but I'm not sure. Can we document that so it's more explicit?

I expect users will want to be able to connect to a feature store instance from a script that isn't running inside of a kubernetes pod, and I'm assuming doing so would require them to specify the token somewhere, so we should make it clear how they can do so.

@redhatHameed one thing that's not obvious to me is how the test.py script makes use of the service account that is being used to connect to the feature store. I'm assuming it's automatically using some environment variable somewhere or something like that, but I'm not sure. Can we document that so it's more explicit?

@accorvin Right, it's getting directly from the pod location. /var/run/secrets/kubernetes.io/serviceaccount/token
https://github.com/feast-dev/feast/blob/master/sdk/python/feast/permissions/client/kubernetes_auth_client_manager.py#L15
I will add this note.

I expect users will want to be able to connect to a feature store instance from a script that isn't running inside of a kubernetes pod, and I'm assuming doing so would require them to specify the token somewhere, so we should make it clear how they can do so.

That's also possible, we can use environment variable LOCAL_K8S_TOKEN https://github.com/feast-dev/feast/blob/master/sdk/python/feast/permissions/client/kubernetes_auth_client_manager.py#L50
let me change the example using locally instead from the pod and add missing document.

@accorvin can you take another look of this PR, I have updated the notebook to use local client instead of the pod. Thanks

I would contextualize some of the documentation that this is mostly relevant if you're an MLOps Engineer or Cluster Admin trying to add Feast to your k8s cluster.

@franciscojavierarceo Thanks yes make sense,

I have separated notebooks for setup operator and RBAC - > 1-setup-operator-rbac.ipynb which need to perform Admin or MLOps Engineer,

and client notebook -> 2-client.ipynb for specific to developer

@franciscojavierarceo can we merge this so it can be part of today release if we are planning for that. Thanks

@redhatHameed while i understand the addition of local workstation client example ... where did the pod to pod (admin vs client) example go? shouldn't we have those as well? after all, restricting authorization from pods within the cluster is probably the more common use case here. its also the cleaner way to demonstrate how RBAC works in feast.

Can you add that part of the example back but keep the local workstation bit as secondary example as well?

i fear this is too complex ... maybe we pivot to demoing remote registry access here instead? much of the local workstation client stuff would do better as a separate example, unrelated to RBAC.

I have an outstanding task to add an additional example around using the feature-server endpoints of an operator deployed feature store. i may play around with some of these rbac docs at the same time. i think this example would benefit from a remote registry use-case ... maybe even using the feature-server endpoints directly

@redhatHameed while i understand the addition of local workstation client example ... where did the pod to pod (admin vs client) example go? shouldn't we have those as well? after all, restricting authorization from pods within the cluster is probably the more common use case here. its also the cleaner way to demonstrate how RBAC works in feast.

Can you add that part of the example back but keep the local workstation bit as secondary example as well?

@tchughesiv thanks for pointing that, I have updated and added that example in this PR #5147 which contain now client example using local environment and from the pod.