Dynamically generate namespace and rbac from user attributes

[gberche-orange]

Thanks for maintaining this great project over the years. Here is an idea in the context of a k8s-centric Internal Develop Platform

In the pinniped tutorial at https://pinniped.dev/docs/tutorials/concierge-and-supervisor-demo/#configure-rbac-rules-for-the-developer-and-devops-users, the namespace and rbac granted to a user are statically created by an operator

For this tutorial, we will keep the Kubernetes RBAC configuration simple.

# Create a namespace in the first workload cluster.
kubectl create namespace "dev" \
  --kubeconfig workload1-admin.yaml

# Allow the developer to edit everything in the new namespace.
cat <<EOF | kubectl create --kubeconfig workload1-admin.yaml -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-can-edit-dev-ns
  namespace: dev
subjects:
- kind: User
  name: [email protected]
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io
EOF

# In the second workload cluster, allow the developer
# to view everything in all namespaces.
kubectl create clusterrolebinding developer-can-view \
  --clusterrole view \
  --user [email protected] \
  --kubeconfig workload2-admin.yaml

I'm exploring a scenario where namespaces and rbac are automatically created/mirrored from the upstream identity sources, using templating with upstream identity providers attributes as inputs (username, groups, email ...), with some vague similarities to pinniped transformation expressions

pinniped/site/content/docs/howto/supervisor/configure-supervisor-federationdomain-idps.md

Lines 177 to 184 in 876f626

	Each time a user attempts to authenticate, and each time a user's session is automatically refreshed periodically,
	the list is evaluated in the order that it was declared.
	`username/v1` expressions may change the username that is passed to the next expressions.
	`groups/v1` expressions may change the group names that are passed to the next expressions.
	`policy/v1` expressions may halt the processing of further expressions when they reject the authentication.
	Because each expression in the list can pass information to the following expressions via its return values,
	the list of expressions acts like a "pipeline".
	Any unexpected runtime evaluation errors (e.g. division by zero) cause the authentication to fail.

Let's take the example of a user who has an identity on a gitlab IDP, is member of multiple groups, this templating system would map these groups to a set of namespaces and rbac resources, so that the user can then subscribe to cloud resources through K8S CRs within these namespaces.

Can you think of a way pinniped could help in this scenario ? Are you instead aware of other community projects that could be setup to fulfill this goal ?