eriqua
commented
1 year ago Adding a couple of thoughts:
- PSRule and WAF could also be considered as good sources
- We need to document our approach in a dedicated Wiki page, in the module design section, elaborating on implementations and design decisions for e.g. CMK and networking of resources supporting those features.
- We should document exceptions and deviations once agreed upon. Possible ones I might expect:
- settings requiring Azure features which are not enabled by default
- preview features
- settings which would possibly mine the usability/accessibility of our modules, like the one mentioned above (disabling public network access by default)
Note: related to #1703
rahalan
AlexanderSehr
Description
The modules we provide in CARML provide quite a lot of functionlity - including security features such as private endpoint support and 'secure' default values like TLS1.2. In the past we did a sweep of the modules of that time and applied as many rules as possible of the following 2 sources
However, ever since more module were added and it wasn't always clear what the 'secure-by-default' recommendation should be.
For example: Should we always set all values to the most secure value, even if that means that the module's deployment will require more effort by the user? An example could be to remove empty default values for private endpoints - essentially enforcing them - unless a user provides an explicit empty value as a parameter.
Looking at this from a more abstract level, this would mean: All modules can only be deployed with all security features enforced - and we need to describe how to (and the user have to make an effort to) deploy them in a less secure way.
Naturally this isn't a straight forward topic - especially as the user experience in this case may suffer.
Let's use this issue to keep the topic on the agenda and track the conversation.