Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix(tls): use fixed-length cert CommonNames #968

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix(tls): use fixed-length cert CommonNames #968

wants to merge 1 commit into from
+18 −11

Conversation

andrewazores
Copy link
Member

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
Copy link
Member Author

/build_test

@github-actions GitHub Actions
Copy link

github-actions bot commented Nov 5, 2024

/build_test completed successfully ✅.
View Actions Run.

@andrewazores andrewazores marked this pull request as ready for review November 5, 2024 19:27
@andrewazores andrewazores requested a review from a team November 5, 2024 19:27
@andrewazores andrewazores mentioned this pull request Nov 5, 2024
Draft
7 tasks
ebaron
ebaron reviewed Nov 5, 2024
View reviewed changes
Copy link
Member

@ebaron ebaron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
ebaron reviewed Nov 5, 2024
View reviewed changes
Copy link
Member

@ebaron ebaron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

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
Copy link
Member

ebaron commented Nov 6, 2024 •
edited
Loading

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
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ebaron ebaron ebaron left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
fix safe-to-test
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

[Bug] CommonName field in certificates may be too long
2 participants
@andrewazores @ebaron