Ansible based operador cant retrieve username that instantiated a crd

[jangel97]

Type of Issue

Feature Request

Description

As a new developer of Ansible-based operators, I've noticed that the operator is not able to retrieve the username that instantiated a Custom Resource Definition (CRD). This functionality is crucial for our workflows, not only for the purposes of tracking user-resource interactions, but also for impersonating user permissions.

Impersonating the user permissions can be essential in scenarios where certain operations or functionalities of the operator need to run with the same access privileges as the user who created the CRD. This allows the operator to act on behalf of the user and maintain the same level of security and access control as if the operations were being performed directly by the user.

Proposed Solution

I propose adding a feature that enables the Ansible-based operator to retrieve the username that initiates the instantiation of a CRD and to impersonate the user permissions for the instantiated resource. The information about the user and their permissions could be retrieved from the Kubernetes API or the metadata associated with the CRD instantiation event.

Thank you in advance,

[varshaprasad96]

Adding some thoughts here:

CRDs by default do not contain any field to know the user who created it. The few possible ways it can be done on server side is by enabling audit logs and verifying the event of CRD creation: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/#synopsis. On the client-side, (as mentioned) it should be possible by adding custom annotations to the CRD. Usually in go, with the help of controller-runtime client we can fetch the CRD and investigate the custom annotations being set:

crd := &apiextensionsv1.CustomResourceDefinition{}
	err = c.Get(context.TODO(), client.ObjectKey{Name: <crdName>}, crd)
	if err != nil {
		// log error and do something
	}

	// Retrieve the annotation from the CRD's metadata
	annotations := crd.GetAnnotations()
	owner := annotations["<>"]

Based on the tutorial here, looks like kubernetes.core.kubectl collections should be helpful in providing clients that help in interacting with cluster. However, since I don't have much knowledge in ansible, will leave it to the community to provide more info.

[everettraven]

Based on the information provided, the information shared by @varshaprasad96 is the same information I would have shared.

@jangel97 I do have a clarifying question:

When you say:

I've noticed that the operator is not able to retrieve the username that instantiated a Custom Resource Definition (CRD). This functionality is crucial for our workflows, not only for the purposes of tracking user-resource interactions, but also for impersonating user permissions.

Do you actually mean the CustomResourceDefinition Kubernetes resource or are you referring to an instance of a Custom Resource?

If you are looking for a way to get user information when they create a Custom Resource (i.e a resource called Foo that your operator reconciles), you should be able to get that information via an admission webhook. According the the Kubernetes Admission Webhook Request docs it looks like it includes a userInfo field that contains username, uid, and groups of the user that is attempting to create the resource.

[jangel97]

Hello @everettraven ,

Do you actually mean the CustomResourceDefinition Kubernetes resource or are you referring to an instance of a Custom Resource?

I am refering to the instance of a Custom Resource.

I am coding an operator that can provision kubevirt VMs and PVCs, I have a CRD called ITVM, so my customers can create VMs following our internal process. In this CRD, there is a field, the .spec.namespace, and people can choose in which namespace they provision a system.

My concern is that if operator has permissions to provision kubevirt VMs in the namespaces of multiple users, that means that a given customer could specify another namespace and provision a thousand VMs there, breaking the quota of another team. When I was thinking on possible solutions on how to approach this, I considered whether deploy an operator instance of having a central cluster-scoped operator capable of impersonating the user when creating the kubevirt VM and the PVCs. I do not know how that would work with the reconciliation loop of the operator.

Maybe having operators impersonate user permissions it is not a valid feature for any use-case, I do not know if it makes sense from a community/ecosystem perspective. Do you know of any possible patterns that I can use to prvent this behaviour?

After reading your response, I was considering maybe to create Admission Controller that checks spec of ITVM and validates if the user is allowed to have operator create those resources. Would that be a correct pattern?

Kind regards and thank you for your help and insight!

[everettraven]

@jangel97 Thanks for the additional information on what you are trying to accomplish!

I am coding an operator that can provision kubevirt VMs and PVCs, I have a CRD called ITVM, so my customers can create VMs following our internal process. In this CRD, there is a field, the .spec.namespace, and people can choose in which namespace they provision a system.

My concern is that if operator has permissions to provision kubevirt VMs in the namespaces of multiple users, that means that a given customer could specify another namespace and provision a thousand VMs there, breaking the quota of another team. When I was thinking on possible solutions on how to approach this, I considered whether deploy an operator instance of having a central cluster-scoped operator capable of impersonating the user when creating the kubevirt VM and the PVCs. I do not know how that would work with the reconciliation loop of the operator.

So this would be my recommendation:

1. Make your ITVM CRD a namespace scoped resource. This allows you to get rid of the spec.namespace field and instead your custom resources will have to have the metadata.namespace field populated to create them in a particular namespace. This allows allows for much more fine-grained controls over permissions for creating these resources via RBAC. I think this should address your concerns around a customer being able to request that VMs are provisioned in other namespaces because in this method they should only be able to provision VMs in namespaces they have permission to create ITVM resources in. This also means your operator doesn't have to impersonate the user.
2. Create a cluster-scoped operator that is capable of reconciling the ITVM custom resources in any namespace.

Maybe having operators impersonate user permissions it is not a valid feature for any use-case, I do not know if it makes sense from a community/ecosystem perspective. Do you know of any possible patterns that I can use to prvent this behaviour?

Hopefully my recommendation above helps. There could be a valid use-case for needing to impersonate user permissions, but I can't think of any off the top of my head. As far as I am aware, I don't think your use case necessitates this requirement but I could have misunderstood.

[everettraven]

@jangel97 I wanted to follow up - has this issue been resolved?

[everettraven]

Closing this issue as there has been no further response from the issue author. Please feel free to reopen this issue if you feel it was closed in error

[jangel97]

@everettraven sorry for not coming back to this, yes my issue has been resolved and thank you for your clarification!