brianlloyd
commented
9 years ago Think we need a requirements session on this - there are several reasonable deployment modes and we should probably reflect those in the nucleator interface...
On Tue, Aug 25, 2015 at 2:48 PM, bweiner notifications@github.com wrote:
When running the redshift stackset to create a private cluster one would expect that the cluster would be in the db-subnet and that the security group assigned to the cluster would be restrict port 5439 access to within the vpc. However, the private cluster was put in the public subnet w/ the security group allowing port 5439 access from everywhere.
I do not believe that this issue is severe as access to the redshift cluster is not possible from outside the vpc due to other network settings. However, this issue with private redshift clusters should be address to achieve the fullest security protection.
— Reply to this email directly or view it on GitHub https://github.com/47lining/nucleator-core-redshift/issues/1.
47 Lining Brian Lloyd, SVP Engineering Cloud Advisory and Development Services M +1.540.845.2975 | E brian.lloyd@47lining.com | W www.47lining.com This message and any attachments are confidential and intended solely for the individual(s) or entity to which it is addressed. If you are not the intended recipient, do not read, copy or distribute the email or any attachments. Please notify the sender immediately by return e-mail.
semifocused
When running the redshift stackset to create a private cluster one would expect that the cluster would be in the db-subnet and that the security group assigned to the cluster would be restrict port 5439 access to within the vpc. However, the private cluster was put in the public subnet w/ the security group allowing port 5439 access from everywhere.
I do not believe that this issue is severe as access to the redshift cluster is not possible from outside the vpc due to other network settings. However, this issue with private redshift clusters should be address to achieve the fullest security protection.