search

kubernetes-sigs / cluster-api-provider-kubevirt

Cluster API Provider for KubeVirt
Apache License 2.0
110 stars 63 forks source link

Authorization token for ignition server does not refresh #169

Closed raz-bn closed 1 year ago

raz-bn commented 2 years ago

When a new VM is provisioned, it pulls its authorization token from the user-data-{NAMESPACE}-{HASH}-userdata secret. The creation of this secret is happening in the kubevirtmachine controller , the source of the data contained in the secret comes from the user-data-{NAMESPACE}-{HASH} secret, which is created by the nodepool controller in HyperShift, the secret is referenced in the Machine object under the field spec.bootstrap.dataSecretName. The nodepool controller rotates the authorization token every 24H (inside the user-data-{NAMESPACE}-{HASH} secret), but there is no mechanized for rotating the user-data-{NAMESPACE}-{HASH}-userdata which means new VMs can not pull their ignition file. The only way to workaround it is to delete the user-data-{NAMESPACE}-{HASH}-userdatasecret.

/kind bug

raz-bn commented 2 years ago

I wonder if there is any reason for creating the user-data-{NAMESPACE}-{HASH}-userdata secret since it is basically identical to the user-data-{NAMESPACE}-{HASH} secret. why not just mounting the existing secret to VMs?

nirarg commented 2 years ago

The secret is duplicated because when new KubevirtMachine is created it look for userdata data key inside this secret, while the original secret is created with the data key: value

Its look like the solution should be not skipping the secret creation code if the duplication secret is already exists, but need to update the secret if the secret data was changed since the last time. here is the location for the suggested change: https://github.com/kubernetes-sigs/cluster-api-provider-kubevirt/blob/48146e1c41d730c13e159b11d147c9f0f42361e6/controllers/kubevirtmachine_controller.go#L572

davidvossel commented 2 years ago

Its look like the solution should be not skipping the secret creation code if the duplication secret is already exists, but need to update the secret if the secret data was changed since the last time.

I think that's the simplest solution for now.

Long term i want us to get out of the business of creating that separate secret for the VM/VMIs entirely. That requires deprecating the ssh and capk user support for the cloud-config types though.

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

nirarg commented 1 year ago

/remove-lifecycle stale

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten