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
Secure communication standard for IaaS infastructure #547
Comments
Major communication channels that need to be secured:
Resources: |
Most of the configuration adjustments proposed here cannot be verified via external tests unfortunately. Only the public-facing APIs can be checked for TLS by inspecting Keystone's service catalog, contacting each public endpoint and verifying its TLS handshake. All the internal stuff would be up to dedicated audits with access to the infrastructure. Speaking of TLS handshakes, I think we should also forbid using older/weak TLS versions and ciphers in the standard. |
I began adding TLS specifics to the standard based on the official guidelines on ssl.com1. I think we should align this to the most commonly and broadly accepted current recommendations around TLS. Footnotes |
Might I ask why you choose this specific guide? E.g. I think this guide is better: https://ssl-config.mozilla.org/ because it does not focus on compliance but on security. |
No particular reason. I was just looking for some form of official consensus on current SSL/TLS recommendations to base the standard on. I guess the Mozilla ones12 would be a good alternative. @martinmo had the same thought apparently: #548 (comment) :) I will have a look. Footnotes |
I've had a look and it seems that sslyze does indeed support checking against the Mozilla recommendations directly. We could simplify the maintenance effort for this standard by referencing Mozilla's recommendations. However, this would mean referencing recommendations which are also a moving target themselves potentially (how often does Mozilla update this?). I've put it on the agenda for the next IaaS call. |
We discussed this on the SIG Standardization / Certification call: SovereignCloudStack/minutes/sig-standardization/20240516.md#tracking-moving-targets-tls-recommendations-from-mozilla I updated the standard and test script to use the Mozilla TLS recommendations instead after figuring out how that works with the SSLyze library. Sadly, the library only ships the single most recent Mozilla TLS preset version at the time of the library version release1. So, when executing, you cannot choose between the versions of the recommendations. This means the recommendation version is coupled to the library version in a non-obvious way (different version numbers, requiring manual lookup). We should pin the SSLyze library version for the test together with the JSON of the recommendation. Footnotes |
As a customer I expect the communication channels to and between infrastructure components of an SCS cloud to be secured appropriately, so that in-transit data is protected.
As a CSP I want to establish secure communication channels adhering to the corresponding SCS standard the users can rely on.
Contents
Definition of Done:
Please refer to scs-0001-v1 for details.
scs-xxxx-v1-slug.md
(only substituteslug
)status
,type
,track
setDraft
, file renamed:xxxx
replaced by document numberDraft
)The text was updated successfully, but these errors were encountered: