Skip to content

Conversation

fealebenpae
Copy link
Contributor

@fealebenpae fealebenpae commented Jul 21, 2025

Summary

Expose new TLS capabilities in mongot.

Proof of Work

New passing test.

Checklist

  • Have you linked a jira ticket and/or is the ticket in the title?
  • Have you checked whether your jira ticket required DOCSP changes?
  • Have you checked for release_note changes?

@fealebenpae fealebenpae self-assigned this Jul 21, 2025
@fealebenpae fealebenpae reopened this Jul 21, 2025
@fealebenpae fealebenpae force-pushed the fealebenpae/search-tls branch from c8447d7 to af0b239 Compare July 21, 2025 01:37
@fealebenpae fealebenpae force-pushed the fealebenpae/search-tls branch from af0b239 to 56e5519 Compare July 21, 2025 01:56
// CertificateKeySecret is a reference to a Secret containing a private key and certificate to use for TLS.
// The key and cert are expected to be PEM encoded and available at "tls.key" and "tls.crt".
// This is the same format used for the standard "kubernetes.io/tls" Secret type, but no specific type is required.
// Alternatively, an entry tls.pem, containing the concatenation of cert and key, can be provided.
Copy link
Contributor

Choose a reason for hiding this comment

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

do we normally support tls.pem AND tls.crt in secrets? I thought we're only supporting standard tls secret types so tls.key and tls.crt only. We might have some leftovers in the codebase handling tls.pem-type secrets but we shouldn't support them anymore for new things. Could you verify it's the case here?

Copy link
Contributor Author

@fealebenpae fealebenpae Jul 21, 2025

Choose a reason for hiding this comment

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

We’re using the community operator’s tls secret handling behind the scenes which does support the concatenated tls.pem field. I copied this comment directly from the Community CRD. I am happy to drop the tls.pem thing altogether, though.

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's drop it and keep it simple, exactly the same as tls-type secrets are defined 👍

@@ -85,13 +89,28 @@ func (r *MongoDBSearchReconcileHelper) reconcile(ctx context.Context, log *zap.S
return workflow.Failed(err)
}

mongotConfig := createMongotConfig(r.mdbSearch, r.db)
configHash, err := r.ensureMongotConfig(ctx, mongotConfig)
ingressTlsMongotModification, ingressTlsStsModification, err := r.ensureIngressTlsConfig(ctx)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: can we have Tls as uppercased TLS in those names?

Copy link
Contributor

Choose a reason for hiding this comment

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

While I agree it's quite nice naming convention specifying mongot's server as ingress and mongot->mongod as egress, I'm a bit worried it's initially misleading/confusing as ingress in k8s is generally considered as a mechanism for exposing workloads externally.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How about if we call them “query” and “replication” as the search team does?

Copy link
Contributor

Choose a reason for hiding this comment

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

replication is regarded also as syncSource, at least in the config schema. Query seems OK, let's see how those work out in the codebase, but it's not super important

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That sounds good to me. I’m not attached to the names I used - I just wanted to see if things worked first.



@fixture(scope="module")
def ca_certificate(tmp_path_factory: TempPathFactory):
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we're relying on already generated ca.crt ca.key in the test resource files (look for ca.crt). So if we don't do anything more here than just ca file, we might not need this code

return ca_cert, ca_private_key, cert_file_path


def generate_server_certificate(
Copy link
Contributor

Choose a reason for hiding this comment

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

also for this consider using existing code: look for generate_cert, create_tls_certs functions and usages. We use cert-manager in e2e tests, so we don't need this custom RSA code around.

func getPem(ctx context.Context, getter secret.Getter, secretName types.NamespacedName) string {
pem, err := secret.ReadKey(ctx, getter, tlsSecretPemName, secretName)
if err != nil {
return ""
Copy link
Contributor

Choose a reason for hiding this comment

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

here as well, it doesn't look good to ignore errors like that

// This is either the tls.pem entry in the given secret, or the concatenation
// of tls.crt and tls.key
// It performs a basic validation on the entries.
func getPemOrConcatenatedCrtAndKey(ctx context.Context, getter secret.Getter, secretName types.NamespacedName) (string, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

complexity of this function is too much at first glance. Let's see how it will be if we not handle pem keys in the secret

Copy link
Contributor

@lsierant lsierant left a comment

Choose a reason for hiding this comment

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

Let's merge and cleanup/refactor this later on.

@fealebenpae fealebenpae marked this pull request as ready for review July 21, 2025 15:51
@fealebenpae fealebenpae requested a review from a team as a code owner July 21, 2025 15:51
@fealebenpae fealebenpae requested review from m1kola and viveksinghggits and removed request for a team July 21, 2025 15:51
@fealebenpae fealebenpae merged commit 5d44ddc into search/public-preview Jul 21, 2025
1 check failed
@fealebenpae fealebenpae deleted the fealebenpae/search-tls branch July 21, 2025 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants