That is a great question.
Kubernetes does not have the notion of a ‘resource owner’ as far as I know which makes this type of dynamic authorization requirement bit complex to implement. Also, the issue is not limited to namespaces but applies across the board for all the resources. For instance, a requirement similar to what you have identified could be to have a service account create a ConfigMap and then only have the ability to to view, get, list, etc. that ConfigMap and not other ConfigMaps. We cannot define a Role that generically gives required permissions on the ConfigMap resource type as that will grant those permissions on all the configmaps to the service account and not for the only ones that it has created. So the issue is not limited to namespaces but is more general.
I don’t know if it is possible to achieve this via static RBAC configuration.
It might be possible to achieve this with a Admission controller. Here is a thought design of how this can be done. The admission controller can keep track of specific resources that are getting created (say, namespaces, configmaps, etc.) and then updates the definition of the Role that is granted to our Service Account with the names of the created resources. The admission controller will need to be configured with the list of Service Accounts tokens corresponding to the Service Accounts whose requests we want to intercept. When a request is received, the admission controller will decide whether to process the request (track the resource name, update Role definition, etc.) based on the token in the request.