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
The restrictServerAccessTo option to include a CIDR only allows for one IP block, e.g. 10.10.10.10/32. When setting up clusters to test Extensions (see opensearch-project/opensearch-sdk-java#652) there is a need for multiple CIDR blocks, e.g., one for the extension and one for a user to access.
What solution would you like?
Allow a user to specify multiple CIDRs. Format options include:
Comma-delimited: 10.10.10.10/32,10.10.10.20/32
Array-style [10.10.10.10/32, 10.10.10.20/32] or ['10.10.10.10/32', '10.10.10.20/32']
A --context which appends to the existing restriction, e.g. --context restrictServerAccessTo=10.10.10.10/32 --context restrictServerAccessAlsoTo=10.10.10.20/32
What alternatives have you considered?
A security group can be configured to allow multiple subnets. However, configuring these requires more detailed knowledge of filtering rules and is more prone to error than CIDR restrictions.
Do you have any additional context?
Other classic subnet combinations include hybrid on-prem+cloud IP ranges.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
The
restrictServerAccessTo
option to include a CIDR only allows for one IP block, e.g.10.10.10.10/32
. When setting up clusters to test Extensions (see opensearch-project/opensearch-sdk-java#652) there is a need for multiple CIDR blocks, e.g., one for the extension and one for a user to access.What solution would you like?
Allow a user to specify multiple CIDRs. Format options include:
10.10.10.10/32,10.10.10.20/32
[10.10.10.10/32, 10.10.10.20/32]
or['10.10.10.10/32', '10.10.10.20/32']
--context
which appends to the existing restriction, e.g.--context restrictServerAccessTo=10.10.10.10/32 --context restrictServerAccessAlsoTo=10.10.10.20/32
What alternatives have you considered?
A security group can be configured to allow multiple subnets. However, configuring these requires more detailed knowledge of filtering rules and is more prone to error than CIDR restrictions.
Do you have any additional context?
Other classic subnet combinations include hybrid on-prem+cloud IP ranges.
The text was updated successfully, but these errors were encountered: