Improve operational processes for AWS Elemental MediaConnect using AWS CDK

Managing encrypted Amazon Web Services (AWS) Elemental MediaConnect entitlements across AWS accounts can be challenging, particularly when dealing with secret strings and upstream changes. We will demonstrate, with code examples, how AWS Cloud Development Kit (AWS CDK) can be leveraged to create a pattern for securing the sharing of secret strings. It will also provide automated responses to upstream modifications, even when you lack direct control over the granting account.

AWS Elemental MediaConnect (MediaConnect) is a service that makes it straightforward for broadcasters and other premium video providers to reliably ingest live video into the AWS Cloud. It also streamlines distribution to multiple destinations inside or outside of the cloud. MediaConnect provides reliability, security, and visibility combined with the flexibility and cost-effectiveness provided by internet-based transmission.

Entitlements in MediaConnect is a feature that facilitates granting access to your flow from another AWS account. Once entitled a subscriber can create a MediaConnect flow based on the entitlement from the granting account. The subscribing account can then go on to use this flow in their use case. For example, a traditional over-the-top (OTT) video workflow using AWS Elemental MediaLive, AWS Elemental MediaPackage, AWS Elemental MediaTailor or Amazon CloudFront.

Configuring your encryption settings

To confirm the granters content is kept secure, you have the ability to set encryption for each entitlement from a given flow. This can be done two different ways by using a secure packager and encoder key exchange (SPEKE) or a static key encryption. Using SPEKE, a conditional access (CA) system provides keys to MediaConnect for content encryption and decryption. Using a static key encryption allows you to generate and store your own encryption key. MediaConnect can be provided access to obtain the key from AWS Secrets Manager. For this demonstration we will focus on using a static key encryption.

Using a static key encryption means, as a granter of the MediaConnect Entitlement, you have full control of your key and can change it when you see fit. However, this brings some operational challenges, which must be managed properly:

1. If the key changes: You will need to verify the downstream account also acquires this update, otherwise it will fail to decrypt when changed.
2. Between two AWS accounts: You will need to setup infrastructure to support this workflow such as Secrets Manager secrets, AWS Key Management Service (AWS KMS) keys, MediaConnect flows and Amazon Identity and Access Management (IAM) roles.
3. Sharing the encrypted key can be insecure if you choose to email, Instant Message or text to send this key to a subscribing account’s team/owner.

The MediaConnect Automated Secret Sharing sample is a new proof of concept reference architecture to help provide an automated way of preventing the operational issue discussed previously and architectural challenge with AWS CDK. AWS CDK is an open-source software development framework to help you provision and model your cloud applications resources. Using AWS CDK, you can automatically provision the required architecture based on your operational needs without manual operations in the AWS Management Console.

This architecture does not provide a way of doing key rotation with MediaConnect static keys.

The following architecture provides a proof of concept for being able to automatically provision and share static encryption keys between different accounts. We focus predominantly on two personas: the granter and the consumer (the subscriber).

Figure 1: High-level architecture.

Architecture overview

The README file has step-by-step instructions on how you deploy the architecture into two accounts. At a high-level, you need to deploy three constructs to get this running in your test accounts (split between the granter and the consumer).

Firstly the “EmxEntitlementConsumerRole” construct in the consumer account to deploy an IAM Role to be used cross-account. Secondly, the “EmxEntitlementGrant” construct in the granting account to setup sending an encrypted entitlement to the consumer. Lastly the “EmxEntitlementConsumer” construct to consume the encrypted entitlement in the consumer account. As part of this AWS CDK application it will also provide a reference stream so you can visually test the architecture.

Key decisions in the design

For this architecture, there were a number of key design decisions that were chosen to help keep this architecture least-privilege and straightforward to operate:

• Uses resource-based policies instead of identity-based policies as resources shared across accounts.
• The project uses a CloudFormation custom resource to pull the secret. This can be configured to run every AWS CDK synthesize or deploy to confirm you always have the most up-to-date secret available.
• To verify that the principle of least privilege is followed each grant and consumer creation received a new secret and AWS KMS key. This means that two entitlements cannot share the same key.
• The secret created in Infrastructure as Code provides a way of generating the first key. However, it doesn’t update or change it once it is created. You would need to build a way of regenerating the key if desired (in a safe and controlled manner, for example, a separate service that is triggered intentionally after moving customers to a back-up stream to minimize impact).
• The initial consumer role needs to be deployed first, so the granter can use that role as the principal for its own IAM policies. This is important for security by enforcing the use of resource-based policies.
• For the operational side, the architecture needs to use AWS CloudTrail and Amazon EventBridge events to detect the change, Amazon Simple Notification Service (Amazon SNS) to notify and Amazon Simple Queue Service (Amazon SQS) to queue the events. This is to detect and trigger when a key has been changed or updated upstream. It utilizes the same AWS Lambda function used in the custom resource to trigger a fetch for the key.
  • You need to use CloudTrail with EventBridge for this feature as Secrets Manager events are triggered through CloudTrail.
  • As previously mentioned, this is not a way of doing key rotation.
  • This demonstration only focuses on static key encryption operational improvements.

AWS CDK facilitates the building of custom construct abstractions and publishes them to a library repository. This empowers you to create reusable patterns that enhance code reuse and maintainability across your projects. In this reference architecture we have these constructs as described in the “Architecture Overview” section.

Testing the architecture

Once you have a running stream and you can view the AWS Elemental MediaPackage stream output through Amazon CloudFront, you can start trying to disrupt the stream. You can start by altering the string in Secrets Manager in the granting account. Through this testing you will see the visible impact on the stream with black frames on the output for multiple seconds.

At the same time, you can also monitor the consumer account re-fetching the secret by looking at the entry in Secrets Manager. It can take a few seconds to notify and fetch the new secret string from the granting account.

An example indication that an underlying decryption key has changed is through Flow Alerts on the MediaConnect flow. While testing, when you change keys in the granting account, you will see a Flow Stream Error in the Alerts tab of the AWS Management Console—indicating a Transport Stream Sync Loss. You can also use this alert to build out further monitoring alerts when or if this occurs in your workflow. For example, you might want to alert your operations teams that something has changed which might impact a viewer’s quality of experience.

For more information on testing refer to the TEST.md in the GitHub repository.

Conclusion

AWS Cloud Development Kit is a great way to build your own custom abstractions of a given pattern. In our use case demonstration, we used AWS CDK to help with both the provisioning and operations for encrypted AWS Elemental MediaConnect entitlements.

This solution helps you prevent sharing secret strings in clear text, and also react automatically when things change upstream. It prepares you to have a fallback if you don’t have any control over the granting account.

Contact an AWS Representative to know how we can help accelerate your business.

Further reading

• Build and publish your AWS CDK constructs
• GitHub repository with more AWS reference architectures
• Troubleshooting SRT and Zixi with AWS Elemental MediaConnect
• AWS Streaming Media Lens for the AWS Well-Architected Framework
• AWS Elemental MediaConnect metrics to monitor source health