-
Notifications
You must be signed in to change notification settings - Fork 40.7k
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
Add support for multiple/optional trust certificates #41932
base: main
Are you sure you want to change the base?
Conversation
@elisabeteaprcd Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@elisabeteaprcd Thanks for the suggestion. We will take a look at the changes and give some feedback. An alternative to these changes would be a boolean property at the top of the bundle structure such as |
Hi @scottfrederick, Im also working with @elisabeteaprcd on this. While the scope of this change is to support optionality for the single item - which is what is currently supported by SB, the end goal is to have it working with multiple items as proposed in #38754 (comment). So, in the scenario of multiple CAs we should be able to define which ones are mandatory for the service to start and which ones are optional, and in this sense your single-property proposal would not work at the spring boot level, however it could be expressed at the k8s deployment level by making the volume mounts mandatory. |
@elisabeteaprcd Thank you for signing the Contributor License Agreement! |
4492041
to
ae68967
Compare
ae68967
to
fe27aca
Compare
hi @scottfrederick , just a heads-up that this has been now updated with support for multiple/optional certificates (initial PR had just support for optional) |
Problem Statement
The challenge is the dynamic updating and management of certificates in an application that supports mTLS and interacts with client services that are frequently added and removed.
Suppose your application needs to support mTLS with two well-known client services,
foo
andbar
, each having a specific intermediate CA (Certificate Authority). Client services are dynamically installed/removed from the cluster. For improved resiliency/manageability, you do not want to change the deployment of your application whenever a new client service is installed in the cluster: the client CAs must be dynamically added/removed to your server truststore as their services installed/removed from the cluster.Proposed Solution
This PR aims to address this issue by allowing certificates to be marked as optional. With this feature, the application can start and continue running regardless of the availability of these certificates. And allows the addition of multiple certificates as mentioned here.
Current Status
This pull request is currently a draft/proof of concept. It does not yet include tests or documentation and is intended to gather feedback. The implementation includes several TODOs.
An example of an
application.yaml
with multiple/optional certificates would look like:Some use cases:
1.The configuration with the deprecated property continues to work as expected:
TODO: Since the structure for loading certificates is the same for both keystore and truststore, should there be limitations on optionality and multiple certificates in the keystore? Should the
certificate
property allow optionality?TODO: Consider creating a validation to ensure that
certificate
andcertificates
cannot be used simultaneously.ca.crt
andca_cert
) do not exist, they will be treated as empty, as no certificates will be available for loading at that moment. However, since thereload-on-update
property is set to true, the parent directory will be monitored. Once changes are detected and the files become available, they will be loaded.isReloadOnUpdate
property is set totrue
, theca.crt
certificate will still be observed.TODO: Or should we keep the exception if one or more items in the list are not observable?
Related Issue
This PR is related to this comment in the issue #38754