`FileSystem` now have the `fileSystemArn` attribute available. It is also possible to import an existing `FileSystem` by `arn` or `id` using the `fromFileSystemAttributes` method.

You can also grant permission to an existing grantee using the grant method.

See the example below giving an IAM Role permission to write to an imported file system:

```ts
const arn = stack.formatArn({
  service: 'elasticfilesystem',
  resource: 'file-system',
  resourceName: 'fs-12912923',
});

const importedFileSystem = efs.FileSystem.fromFileSystemAttributes(this, 'existingFS', {
  fileSystemArn: arn, // You can also use fileSystemArn instead of fileSystemId.
  securityGroup: ec2.SecurityGroup.fromSecurityGroupId(this, 'SG', 'sg-123456789', {
    allowAllOutbound: false,
  }),
});

const role = new iam.Role(this, 'Access Role', { assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com') });

importedFileSystem.grant(role, 'elasticfilesystem:ClientWrite');
```


Closes #14998.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…ion type (#15526)

A recent update to the SAM spec (#15311)
changed the EndpointConfiguration property of AWS::Serverless::Api to have a complex type.
However, that is a breaking change compared to the previous, string, type.
I consulted with the SAM team, and it turns out the property accepts both a string and the complex type.
Given that, patch our SAM spec to make EndpointConfiguration a union type.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

… v2 (#15565)

In v1 we are allowing selection by the ID of the stack, with a warning that it will be stop working in v2 and asking the user to use the same names shown in the `cdk ls` result. Since the tests are written with the ID as input, they work when building for v1, but fail when building for v2. This change makes it work in both cases.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

KMS keys try to be smart about not generating impossible dependencies
between multiple stacks, which CodePipeline takes advantage of for
its support stacks.

However, because the logic that tests for this case has an `instanceof
Construct` in its code path, if there are ever multiple copies of the
`constructs` library in the NPM tree the test will fail, and the
resulting error will be very confusing.

This situation can arise when people flip back and forth between
CDK v1 and v2, because `package-lock.json` will contain half-baked
dependency trees; people will be looking at their code but the issue
will be in invisible state.

Be more liberal in detecting that a construct is, in fact, a construct
to get around this.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Fixes #15592


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

From the CONTRIBUTING guide.

- License notice was requested by our lawyers
- Docker instructions haven't worked in forever: our build uses
  Docker itself so needs privileged mode, and the `--privileged`
  flag does not available for `docker build`.

Closes #10438.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

The new recommended way of selecting stacks is by their construct path,
however when prompted the CLI is printing the deprecated identifiers.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…15441)

Add an option under `addApplication` for a given stage to create a CodeBuild that checks if there are any security changes within the stage's assembly. 

* If the changes exist: **manual approval is required**
* else: a lambda function will automatically approve the manual approval action

Adding a security check to an application creates two actions that precede the prepare
and deploy actions of an application:
1. A CodeBuild Project that runs a security diff on the stage
2. A Manual Approval Action that can be approved via a shared Lambda function.

```txt
Pipeline
├── Stage: Build
│   └── ...
├── Stage: Synth
│   └── ...
├── Stage: UpdatePipeline
│   └── ...
├── Stage: MyApplicationStage
│   └── Actions
│       ├── MyApplicationSecurityCheck       // Security Diff Action
│       ├── MyApplicationManualApproval      // Manual Approval Action
│       ├── Stack.Prepare
│       └── Stack.Deploy
└── ...
```

<details>
<summary>Example Usage</summary>
You can enable the security check in one of two ways:

1. Enable security check across the entire `CdkStage`

    ```ts
    const pipeline = new CdkPipeline(app, 'Pipeline', {
      // ...source and build information here (see above)
    });
    const stage = pipeline.addApplicationStage(new MyApplication(this, 'Testing'), {
      securityCheck: true,
    });
    // The 'PreProd' application is also run against a security diff because we configured
    // the stage to enable security checks
    stage.addApplication(new MyApplication(this, 'PreProd'));
    ```

2. Enable security check for a single application

    ```ts
    const pipeline = new CdkPipeline(app, 'Pipeline', {
      // ...source and build information here (see above)
    });
    const stage = pipeline.addApplicationStage(new MyApplication(this, 'NoCheck'));
    stage.addApplication(new MyApplication(this, 'RunSecurityDiff'), {
      securityCheck: true,
    });
    ```

</details>

Fixes: #12748

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

I added property to extract websocket callback endpoint url to WebSocketStage.
I added it simply like existing `url` property.

It's my first time to submit PR.
Please point out any mistakes.

closes #14836 

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…15604)

added the ability to specify an external id for the deploy-role as part of the synthesizer config.
this is similar to the existing functionality that allows specifying the external id for the image
and file publishing roles

In order to take advantage of this functionality you would need to customize the bootstrap template. To test this feature I customized the DeploymentActionRole in the bootstrap template to have the `AssumeRolePolicyDocument` as:

```yaml
DeploymentActionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Action: sts:AssumeRole
            Condition:
              StringEquals:
                sts:ExternalId: "my-external-id"
            Effect: Allow
            Principal:
              AWS:
                - Fn::Join:
                    - ""
                    - - "arn:"
                      - Ref: AWS::Partition
                      - :iam::1111111111111:root
        Version: "2012-10-17"
      ...
      RoleName:
        Fn::Sub: cdk-${Qualifier}-deploy-role-${AWS::AccountId}-${AWS::Region}
```

I then created a test stack that specified that external id:

```ts
new CdkExternalIdTestStack(app, 'CdkExternalIdTestStack', {
  env: {
    account: '111111111111',
    region: 'us-east-2',
  },
  synthesizer: new cdk.DefaultStackSynthesizer({
    deployRoleExternalId: 'my-external-id',
  }),
});
```
----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Fixes #15623 by updating timestamp for apikey integ test.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…15633)

A similar case to #15565 in which CLI tests assume stacks can be selected by ID and then fail when they land in v2-main. 

To detect this upstream (on `master`), I added an environment variable that explicitly disables the legacy behavior in cx-api and use it in the CLI tests to ensure that tests are executed without legacy behavior enabled.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Also migrate sns and lambda-event-sources to the new
'assertions' module.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

In `PrincipalWithConditions` the `conditions` parameter uses the getter syntax to return a new conditions object each time, which means the `addCondition` call will effectively throw away any conditions being added.

This PR ensures the conditions added with `addCondition` show up in the resulting principal.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Add a Troubleshooting section for the 'no matching base directory' error,
which is probably going to be common with the new API.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…control for legacy API (#15625)

this fixes #15169

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Allows users to add TagOptions to their portfolio.
----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

… template (#15283)

**[CORE CHANGES]**
Add optional `operation` parameter to `lamdaRequest` mapping template.
- Defaults to `"Invoke"`
- Allows for `"BatchInvoke"` operations directly through the static `lambdaRequest` function

**[MISC]**
* Add integration test w/ a verification script to test mapping template
* preliminary mapping template unit tests (created an issue to create more testing #15274 
* Use `path.resolve()` to resolve testing integration test in different directories

Fixes: #14079 

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Adds support for the `copyTagsToSnapshot` property.

Closes #15521

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Addresses #14857 by adding source map configuration options. Current implementation preferred preserving backwards compatibility with `sourceMap` boolean flag. See issue discussion for an alternative.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

We were still passing a stack name instead of a stage path,
causing the check to not work correctly.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Describe recommended way to do context lookups, and an alternative
approach we don't recommend but that everyone is asking for.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

We do validation-as-part-of-synth for legacy pipelines;
also need to do the same for modern pipelines otherwise
failing context lookups are too hard to diagnose.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…ig (#15469)

Adds the option to specify tlsConfig for `AWS::ApiGatewayV2::Integration` resources, to enable use of HTTPS when configuring private integrations.

closes #14036

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

…eline (#15669)

There was confusion on Slack on why the `ShellStep` of this
example did not appear in the pipeline. Make the example code more
complete.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Add stack event notification constraint.
Allows users to subscribe AWS `SNS` topics to stack updates on their products.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*


Co-authored-by: Dillon Ponzo <dponzo18@gmail.com>

fo -> of


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

This change corrects the episode link, both within a browser and with
the youtube-dl tool it shows as a non-existent video with the current
link.

youtube-dl output
```bash
youtube-dl https://www.twitch.tv/aws/video/977551207
[twitch:vod] 977551207: Downloading stream metadata GraphQL
ERROR: Video 977551207 does not exist
```


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Requested by AppSec to double-stress that access to the deploy
role (implied by `--trust`) is dangerous and should be explicitly
called out in the documentation.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*