fix(tls): use fixed-length cert CommonNames

[andrewazores]

Welcome to Cryostat! 👋

Before contributing, make sure you have:

• Read the contributing guidelines
• Linked a relevant issue which this PR resolves
• Linked any other relevant issues, PR's, or documentation, if any
• Resolved all conflicts, if any
• Rebased your branch PR on top of the latest upstream main branch
• Attached at least one of the following labels to the PR: [chore, ci, docs, feat, fix, test]
• Signed all commits: git commit -S -m "YOUR_COMMIT_MESSAGE"

---

Fixes: #964

Description of the change:

This change adds allows the users to provide...

Motivation for the change:

This change is helpful because users may want to...

How to manually test:

1. Insert steps here...
2. ...

[andrewazores]

/build_test

[github-actions]

/build_test completed successfully ✅.
View Actions Run.

[ebaron]

Seems pretty straightforward, I just want to check first if this breaks anything when upgrading the operator. I'm worried something like #896 will happen.

[ebaron]

Yeah, I'm getting a 503 error after upgrading using the steps in #897. I think the easiest fix would be expand the check from #897 to compare the entire certificate spec and not just the secret name. This doesn't solve the certificate expiry issue (#119), but at least should get us back to the current state.

[andrewazores]

The check from #897 looks like it's just checking the SecretName referenced by the CA Issuer, and the Issuer's Spec only really contains the SecretName.

cryostat-operator/internal/controllers/common/resource_definitions/certificates.go

Line 51 in 0ec9a84

SecretName: NewCryostatCACert(gvk, cr).Spec.SecretName,

cryostat-operator/internal/controllers/common/resource_definitions/certificates.go

Line 66 in 0ec9a84

SecretName: common.ClusterUniqueNameWithPrefix(gvk, "ca", cr.Name, cr.InstallNamespace),

cryostat-operator/internal/controllers/certmanager.go

Line 310 in 0ec9a84

currentSecret := current.SecretName

If I'm understanding the problem correctly, it's that the Certificates' Specs have changed (because the CommonName field has changed) - the Issuers and theirs Specs actually haven't changed. But I suppose on upgrade, a new CA gets created again and the old one needs to be invalidated and all its Certificates deleted?

[ebaron]

The check from #897 looks like it's just checking the SecretName referenced by the CA Issuer, and the Issuer's Spec only really contains the SecretName.

cryostat-operator/internal/controllers/common/resource_definitions/certificates.go

Line 51 in 0ec9a84

SecretName: NewCryostatCACert(gvk, cr).Spec.SecretName,

cryostat-operator/internal/controllers/common/resource_definitions/certificates.go

Line 66 in 0ec9a84

SecretName: common.ClusterUniqueNameWithPrefix(gvk, "ca", cr.Name, cr.InstallNamespace),

cryostat-operator/internal/controllers/certmanager.go

Line 310 in 0ec9a84

currentSecret := current.SecretName

If I'm understanding the problem correctly, it's that the Certificates' Specs have changed (because the CommonName field has changed) - the Issuers and theirs Specs actually haven't changed. But I suppose on upgrade, a new CA gets created again and the old one needs to be invalidated and all its Certificates deleted?

Right that's what needs to happen on upgrade. You're right, detecting this will be a little more complicated than just modifying the check done in #897.

One possibility is treating the certificate spec like an immutable field, and calling the deleteCertChain method when attempting to modify it. Something like:

cryostat-operator/internal/controllers/reconciler.go

Lines 512 to 518 in 0ec9a84

	// Immutable, only updated when the deployment is created
	if deploy.CreationTimestamp.IsZero() {
	deploy.Spec.Selector = deployCopy.Spec.Selector
	} else if !cmp.Equal(deploy.Spec.Selector, deployCopy.Spec.Selector) {
	// Return error so deployment can be recreated
	return errSelectorModified
	}

[andrewazores]

I found that the cmp.Equal() check on the whole cert Spec didn't behave quite how I expected, so in that latest commit I'm checking specific properties for equality. This looks like it works as expected, including in the upgrade case as outlined in #897's test steps, so once I figure out what exactly was breaking the deep equality check on the Specs then I can clean it up and I think this will be ready.

[andrewazores]

/build_test

[github-actions]

/build_test : At least one test failed ❌.
View Actions Run.

[andrewazores]

/build_test

[github-actions]

/build_test completed successfully ✅.
View Actions Run.