AWS parallelcluster medium security documentation change
Summary
Added documentation recommending explicit specification of SecurityGroupIds alongside SubnetId for build instances, emphasizing security best practices and network control
Security assessment
The change explicitly advises users to define security groups to restrict network access and follow security best practices, directly addressing potential security weaknesses from overly permissive defaults.
Diff
diff --git a/parallelcluster/latest/ug/Build-v3.md b/parallelcluster/latest/ug/Build-v3.md index 1d044c7b5..466e0c9dd 100644 --- a//parallelcluster/latest/ug/Build-v3.md +++ b//parallelcluster/latest/ug/Build-v3.md @@ -56,0 +57,11 @@ Specifies the ID of an existing subnet in which to provision the instance to bui +When you specify the SubnetId, it is recommended to specify the SecurityGroupIds property as well. If you leave SecurityGroupIds out, AWS ParallelCluster will use default security groups or rely on the default behavior within the specified subnet. When you use both, you gain these advantages: + + * Granular control: When you explicitly define both you ensure the instances launched during the image build process are placed in the correct subnet and have the precise network access you need for your build components and any required services (like access to S3 for build scripts). + + * Security best practices: When you define appropriate security groups this helps restrict network access to only necessary ports and services, which enhances the security of your build environment. + + * Avoiding potential issues: If you rely solely on defaults this might result in security groups that are too open or too restrictive, which can lead to problems during the build process. + + + +