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.

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

⚠️ Serve catalog over HTTPS #263

Merged
merged 6 commits into from
May 14, 2024

Conversation

trgeiger
Copy link
Contributor

@trgeiger trgeiger commented May 6, 2024

This adds the ability to use HTTPS on the catalog server.

If the TLS cert and key filenames are provided via the relevant flags, then the server will be set to use HTTPS. If neither or only one of those options are provided, the server will use HTTP.

This also changes the http-external-address flag to just external-address, with the user no longer prepending the address with http or https.

  • Should I add a check for if the user does have http or https in the address, and adjust it to the proper one depending on the presence of the key/cert?
  • Should we add a duplicate flag --http-external-address for backwards compatibility and just map it to the new flag if used?

This PR also includes an overhaul of the organization of the manifests. Following the example of rukpak, cert-manager is used in the Makefile build targets so HTTPS is enabled in kind, but cert-manager is not a required dependency of catalogd. Instead, it's applied as an overlay which we target in the Makefile.

everettraven and others added 3 commits May 6, 2024 09:58
adds cert-manager as a dependency again to create self-signed
certs for the catalog server

Signed-off-by: everettraven <everettraven@gmail.com>
Signed-off-by: everettraven <everettraven@gmail.com>
This allows the use of alternate certificate managers.

Signed-off-by: Tayler Geiger <tayler@redhat.com>
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 6, 2024
@trgeiger trgeiger force-pushed the https-tayler branch 2 times, most recently from 30449a5 to 5428233 Compare May 6, 2024 20:41
Copy link

codecov bot commented May 6, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 48.84%. Comparing base (250e348) to head (e7133a6).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #263   +/-   ##
=======================================
  Coverage   48.84%   48.84%           
=======================================
  Files           8        8           
  Lines         434      434           
=======================================
  Hits          212      212           
  Misses        201      201           
  Partials       21       21           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@trgeiger trgeiger force-pushed the https-tayler branch 2 times, most recently from c20a488 to d42ad79 Compare May 7, 2024 20:16
@trgeiger trgeiger marked this pull request as ready for review May 7, 2024 20:22
@trgeiger trgeiger requested a review from a team as a code owner May 7, 2024 20:22
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 7, 2024
Fix a few manifest issues as well.

Signed-off-by: Tayler Geiger <tayler@redhat.com>
cmd/manager/main.go Outdated Show resolved Hide resolved
cmd/manager/main.go Outdated Show resolved Hide resolved
internal/third_party/server/server.go Show resolved Hide resolved
@trgeiger trgeiger force-pushed the https-tayler branch 7 times, most recently from 81314f6 to 02e3232 Compare May 9, 2024 01:13
@trgeiger trgeiger changed the title ⚠ Serve catalog over HTTPS ⚠️ Serve catalog over HTTPS May 9, 2024
cmd/manager/main.go Outdated Show resolved Hide resolved
- apiGroups:
- ""
resources:
- pods
Copy link
Collaborator

Choose a reason for hiding this comment

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

Out of scope for this PR, but seeing this I don't think we need these permissions on pods anymore. we don't use a pod to unpack the catalog contents anymore and probably forgot to come back and cleanup these permissions. I'll create an issue for this.

@trgeiger trgeiger force-pushed the https-tayler branch 2 times, most recently from 904d3d7 to 04cc7c0 Compare May 9, 2024 20:02
"sigs.k8s.io/controller-runtime/pkg/certwatcher"
)

func ConfigureListener(cert string, key string, addr string, catalogAddr string, mgr ctrl.Manager) (net.Listener, string, error) {
Copy link
Member

@joelanford joelanford May 10, 2024

Choose a reason for hiding this comment

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

As I mentioned in Slack, I didn't realize how complex the signature for this function would be when I suggested it. At this point, it seems like we might as well go one step further and setup the entire server as part of this function.

I think just adding the storeDir would give us all the info we need to do that?

Also some nit suggestions on naming and order of parameters.

  • Put the manager parameter first. That aligns with other functions that configure/add stuff to the manager.
  • Group storeDir and externalAddr together, since they are used to build the storage struct.
  • Use certFile and keyFile (instead of cert and key to make it more clear that they are the filenames of the cert and key, not the cert and key themselves)
  • Group listenAddr, certFile, and keyFile together since they are used to build the listener

Putting all that together, WDYT of this?

func AddCatalogServerToManager(mgr ctrl.Manager, storeDir, externalAddr, listenAddr, certFile, keyFile string) error

Copy link
Collaborator

Choose a reason for hiding this comment

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

If we are concerned about the size of the function signature, it can probably be reduced to something like:

type CatalogServerConfig struct {
...
}

func AddCatalogServerToManager(mgr ctrl.Manager, cfg CatalogServerConfig) (net.Listener, string, error) { 
... 
}

@trgeiger trgeiger force-pushed the https-tayler branch 2 times, most recently from 7577dc3 to fa4bb3c Compare May 10, 2024 16:51
- Add error for missing either tls-key or tls-cert arguments.
- Move server creation and configuration to serverutil

Signed-off-by: Tayler Geiger <tayler@redhat.com>
everettraven
everettraven previously approved these changes May 10, 2024
Copy link
Collaborator

@everettraven everettraven left a comment

Choose a reason for hiding this comment

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

LGTM - thanks @trgeiger . I'll hold merging for a bit to allow @joelanford to take another pass

@trgeiger
Copy link
Contributor Author

Thanks, Bryce. Should we adjust anything in the readme's quickstart instructions or anywhere else in docs?

@everettraven
Copy link
Collaborator

Thanks, Bryce. Should we adjust anything in the readme's quickstart instructions or anywhere else in docs?

Ah, great question (and good catch). We should probably update the quickstart instructions for port-forwarding and the curl command for fetching catalog contents to reflect the new state with an HTTPS based server as opposed to HTTP. I think this information is also present in https://github.com/operator-framework/catalogd/blob/main/docs/fetching-catalog-contents.md

@trgeiger
Copy link
Contributor Author

How should we handle changing the instructions, given that HTTP is still supported if no TLS keys are provided, and the cert-manager is now an overlay. Do we just add that information as caveats to the instructions? Should I detail pulling down the cert and providing it to curl? etc.

@everettraven
Copy link
Collaborator

How should we handle changing the instructions, given that HTTP is still supported if no TLS keys are provided, and the cert-manager is now an overlay. Do we just add that information as caveats to the instructions? Should I detail pulling down the cert and providing it to curl? etc.

I'm not too familiar with how the overlays work, but IIUC the default deployment (i.e what is released) is going to be including the cert-manager resources and enable TLS (please correct me if I am wrong). If that is the default I would document whatever the default is.

I would not document pulling down the cert and providing it to curl and instead document with curl -k to ignore the certs. We can include a disclaimer in the docs that this is only for demonstration purposes and that if they want to trust the certificates to follow some other documentation on how to do that (I'm sure there is some documentation on this that already exists)

@trgeiger
Copy link
Contributor Author

I made a couple small edits to README.md and https://github.com/operator-framework/catalogd/blob/main/docs/fetching-catalog-contents.md, let me know what you think

everettraven
everettraven previously approved these changes May 14, 2024
Copy link
Collaborator

@everettraven everettraven left a comment

Choose a reason for hiding this comment

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

A couple nits on the docs edits but I won't hold this PR on those. Great work @trgeiger !

@trgeiger
Copy link
Contributor Author

Those were quick fixes, just made em so no need to hold off for another issue/pr for those.

@everettraven everettraven added this pull request to the merge queue May 14, 2024
Merged via the queue into operator-framework:main with commit cf384e4 May 14, 2024
12 checks passed
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.

None yet

3 participants