Externalize tls version and security protocols configuration on mail sending#5119
Externalize tls version and security protocols configuration on mail sending#5119nvazquez merged 2 commits intoapache:mainapache/cloudstack:mainfrom GutoVeronezi:externalize-tls-version-and-security-protocols-configuration-on-mail-sendingGutoVeronezi/cloudstack:externalize-tls-version-and-security-protocols-configuration-on-mail-sendingCopy head branch name to clipboard
Conversation
|
@blueorangutan package |
|
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔️ centos7 ✔️ centos8 ✔️ debian. SL-JID 275 |
|
@GutoVeronezi It makes sense to make this configuratble, but should we allow it to be different for alert and project? seems like it is a true global setting. |
|
Trillian Build Failed (tid-1005) |
@DaanHoogland I am following the way mail settings are implemented today; each scope (quota, alert and project) has its own settings. Although, I don't see any plausible reason to keep settings to each scope (it seems that an operator could use different providers to send mail is a remote probability). I think that if we turn these global, we should turn those too, to maintain the same pattern. |
makes sense. |
|
Can anyone review this? |
RodrigoDLopez
left a comment
There was a problem hiding this comment.
Nice work @GutoVeronezi
The Code LGTM, i will try run some manual tests. But i'm not sure if i can do this in my env.
|
@blueorangutan package |
|
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔️ el7 ✔️ el8 ✔️ debian. SL-JID 550 |
|
@DaanHoogland @RodrigoDLopez is there anything else to do? |
|
Trillian Build Failed (tid-1324) |
|
Packaging result: ✔️ el7 ✔️ el8 ✔️ debian. SL-JID 599 |
|
@blueorangutan package |
|
@nvazquez a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
@GutoVeronezi as the PR is only exposing config keys for existing properties I think a round of tests will be enough as there are no changes in the functionality |
|
Packaging result: ✔️ el7 ✔️ el8 ✔️ debian. SL-JID 608 |
|
@blueorangutan test |
|
@nvazquez a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
Trillian test result (tid-1326)
|
|
Merging based on approvals and test results as failures are intermitent issues |
|
Trillian test result (tid-1331)
|
Description
Some servers (such as Microsoft exchange) are deprecating TLSv1 and TLSv1.1. On alert's and project's mailing settings, ACS uses the protocol TLSv1; therefore, operators do not have options to choose which version they want to use.
ACS has configurations (
\*.smtp.useAuth) to inform if it will use secure SMTP authentication when sending emails; However, this configuration only refers to the use of SSL. Operators have no means to choose if they want to use StartTLS option.This PR intends to externalize the protocol's and StartTLS settings on alert's and project's mail sending. Alert and project (also quota) send email through the class
SMTPMailSender, inserted in PR 4954, which will handle these configurations.Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
How Has This Been Tested?
It was tested in a test lab.
I set SMTP global settings to project and alert and enabled StartTLS (global setting); Then I allowed
Less secure app accesson my Google account and set the following settings:project.invite.requiredand added a user via email;In Gmail, we have an option to
show originalmessage, which provides the TLS version and the cipher. So I changed the configuration a few times and sent some alerts and invitations to verify if both versions, in configuration and Gmail, were the same.