Authorization token for ignition server does not refresh

[raz-bn]

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]

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]

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:

cluster-api-provider-kubevirt/controllers/kubevirtmachine_controller.go

Line 572 in 48146e1

bootstrapDataSecret := &corev1.Secret{}

[davidvossel]

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]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[nirarg]

/remove-lifecycle stale

[k8s-triage-robot]

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

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

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten