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

feat(config/server): Add option for TLS and mTLS server #508

Merged
merged 2 commits into from
Jun 14, 2023

Conversation

annadorottya
Copy link
Contributor

What type of PR is this?

/kind feature

Any specific area of the project related to this PR?

/area config

What this PR does / why we need it: Currently only HTTP server can be deployed. It would be more secure if we could deploy TLS or mutualTLS server if wanted.

Which issue(s) this PR fixes: #507

Fixes #

Special notes for your reviewer:
The logic for config is a bit different than the one already used. I decided to add 3 config options as full paths for the 3 files needed. I feel this way it's more customizable and does not collide with the mutualtlsfilespath config. Eg. this way we could set it to the same folder but different file names, or a different folder, or reuse the files completely.

Signed-off-by: Anna Simon <asimon@mercari.com>
@poiana poiana requested review from fjogeleit and leogr June 12, 2023 06:15
@poiana poiana added the size/M label Jun 12, 2023
@Issif Issif added this to the 2.28.0 milestone Jun 12, 2023
Comment on lines 11 to 17
mutualtlsfilespath: "/etc/certs" # folder which will used to store client.crt, client.key and ca.crt files for mutual tls for outputs (default: "/etc/certs")
tlsserver:
deploy: false # if true, TLS server will be deployed instead of HTTP
certfile: "/etc/certs/server.crt" # server certification file
keyfile: "/etc/certs/server.key" # server key
mutualtls: false # if true, mTLS server will be deployed instead of TLS, deploy also has to be true
cacertfile: "/etc/certs/ca.crt" # for client certification if mutualtls is true
Copy link
Member

Choose a reason for hiding this comment

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

I'm afraid it will create confusion for end users. We have 2 different mTLS:

  • the mTLS used to authenticate falcosidekick with its outputs
  • the mTLS used by the falcosidekick's webserver
    So we can't use the same folder as they might have conflicts with the ca.crt , wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree it could be confusing that the default path is the same folder. They could rename the ca.crt for the server to something else if they need two different ones though.
One solution I see is that we could use etc/certs/server for the new ones and /etc/certs/client for the already existing ones - this sounds more logical in my mind but this would mean breaking change for those who used the default option.
Other path name that I would suggest is /etc/tls/server and leave the client one as is. Just to have something different and in the end everyone can set it to whatever they want.

Copy link
Member

Choose a reason for hiding this comment

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

Let me propose you something, it's mostly to avoid to break anything:

  • /etc/certs/ remains as is, for client and not break anything
  • /etc/certs/client/ is for client too, with client.key, client.crt and ca.crt
  • /etc/certs/server/ is for server, with server.key, server.crt and ca.crt

I'll add a message in the changelog and blog post to explain the /etc/certs is obsolete and will be replaced by /etc/certs/client/ in the falcosidekick-ui in future

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just to be clear, you mean something like this?

mutualtlsfilespath: "/etc/certs" # folder which will used to store client.crt, client.key and ca.crt files for mutual tls for outputs, will be deprecated in the future (default: "/etc/certs")
mutualtlsclient: # takes priority over mutualtlsfilespath if not emtpy
  certfile: "/etc/certs/client/client.crt" # client certification file
  keyfile: "/etc/certs/client/client.key" # client key
  cacertfile: "/etc/certs/client/ca.crt" # for server certification
tlsserver:
  deploy: false # if true, TLS server will be deployed instead of HTTP
  certfile: "/etc/certs/server/server.crt" # server certification file
  keyfile: "/etc/certs/server/server.key" # server key
  mutualtls: false # if true, mTLS server will be deployed instead of TLS, deploy also has to be true
  cacertfile: "/etc/certs/server/ca.crt" # for client certification if mutualtls is true

Not sure how to resolve the issue of which one gets priority in this case, this is what I could come up with:
By not setting default value for mutualtlsclient file values for now, it will be set to those values if they are set manually and the mutualtlsfilespath + hardcoded file names if mutualtlsfilespath is set or if it's empty (thus backfalls to the default /etc/certs value.

Copy link
Member

Choose a reason for hiding this comment

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

Ok with your solution.

For the mutualtls, do you think we could enforce deploy if it's true?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great!

I think that would be confusing eg. if I turn off the deploy for debugging, then I would expect that the whole TLS part is turned off, but it would still be on. Maybe I could set a warning log message for the deploy == false && mutualtls == true case.

Copy link
Member

Choose a reason for hiding this comment

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

Ok for the warning, thanks

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added the modifications in a new commit, let me know if it's okay with you or I should change something!

@Issif Issif closed this Jun 12, 2023
@Issif Issif reopened this Jun 12, 2023
…lTLS

Signed-off-by: Anna Simon <asimon@mercari.com>
@poiana poiana added size/L and removed size/M labels Jun 14, 2023
@poiana
Copy link

poiana commented Jun 14, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: annadorottya, Issif

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@poiana
Copy link

poiana commented Jun 14, 2023

LGTM label has been added.

Git tree hash: f0cede59caa40fcc57927e1471b0805a5f97c5bd

@poiana poiana merged commit e078680 into falcosecurity:master Jun 14, 2023
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

3 participants