search

Azure / AKS

Azure Kubernetes Service
https://azure.github.io/AKS/
1.97k stars 312 forks source link

Restricting Developers from accessing selective secrets , service accounts etc #4432

Open Ashish123-abn opened 4 months ago

Ashish123-abn commented 4 months ago

**Is your feature request related to a problem? We have developers who want to access so everything inn cluster like get, list , update delete etc for all the resourses in the kubernetes namespace . for this we granted them the role "Azure kubernetes service rbac admin" and now we created a role and role binding to allow them to only view the secrets and network policy , by giving the exact names of the secrets and network policy in the role . But they can still edit those secrets and network policy .

Describe the solution you'd like

We want that developers can ONLY view the selective secrets ( that is admin secrets that we deployed in their namespace, these secrets needs to be deployed in each of the developer team namespaces ) from the given list of secrets in their namespace because other secrets in the list are managed by them ( meaning that they can do anything with thier application secrets )

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context

We need to achieve this with aks auth mechanism as "Azure Rbac" , Kubernetes Rbac auto mechanism in aks is restricted

yyvess commented 1 day ago

Look on Kubernetes 31 release note.

Kubernetes 1.31 introduces finer-grained authorization based on selectors


# Example of using finer-grained authorization with selectors
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: my-cluster-role
rules:
- apiGroups: ["*"]
  resources: ["pods"]
  verbs: ["list", "watch"]
  resourceAttributes:
    matchingLabels:
      app: my-app