search

opea-project / GenAIInfra

Containerization and cloud native suite for OPEA
Apache License 2.0
16 stars 22 forks source link

[ChatQnA integration between GMC and OneClick] Suggest new ServiceAccount and RBAC for all ChatQnA microservices #63

Open zhlsunshine opened 1 month ago

zhlsunshine commented 1 month ago

Hi Team,

There should be the ServiceAccount RBAC setting for all ChatQnA microservices under a namespace, eg gmc rbac. However, I can not find such setting configurations in ChatQnA. There are 2 suggestions for this:

  1. New ServiceAccount yaml for all ChatQnA microservices in the same namespace instead using default.
  2. New RBAC yaml for above new service ServiceAccount. Please correct me if I'm incorrect.
mkbhanda commented 1 month ago

@yongfengdu would you kindly provide your opinion on this issue. Perhaps an alternate suggestion. Does it make sense to have a single service account for GMC?

yongfengdu commented 1 month ago

I'm not expert on security, so I think the best way is to leave the decision to k8s cluster admin(To modify default policy or create new one) or workload deployer. To implement a RBAC for ChatQnA might improve the security a little by default, but without a thorough security review, it's hard to say how "Secure" our deployment is, and it should not be trusted by the deployer. To summarize, I think implement the RBAC in current phase would introduce additional complexity and maintenance effort with little benefits.

lianhao commented 1 month ago

@yongfengdu I guess the use of rbac here is for GMC to access the k8s API objects. I think we have 2 options here:

  1. Each workload defines a RBAC role for GMC.
  2. GMC inject its own RBAC role for when deploying workload.