You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 15, 2021. It is now read-only.
log-in as customer and subscribe to AWS EC2 service that has an underlying technical service that
can specify a security group (but specifies no subnet).
during subscription process specify a security group SG1, that is not the default security group,
and exist in the default region/subnet.
check provisioned instance's security group
[Expected result]
security group SG1
[Observed result]
instance has default security group
[Details]
If I set security group and subnet this works ok (workaround).
If I set security group SG1, and I do not set the subnet, I end up with an instance created in subnet as in 1. above, with default security group (not SG1)
If I try to manually create an Instance using AWS EC2 UI, and do not specify a subnet, but specify a security group, then the instance is created with the correct security group.
=> The workaround is to specify both. If this cannot be fixed, then it should be documented that the security group will only work if subnet is also specified.
@gertipoppel this might become a documentation issue.
The text was updated successfully, but these errors were encountered:
The AWS Controller ignores the specified security groups in case no subnet parameter specified. In that case, the instance will be created in some default subnet and default security group will be assigned.
The subnet parameter is used to get the VPC Identifier in order to identify the security groups for that VPC and check if the specified one exists. If the subnet parameter is not specified, checking security groups logic should be changed (e.g. get somehow the VPC Id or get the VPC security groups with some filtering).
@gertipoppel, please document that for specifying security groups, the subnet parameter is mandatory. Otherwise the groups will be ignored.
I will not close this issue, but set it for later if requested.
gertipoppel
added a commit
to servicecatalog/documentation
that referenced
this issue
Sep 5, 2017
Added a section to the Restrictions in the Release Notes for 17.4 and added corresponding comments to the SUBNET and SECURITY_GROUP_NAMES parameters in the Appendix "Service Parameters and Operations" of the AWS service controller manual.
Modified sources:
DocSources/en/AWSIntegrationGuide/Appendix/r_ServiceParameters.xml (documentation repository on GitHub)
DocSources/en/ReleaseNotes/Restrictions/c_Restrictions.xml (document repository on GitLab)
gertipoppel
added a commit
to servicecatalog/documentation
that referenced
this issue
Sep 5, 2017
[Build] 17.3 2017/07/27
[Steps to reproduce]
can specify a security group (but specifies no subnet).
and exist in the default region/subnet.
[Expected result]
security group SG1
[Observed result]
instance has default security group
[Details]
=> The workaround is to specify both. If this cannot be fixed, then it should be documented that the security group will only work if subnet is also specified.
@gertipoppel this might become a documentation issue.
The text was updated successfully, but these errors were encountered: