AWS network-manager documentation change
Summary
Introduced 'attachment-routing-policy-rules' section with routing policy label-based associations
Security assessment
Separates routing policy controls from tag-based segmentation for better security governance but doesn't resolve a specific security issue
Diff
diff --git a/network-manager/latest/cloudwan/cloudwan-policies-json.md b/network-manager/latest/cloudwan/cloudwan-policies-json.md index 1507ed7d7..12562d461 100644 --- a//network-manager/latest/cloudwan/cloudwan-policies-json.md +++ b//network-manager/latest/cloudwan/cloudwan-policies-json.md @@ -5 +5 @@ -core-network-configurationsegmentsnetwork-function-groupssegment-actionsattachment-policies +versioncore-network-configurationsegmentsnetwork-function-groupssegment-actionsattachment-policiesattachment-routing-policy-rulesrouting-policies @@ -14,0 +15,2 @@ For example JSON policies, see [AWS Cloud WAN core network policy examples](./cl + * version + @@ -24,0 +27,14 @@ For example JSON policies, see [AWS Cloud WAN core network policy examples](./cl + * attachment-routing-policy-rules + + * routing-policies + + + + +## `version` + +You must select a version for your core network from the following options: + + * `2021.12` + + * `2025.11` @@ -27,0 +44,5 @@ For example JSON policies, see [AWS Cloud WAN core network policy examples](./cl + +###### Note + +You must select version 2025.11 to use route policies in your core network policy. Using version 2025.11 will also enable BGP community support on your core network, meaning community tags coming from BGP capable attachments will begin to be propagated through your core network. We will drop the subtype information of community tags propagated through the core network and for community tags propagated outbound of the core network the subtype will be set to Route Target. + @@ -159 +180 @@ You can use either `allow-filter` or `deny-filter`, but you can't use both of th - * `share` attachments across segments. Use the `share` action so that attachments from two different segments can reach each other. For example, if you’ve set a segment to `isolate-attachments`, the segment can't reach anything unless it has a `share` relationship with other segments. The `share` statement creates routes between attachments in the provided segments. If you're creating a share between one segment and an array of segments, the segment to share allows attachments from the segments in the array. However, sharing does not occur between the segments within the array. For example, if a segment named `shared-service` is defined as a segment with a `share-with` array of segments named `prod` and `prod2`, the network policy will allow the attachments in both `prod` and `prod2` to reach `shared-service`. But the network policy will not allow sharing of attachments between `prod` and `prod2`. + * `share` attachments across segments. Use the `share` action so that attachments from two different segments can reach each other. For example, if you've set a segment to `isolate-attachments`, the segment can't reach anything unless it has a `share` relationship with other segments. The `share` statement creates routes between attachments in the provided segments. If you're creating a share between one segment and an array of segments, the segment to share allows attachments from the segments in the array. However, sharing does not occur between the segments within the array. For example, if a segment named `shared-service` is defined as a segment with a `share-with` array of segments named `prod` and `prod2`, the network policy will allow the attachments in both `prod` and `prod2` to reach `shared-service`. But the network policy will not allow sharing of attachments between `prod` and `prod2`. @@ -185,0 +207,2 @@ The following parameters are used in `segment-actions`: + * `associate-routing-policy` for associating routing policies with edge location pairs within a segment. + @@ -196 +219 @@ The following parameters are described for these actions. -For example, if you create a `share` between a segment named `shared-services` and share-with “A” and “B”, this allows the attachments from “A” and “B” to reach “Shared services”. “A” and “B” cannot reach each other, and any static routes or routes propagated from other segments are not shared among these segments. +For example, if you create a `share` between a segment named `shared-services` and share-with "A" and "B", this allows the attachments from "A" and "B" to reach "Shared services". "A" and "B" cannot reach each other, and any static routes or routes propagated from other segments are not shared among these segments. @@ -213,0 +237,2 @@ Use "`*`" as a wild card to reference all segments instead of explicitly calling + * `routing-policy-names` — (Optional) An array of routing policy names to apply to the segment sharing. The routing policies control how routes are propagated between the shared segments. + @@ -227,0 +253,24 @@ Use "`*`" as a wild card to reference all segments instead of explicitly calling + * `associate-routing-policy` parameters. If the action is `associate-routing-policy`, the following parameters are required: + + * `segment` — The name of the segment where the routing policy association will be applied. + + * `edge-location-association` — Defines the edge location pair and routing policies to associate: + + * `edge-location` — The primary edge location. + + * `peer-edge-location` — The peer edge location that forms the edge location pair. + + * `routing-policy-names` — An array of routing policy names to apply to traffic between these edge locations. + +The following example shows associating a routing policy with an edge location pair: + + { + "action": "associate-routing-policy", + "segment": "prod", + "edge-location-association": { + "edge-location": "us-east-1", + "peer-edge-location": "us-west-2", + "routing-policy-names": ["inboundRoutingFilter"] + } + } + @@ -290,5 +339,5 @@ The following example shows an example of the `send-to` action. In this example, - “action”: “send-to”, - “segment”: “development”, - “via”: { - “network-function-groups”: [ - “inspetion-vpc” + "action": "send-to", + "segment": "development", + "via": { + "network-function-groups": [ + "inspetion-vpc" @@ -317 +366 @@ In a core network, all attachments use the `attachment-policies` section to map -For example, to attach a VPC to a core network, either the VPC owner or the core network owner would create a core network attachment in the core network using either the AWS Cloud WAN console or the Network Manager `create-attachment` command line or API. The attachment itself will have tags analyzed by the attachment policy, and not the tags associated with the VPC resource. A tag on the attachment such as `“environment” : “development” ` would then map to a `development` segment. Attachment policy rules can also use available metadata from within the conditions, such as `account ID`, `type` of attachment, the `resource ID` (for example, `vpc-id`), or the AWS Region. +For example, to attach a VPC to a core network, either the VPC owner or the core network owner would create a core network attachment in the core network using either the AWS Cloud WAN console or the Network Manager `create-attachment` command line or API. The attachment itself will have tags analyzed by the attachment policy, and not the tags associated with the VPC resource. A tag on the attachment such as `"environment" : "development" ` would then map to a `development` segment. Attachment policy rules can also use available metadata from within the conditions, such as `account ID`, `type` of attachment, the `resource ID` (for example, `vpc-id`), or the AWS Region. @@ -321 +370 @@ Rules are assigned numbers for processing, and are processed in order by number, -When an attachment matches a rule, the attachment attaches to the segment defined `segment`. Each attachment can either be associated without acceptance or require a separate action to approve the attachment association. By default, every segment requires all attachments to be accepted. The acceptance requirement can be turned off with `“require-attachment-acceptance” : false` in the `segment` definition. When `require-acceptance` is `false`, any attachment that maps to the segment is automatically added. For example, a developer `sandbox` segment might want to allow any attachment with the correct tag to be added to the network. With the `attachment-policies`, you can add additional controls on a per-rule basis. For example, if attachments from the `us-east-2` Region require acceptance but other Regions do not, you can set the `“require-acceptance” : true` setting on a rule that is specific to `us-east-2` . +When an attachment matches a rule, the attachment attaches to the segment defined `segment`. Each attachment can either be associated without acceptance or require a separate action to approve the attachment association. By default, every segment requires all attachments to be accepted. The acceptance requirement can be turned off with `"require-attachment-acceptance" : false` in the `segment` definition. When `require-acceptance` is `false`, any attachment that maps to the segment is automatically added. For example, a developer `sandbox` segment might want to allow any attachment with the correct tag to be added to the network. With the `attachment-policies`, you can add additional controls on a per-rule basis. For example, if attachments from the `us-east-2` Region require acceptance but other Regions do not, you can set the `"require-acceptance" : true` setting on a rule that is specific to `us-east-2` . @@ -323 +372 @@ When an attachment matches a rule, the attachment attaches to the segment define -You can apply multiple conditions using either `and` or `or` logic to create a single rule. For example, you can state that if the account is `111122223333` and includes the tag `“stage” : “development”` it should map to a specified segment. If you don't want to use tags to map attachments, you could use the `resource-id` to manually map each incoming connection to a segment. However, this approach requires changing the policy document every time new attachments are added and can reduce the operability of your current LIVE policy. +You can apply multiple conditions using either `and` or `or` logic to create a single rule. For example, you can state that if the account is `111122223333` and includes the tag `"stage" : "development"` it should map to a specified segment. If you don't want to use tags to map attachments, you could use the `resource-id` to manually map each incoming connection to a segment. However, this approach requires changing the policy document every time new attachments are added and can reduce the operability of your current LIVE policy. @@ -337,5 +386 @@ The following parameters are used in `attachment-policies`: - * `condition-logic` — Evaluates a condition on either `and` or `or`. This is a mandatory parameter only if you have more than one condition. The conditions themselves are unordered, so the `condition-logic` applies to all of the conditions for a rule, which also means nested conditions of `and` or `or` are not supported. Use `and` if you want to the rule to match on all of the conditions, or use `or` if you want the rule to match on one of the conditions. - -If you're creating a JSON policy for a network function group `and` and `or` are the only supported `condition-logic` options. - - * `conditions` — An array composed of one of the four following types: + * `condition-logic` — Evaluates a condition on either `and` or `or`. @@ -343 +388 @@ If you're creating a JSON policy for a network function group `and` and `or` are - 1. `type` where the `value` is `any` — This matches any request. For example, you could use any if you're only using one segment that everything should map to. Or, you could use this as a fallback segment if you want all attachments that don't match a rule to map to a known segment. +This is a mandatory parameter only if you have more than one condition. The conditions themselves are unordered, so the `condition-logic` applies to all of the conditions for a rule, which also means nested conditions of `and` or `or` are not supported. Use `and` if you want to the rule to match on all of the conditions, or use `or` if you want the rule to match on one of the conditions. @@ -345,5 +390 @@ If you're creating a JSON policy for a network function group `and` and `or` are - 2. `type` where - - * `value` = `resource-id` | `account-id` | `region` | `attachment-type` - - * `operator` = `equals` | `not-equals` | `contains` | `begins-with` +If you're creating a JSON policy for a network function group `and` and `or` are the only supported `condition-logic` options. @@ -351 +392 @@ If you're creating a JSON policy for a network function group `and` and `or` are -This type is the `value` compared against the `operator`. For example, you might use the `condition` `type` in the following way: + * `conditions` — An array composed of one of the following types: @@ -353 +394 @@ This type is the `value` compared against the `operator`. For example, you might - * where the `resource-id` uses the resource associated with the attachment (for example, `vpc-1234567890123456`) + * `type` \- Specifies the kind of condition to evaluate for matching attachments. The type determines what attribute of the attachment will be examined and how the matching logic is applied. @@ -355 +396 @@ This type is the `value` compared against the `operator`. For example, you might - * where the `account-id` uses the account ID of the requesting attachment (for example, `111122223333`) + * `any` — This matches any request. For example, you could use any if you're only using one segment that everything should map to. Or, you could use this as a fallback segment if you want all attachments that don't match a rule to map to a known segment. @@ -357 +398 @@ This type is the `value` compared against the `operator`. For example, you might - * where the `Region `uses the Region code for the requesting attachment (for example, `us-east-1`), and + * `resource-id` uses the resource associated with the attachment (for example, `vpc-1234567890123456`). Supports additional parameters: @@ -359 +400 @@ This type is the `value` compared against the `operator`. For example, you might - * where the `attachment-type` uses `vpc`, `site-to-site-vpn`, `connect`, or `transit-gateway-route-table` strings + * `operator` — The operation to perform. Must be one of `equals` | `not-equals` | `contains` | `begins-with`. @@ -361 +402 @@ This type is the `value` compared against the `operator`. For example, you might - 3. `type` where the `value` is `tag-exists` — A string that matches against any of the keys defined on the attachment. Use this type when the value of the tag is not important, or if there is only a key without a value. + * `value` — The resource ID value to match against. @@ -363 +404 @@ This type is the `value` compared against the `operator`. For example, you might -A network function group attachment policy requires that you use the `tag-exists` type and then either `tag-name `or `tag-value`. + * `region` — Matches based on the AWS region where the attachment is located. Supports additional parameters: @@ -365 +406 @@ A network function group attachment policy requires that you use the `tag-exists - 4. `type` where the `value` is `tag-value` — Evaluates the following key value parameters: + * `operator` — The operation to perform. Must be one of `equals` | `not-equals` | `contains` | `begins-with`. @@ -367 +408 @@ A network function group attachment policy requires that you use the `tag-exists - * `key` — A string that matches against any of the keys defined on the attachment. It must be an exact match of the key. + * `value` — The Region to match against (for example,` us-east-1`). @@ -369 +410 @@ A network function group attachment policy requires that you use the `tag-exists - * `operator` — The operation to perform against the key value. Must be one of `equals` | `not-equals` | `contains` | `begins-with`. + * `attachment-type` — Matches based on the type of attachment. Supports additional parameters: @@ -371 +412 @@ A network function group attachment policy requires that you use the `tag-exists -`operator` is not supported for tag-name in a network function group policy version. + * `operator` — The operation to perform. Must be one of `equals` | `not-equals` | `contains` | `begins-with`. @@ -373 +414 @@ A network function group attachment policy requires that you use the `tag-exists - * `value` — The value of the key to be evaluated for the operator. + * `value` — The attachment type to match against. Supported values are: `vpc`, `site-to-site-vpn`, `connect`, `transit-gateway-route-table`. @@ -375 +416 @@ A network function group attachment policy requires that you use the `tag-exists -In this example, + * `account` — Uses the account ID of the requesting attachment (for example, `111122223333`). Supports additional parameters: @@ -377 +418 @@ In this example, -`“type” : “tag-value”,` + * `operator` — The operation to perform. Must be one of `equals` | `not-equals` | `contains` | `begins-with`. @@ -379 +420 @@ In this example, -`“key” : “project”,` + * `value` — The account ID value to match against. @@ -381 +422 @@ In this example, -`“operator” : “begins-with”,` + * `tag-name` — Match attachments based on the presence of specific tag names without evaluating their values. @@ -383 +424 @@ In this example, -`“value” : “sta”` + * `tag-value` — Match attachments based on the presence of specific tag values. Supports additional parameters: @@ -385 +426 @@ In this example, -Any condition where the value of `project` begins with `sta` is matched against the condition. This would return `staging`, `stage`, etc. + * `operator` — The operation to perform. Must be one of `equals` | `not-equals` | `contains` | `begins-with`. @@ -387 +428 @@ Any condition where the value of `project` begins with `sta` is matched against - * `description` — A user-defined description to help further identify the attachment policy. + * `value` — The tag key value to match against. @@ -389 +430 @@ Any condition where the value of `project` begins with `sta` is matched against - * `action` — The action to take when a condition is true. + * `action` — One of the following actions to when a condition is true: @@ -395 +436 @@ Any condition where the value of `project` begins with `sta` is matched against - * `tag-value-of-key` — Maps the attachment to the value of a known key. This is used with the `association-method ` is `tag`. For example a tag of `“stage” : “test”,` will map to a segment named `test`. The value must exactly match the name of a segment. This allows you to have many segments, but use only a single rule without having to define multiple nearly identical conditions. This prevents creating many similar conditions that all use the same keys to map to segments. + * `tag-value-of-key` — Maps the attachment to the value of a known key. This is used with the `association-method ` is `tag`. For example a tag of `"stage" : "test",` will map to a segment named `test`. The value must exactly match the name of a segment. This allows you to have many segments, but use only a single rule without having to define multiple nearly identical conditions. This prevents creating many similar conditions that all use the same keys to map to segments. @@ -397 +438 @@ Any condition where the value of `project` begins with `sta` is matched against - * `require-acceptance` — Determines if this mapping should override the segment value for `require-attachment-acceptance`. You can only set this to `true`, indicating that this setting applies only to segments that have `require-attachment-acceptance` set to `false`. If the segment already has the default `require-attachment-acceptance`, you can set this to inherit segment’s acceptance value. + * `require-acceptance` — Determines if this mapping should override the segment value for `require-attachment-acceptance`. You can only set this to `true`, indicating that this setting applies only to segments that have `require-attachment-acceptance` set to `false`. If the segment already has the default `require-attachment-acceptance`, you can set this to inherit segment's acceptance value. @@ -401 +442,3 @@ Any condition where the value of `project` begins with `sta` is matched against -The following shows an example policy adding a network function group named `SendToInspectionVPC`. The rule-number for the service insertion policy `125`. It uses the and condition-logic with a `tag` type of `tag-exists` type and a `key` value of `Location`. +A network function group attachment policy requires that you use the `condition` option `tag-exists`, and then either `tag-name` or `tag-value`. + +This following example attachment policy routes any attachment that has a `Location` tag to the `SendToInspectionVPC` network function group for traffic inspection, requiring manual acceptance before the attachment is processed: @@ -402,0 +446 @@ The following shows an example policy adding a network function group named `Sen + { @@ -406 +450 @@ The following shows an example policy adding a network function group named `Sen - "description": "Sends to Inspection VPC", + "description": "Send traffic to inspection VPC", @@ -415,0 +460,2 @@ The following shows an example policy adding a network function group named `Sen + "require-acceptance": true + } @@ -416,0 +463,51 @@ The following shows an example policy adding a network function group named `Sen + + + + +## `attachment-routing-policy-rules` + +`attachment-routing-policy-rules` defines how routing policies are associated with attachments using routing policy labels. This section works similarly to attachment policies but uses a new form of metadata called routing-policy-label instead of tags to map attachments to routing policies. + +This approach provides separation between segment association (via tags) and routing policy association (via labels), and ensures only the core network owner can manage routing policy associations. + +Before you can create an attachment routing policy rule, you must have routing policies already defined in the `routing-policies` section, as the rules reference these policies by the routing policy names. + +`attachment-routing-policy-rules` is an optional section. + +### Parameters