Седмицата (13–18 октомври)

Post Syndicated from Йовко Ламбрев original https://www.toest.bg/sedmitsata-13-18-oktomvri/

Седмицата (13–18 октомври)

Седмицата започна с изключително важно предупреждение, което не бива да подминаваме. „Бюджетът за 2026 г. е изправен пред сериозни трудности“, каза в интервю за БНТ управителят на БНБ Димитър Радев. Уточнявайки, че държавните разходи възлизат на около 40% от брутния вътрешен продукт, той добави:

Ако поддържаме устойчиво тези разходи значително над тази граница, това неизбежно поражда въпроса как ще се финансират. И отговорите не са толкова сложни – чрез дълг или чрез увеличение на данъците, или чрез комбинация от тези две възможности. А те не са добри възможности.

В същия момент Министерството на финансите се бави с проектобюджета, синдикатите шумят за данъчни реформи и увеличаване на осигуровките и данъците, а близки до правителството „говорещи глави“ им пригласят.

След безобразно щедрите увеличения на заплатите в МВР и в другите силови структури на държавата и обвързването на нивото на минималната работна заплата с 50% от средната на фона на скромната производителност на труда, уверено сме се засилили да влезем в еврозоната със свръхдефицит и ускоряваща се инфлация. А после сигурно еврото ще ни е виновно?

В същото това време големите Д-та ни разиграват сценки от самодейни вечеринки. Понеже талантът на Бойко Борисов като стендъп комедиант се поизтърка, напоследък той се упражнява в жанра старогръцка трагедия. В новия епизод на „Т.Е. от Е.Т.“ Елена Телбис за три минути разхвърля този и други „герои“ от седмицата в различните ъгли на тепиха. Докато мята щанги.

Емилия Милчева също взема за информационен повод гибелния гняв на Бойко Борисов. Според нея ние сме в преддверието на криза и е много вероятно следващите парламентарни избори да изпреварят президентските догодина. Не подминавайте седмичния ѝ политически коментар, озаглавен „Конграчулейшънс, Борисов 2.0“.

Емилия Милчева беше и вторият събеседник в поредицата ни „Тоест разговаряме“. Ако сте пропуснали излъчването на живо, може да изгледате или да изслушате записа на срещата, водена от Владислав Севов – линкове ще намерите в статията за епизода, в която е включен още един отговор от Емилия на зрителски въпрос: „Злодей ли е Пеевски?“

Министърът на образованието Красимир Вълчев не изглежда да е злодей, но ми е личен „любимец“. Така далеч е от моите позиции за миналото, настоящето и бъдещето, че дори неволно не можем да нацелим тема, по която да се доближим на по-малко от 200 светлинни години отстояние. Но понеже социалните мрежи според мен вече са фундаментално вредни, за малко да се подхлъзна по идеята му да ги ограничава за подрастващите. След като прочетох обаче статията на Светла Енчева „Не дай боже училището да стане интересно“, благосклонността ми към МОН и министъра отново се разсея.

Джорджа Спадони започва в „Тоест“ публицистична поредица за събитията в съседна Сърбия, които бяха възпламенени от злощастния инцидент на гарата в Нови Сад преди година. На 1 ноември 2024 г. почти 50-метровата бетонна козирка на новоремонтираната гара рухва върху главите на няколко десетки души, 16 от които умират. Трагедията се превръща в сръбския символ на корупцията, която убива. Последвалите студентски протести, които не стихват вече цяла година, разклатиха управлението на Сръбската прогресивна партия и Александър Вучич както нищо друго досега.

Културните войни са темата на новия текст на Йоанна Елми. Почти няма колебания, че те са симптом за социална криза и пренареждане на обществени и икономически слоеве, но колко разрушителни могат да са последиците? И ако несъгласията (от съвсем недалечното минало) бяха белег за жизнена и здрава демокрация, дали тя ще издържи екстремумите на днешните ни разминавания? Прочетете повече в брой 9 на „Гласовете на Америка“ и се абонирайте за този бюлетин, ако все още не сте.

В съвместната ни рубрика с „Екипът на София“ тази седмица Елена Гечева, която е политолог с фокус върху местните политики, показва какво прави един градски бюджет добър. И че водещото в него са не числата, а целите и идеите, заложени в плана за развитие на местната общност, които числата измерват и оценяват.

Автобиографичният роман „Живей бързо“ от Брижит Жиро е изборът на Антония Апостолова в рубриката ни „На второ четене“. В книгата, отличена с наградата „Гонкур“ за 2022 г., Жиро се опитва да разсъди има ли непредвидимост и непредотвратимост и изчислим ли е животът. Романът прераства в значим социален коментар, минава отвъд личното и засяга колективни измерения, смята Антония.

И накрая – ако миналата седмица Атанас Шиников напълно ви е ошашавил със сложния религиозен контекст на невидимите парични преводи хауала и сте очаквали във втората част (някак естествено или божествено) да се стигне до криптовалутите… уви, този път ще бъдем засилени още по-назад в дълбините на времето, чак до делниците на Пророка Мохамед.

Пожелавам ви приятно четене и гледане. А ако цените нашата журналистическа работа, подкрепете ни. „Тоест“ се издържа от месечните дарения на своите читатели.

Станете дарител

Configure seamless single sign-on with SQL analytics in Amazon SageMaker Unified Studio

Post Syndicated from Arun A K original https://aws.amazon.com/blogs/big-data/configure-seamless-single-sign-on-with-sql-analytics-in-amazon-sagemaker-unified-studio/

Amazon SageMaker Unified Studio provides a unified experience for using data, analytics, and AI capabilities. SageMaker Unified Studio now supports trusted identity propagation (TIP) for SQL workloads, enabling fine-grained data access control based on individual user identities. Organizations can use this integration to manage data permissions through AWS Lake Formation while using their existing single sign-on (SSO) infrastructure.

Organizations already using Amazon Redshift with TIP can extend their existing Lake Formation permissions to SageMaker Unified Studio. Users simply log in through SSO and access their authorized data using the SQL editor, maintaining consistent security controls across their analytics environment.

This post demonstrates how to configure SageMaker Unified Studio with SSO, set up projects and user onboarding, and access data securely using integrated analytics tools.

Solution overview

For our use case, a retail corporation is planning to implement sales analytics to identify sales patterns and product categories that are doing well. This will help the sales team improve on sales planning with targeted promotions and help the finance team plan budgeting with better inventory management. The corporation stores a customer table in an Amazon Simple Storage Service (Amazon S3) data lake and a store_sales table in a Redshift cluster.

The corporation uses SageMaker Unified Studio as the UI, with users onboarded from their identity provider (IdP) to AWS IAM Identity Center with TIP. Amazon SageMaker Lakehouse centralizes data from Amazon S3 and Amazon Redshift, and Lake Formation provides fine-grained access control based on user identity. For our example use case, we explore two different users. The following table summarizes their roles, the tools they use, and their data access.

User Group Tool Data Access
Ethan (Data Analyst) Sales Amazon Athena for interactive SQL analysis Non-sensitive customer data (id, c_country, birth_year) and store_sales full table access
Frank (BI Analyst) Finance Amazon Redshift for reports and visualization US customer data (c_country='US')

The following diagram illustrates the solution architecture.

SageMaker Unified Studio with IAM Identity Center simplifies the user journey from authentication to data analysis. The workflow consists of the following steps:

  1. Users sign in with organizational SSO credentials through their IdP and are redirected to SageMaker Unified Studio.
  2. Users configure IAM Identity Center authentication for Amazon Redshift, linking identity management with data access.
  3. Users access the query editor for Amazon Redshift or SageMaker Lakehouse, triggering IAM Identity Center federation to generate session and access tokens.
  4. SageMaker Unified Studio retrieves user authorization details and group membership using the session token.
  5. Users are authenticated as IAM Identity Center users, ready to explore and analyze data using Amazon Redshift and Amazon Athena.

To implement our solution, we walk through the following high-level steps:

  1. Set up SageMaker Lakehouse resources.
  2. Create a SageMaker Unified Studio domain with SSO and TIP enabled.
  3. Configure Amazon Redshift for TIP and validate access.
  4. Validate data access using Amazon Athena.

Prerequisites

Before you begin implementing the solution, you must have the following in place:

  1. If you don’t have an AWS account, you can sign up for one.
  2. We provide utility scripts to help set up various sections of the post. To use them:
    1. Right-click this link and save the utility scripts zip file.
    2. Unzip the file to a terminal that has the AWS Command Line Interface (AWS CLI) configured. You can also use AWS CloudShell.
    3. Run the scripts only when prompted in the relevant sections.
    Note: The utility scripts are configured for
    us-east-1 region. If you prefer another region, edit the region in the scripts before running them.
  3. To deploy the infrastructure, right-click this link and select ‘Save Link As’ to save it as sagemaker-unified-studio-infrastructure.yaml. Then upload the file when creating a new stack in the AWS CloudFormation console, which will create the following resources:
    1. An S3 bucket to hold the customer data used in this post.
    2. An AWS Identity and Access Management (IAM) role called DataTransferRole with permissions as defined in Prerequisites for managing Amazon Redshift namespaces in the AWS Glue Data Catalog.
    3. An IAM role called IAMIDCRedshiftRole, which will be used later to set up the IAM Identity Center Redshift application.
    4. An IAM role called LakeFormationRegistrationRole, following the instructions in Requirements for roles used to register locations, and necessary IAM policies.
  4. If you don’t have a Lake Formation user, you can create one. For this post, we use an admin user. For instructions, see Create a data lake administrator.
  5. If IAM Identity Center is not enabled, refer to Enabling AWS IAM Identity Center for instructions to enable it.
    1. If you need to migrate existing Redshift users and groups, use the IAM Identity Center Redshift migration utility.
    2. For a quick way to test the feature and familiarize yourself with the process, we provide a script to generate mock users and groups. Run the setup-idc.sh script, which is provided in Step 2, to create test users and groups in IAM Identity Center for demonstration purposes.
  6. Integrate IAM Identity Center with Lake Formation. For instructions, see Connecting Lake Formation with IAM Identity Center.
  7. Register the S3 bucket as a data lake location:
    1. On the Lake Formation console, choose Data lake locations in the navigation pane.
    2. Choose Register location.
    3. For the role, use LakeFormationRegistrationRole.
  8. Create an IAM Identity Center Redshift application, as detailed in our previous post:
    1. On the Amazon Redshift console, choose IAM Identity Center connections in the navigation pane and choose Create application.
    2. For both the display name and application name, enter redshift-idc-app.
    3. Set the IdP namespace to awsidc.
    4. Choose IAMIDCRedshiftRole as the IAM role.
    5. Choose Next to create the application.
    6. Take note of the application Amazon Resource Name (ARN) to use in subsequent steps. The ARN format is arn:aws:sso::<ACCOUNT_NUMBER>:application/ssoins-<RANDOM_STRING>/apl-<RANDOM_STRING>.
  9. If you don’t have existing Redshift tables to work with, run the script setup-producer-redshift.sh, which is provided in Step 2, to create a producer namespace and workgroup, set up a sample sales database, and generate necessary tables with test data.
  10. The post also uses simulated customer data stored in the AWS Glue Data Catalog. To set up this data and configure the necessary Lake Formation permissions, run the setup-glue-tables-and-access.sh script provided in Step 2.

Set up SageMaker Lakehouse resources

In this section, we configure the foundational lakehouse resources required for SageMaker to access and analyze data across multiple storage systems. We’ll register the Redshift instance to the AWS Glue Data Catalog to make warehouse data discoverable and establish Lake Formation permissions on lakehouse resources for user identities to ensure secure, governed access to both data lake and data warehouse resources from within SageMaker environments.

Register Redshift instance to the Data Catalog

In this step, we use the store_sales data, which we created earlier using the setup-producer-redshift.sh script. You can register entire clusters to the Data Catalog and create catalogs managed by AWS Glue. To register a cluster to the Data Catalog, complete the following steps:

  1. On the Lake Formation console, choose Administrative roles and tasks in the navigation pane.
  2. Under Data lake administrators, choose Add.
  3. Choose Read-only administrator, then choose AWSServiceRoleForRedshift.
  4. On the Amazon Redshift console, open your namespace.
  5. On the Actions dropdown menu, chose Register with AWS Glue Data Catalog, then choose Register.
  6. Sign in to the Lake Formation console as the data lake administrator and choose Catalogs in the navigation pane.
  7. Under Pending catalog invitations, select the namespace and accept the invitation by choosing Approve and create catalog.
  8. Provide the name for the catalog as salescatalog.
  9. Select Access this catalog from Apache Iceberg compatible engines, choose DataTransferRole for the IAM role, then choose Next.
  10. Choose Add permissions and choose the admin IAM role under IAM users and roles.
  11. Select Super user for catalog permissions and choose Add.
  12. Choose Next.
  13. Choose Create catalog.

Set up Lake Formation permission on lakehouse resources for user identities

In this section, we configure Lake Formation permissions to enable secure access to lakehouse resources for federated user identities. Lake Formation provides fine-grained access control that works seamlessly with IAM Identity Center, allowing you to manage permissions centrally while maintaining security boundaries.

We’ll focus on granting database access to IAM Identity Center groups in Lake Formation and setting table-level permissions for federated Redshift catalog tables. These permissions form the security foundation for our federated query architecture, enabling users to seamlessly access both S3 data lake and Redshift data warehouse resources through a unified interface.

Grant database access to IAM Identity Center groups in Lake Formation

After you share your Redshift catalog with the Data Catalog and integrate with Lake Formation, you must grant appropriate database access. Follow these steps to set up permissions on your data lake resources for corporate identities:

  1. On the Lake Formation console, under Permissions in the navigation pane, choose Data permissions.
  2. Choose Grant.
  3. Select Principals for Principal type.
  4. Under Principals, select IAM Identity Center and choose Add.
  5. In the pop-up window, if this is your first time assigning users and groups, choose Get started.
  6. Search for and select the IAM Identity Center groups awssso-sales and awssso-finance.
  7. Choose Assign.
  8. Under LF-Tags or catalog resources, choose Named Data Catalog resources.
    1. Choose <accountid>:salescatalog/dev for Catalogs.
    2. Choose sales_schema for Database.
  9. Under Database permissions, select Describe.
  10. Choose Grant to apply the permissions.

Grant table-level permissions for federated Redshift catalog tables

Complete the following steps to grant table permissions to the IAM Identity Center groups:

  1. On the Lake Formation console, under Permissions in the navigation pane, choose Data permissions.
  2. Choose Grant.
  3. Select Principals for Principal type.
  4. Under Principals, select IAM Identity Center and choose Add.
  5. In the pop-up window, if this is your first time assigning users and groups, choose Get started.
  6. Search for and select the IAM Identity Center group awssso-sales.
  7. Choose Assign.
  8. Under LF-Tags or catalog resources, choose Named Data Catalog resources.
    1. Choose <accountid>:salescatalog/dev for Catalogs.
    2. Choose sales_schema for Database.
    3. Choose store_sales for Table.
  9. Select Select and Describe for Table permissions.
  10. Choose Grant to apply the permissions.

Create a SageMaker Unified Studio domain with SSO and TIP enabled

For instructions to create a SageMaker Unified Studio domain, refer to Create an Amazon SageMaker Unified Studio domain – quick setup. Because your IAM Identity Center integration is already complete, you can specify an IAM Identity Center user in the domain configuration settings.

Enable TIP in SageMaker Unified Studio

Complete the following steps to enable TIP in SageMaker Unified Studio:

  1. On the SageMaker console, use the AWS Region selector in the top navigation bar to choose the appropriate Region.
  2. Choose View domains and choose the domain’s name from the list.
  3. On the domain’s details page, on the Project profiles tab, choose a project profile, for example, SQL analytics.
  4. Select SQL analytics and choose Edit.
  5. In the Blueprint parameters section, select enableTrustedIdentityPropagationPermissions and choose Edit.
  6. Update the value as true.
  7. To enforce authorization-based on TIP, the SageMaker Unified Studio admin can make this parameter non-editable.
  8. Choose Save.

Enable user access for SageMaker Unified Studio domain

Complete the following steps to enable user access for the SageMaker Unified Studio domain:

  1. Open the SageMaker console in the appropriate Region and choose Domains in the navigation pane.
  2. Choose an existing SageMaker Unified Studio domain where you want to add SSO user access.
  3. On the domain’s details page, on the User management tab, in the Users section, choose Add and Add SSO users and groups.
  4. Choose the user (for this post, we add the user Frank) from the dropdown list and choose Add users and groups.

Add project members

SageMaker Unified Studio projects facilitate team collaboration for different business initiatives. As the project owner, Ethan now can add Frank as a team member to enable their collaboration. To add members to an existing project, complete the following steps:

  1. Sign in to the SageMaker Unified Studio console using the SSO credentials of who owns the project (for this post, Ethan).
  2. Choose Select a project.
  3. Choose the project you want to edit.
  4. On the Project overview page, expand Actions and choose Manage members.
  5. Choose Add members.
  6. Enter the name of the user or group you want to add (for this post, we add Frank).
  7. Select Contributor if you want to add the project member as a contributor.
  8. (Optional) Repeat these steps to add more project members. You can add up to eight project members at a time.
  9. Choose Add members.

Create a SQL analytics project in Unified Studio

In this step, we federate into SageMaker Unified Studio and create a project using SQL analytics. Complete the following steps:

  1. Federate into SageMaker Unified Studio using your IAM Identity Center credentials:
    1. On the SageMaker console, choose Domains in the navigation pane.
    2. Copy the SageMaker Unified Studio URL for your domain and enter it into a new browser window.
    3. Choose Sign in with SSO.
    4. A browser pop-up will redirect you to your preferred IdP login page, where you enter your IdP credentials.
    5. If authentication if successful, you will be redirected to SageMaker Unified Studio.
  2. After logging in, choose Create project.
  3. Enter a name for your project. This project name is final and can’t be changed later.
  4. (Optional) Enter a description for your project. You can edit this later.
  5. Choose a project profile. For this demo, we choose the SQL analytics profile from the available templates.
  6. Leave the default values as they are or modify them according to your use case, then choose Continue.
  7. Choose Create project to finalize the project and initialize your SQL analytics workspace.

For more detailed information and advanced configurations, refer to Create a project.

Configure Amazon Redshift for TIP and validate access

Run the setup-consumer-redshift.sh script (provided in the prerequisites). This script will create a new namespace and workgroup and add the required tags, which you will use later to integrate with SageMaker Unified Studio compute.

If you are creating the cluster manually, add one of the following tags to the Redshift cluster or workgroup that you want to add to SageMaker Unified Studio:

  • Option 1 – Add a tag to allow only a specific SageMaker Unified Studio project to access it: AmazonDataZoneProject=<projectID>
  • Option 2 – Add a tag to allow all SageMaker Unified Studio projects in this account to access it: for-use-with-all-datazone-projects=true

Create compute using IAM Identity Center authentication

After you set up your project, the next step is to establish a compute resource connection on the SageMaker Unified Studio console. Follow these steps to add either Amazon Redshift Serverless or a provisioned cluster to your project environment:

  1. Go to the Compute section of your project in SageMaker Unified Studio.
  2. On the Data warehouse tab, choose Add compute.
  3. You can create a new compute resource or choose an existing one. For this post, we choose Connect to existing compute resources, then choose Next.
  4. Choose the type of compute resource you want to add, then choose Next. For this post, we choose Redshift Serverless.
  5. Under Connection properties, provide the JDBC URL or the compute you want to add, which is integrated with IAM Identity Center. If the compute resource is in the same account as your SageMaker Unified Studio project, you can select the compute resource from the dropdown menu. In our example, we use the consumer account that was just provisioned.
  6. Under Authentication, select IAM Identity Center.
  7. For Name, enter the name of the Redshift Serverless or provisioned cluster you want to add.
  8. For Description, enter a description of the compute resource.
  9. Choose Add compute.

The SageMaker Unified Studio Project Compute and Data pages will now display information for that resource.

If everything is configured correctly, your compute will be created using IAM Identity Center. Because your IdP credentials are already cached while you’re logged in to SageMaker Unified Studio, it uses the same credentials and creates the compute.

Test data access using Amazon Redshift

When Ethan logs in to SageMaker Unified Studio using IAM Identity Center authentication, he successfully federates and can access customer data from all countries but only for non-sensitive columns. Let’s connect to Amazon Redshift in SageMaker Unified Studio by following these steps:

  1. Choose Actions and choose Open Query editor.
  2. Choose Redshift in the Data explorer pane.
  3. Run the customer sales calculation query to observe that user Ethan (a data analyst) can access customer data from all countries but only non-sensitive columns (id, birth_country, product_id): 
    select current_user, c.*, sum(s.sales_amount) as total_sales
from "awsdatacatalog"."customerdb"."customer" c
join "dev@salescatalog"."sales_schema"."store_sales" s 
on c.id=s.id
group by all;

You have successfully configured Redshift to use IAM Identity Center authentication in SageMaker Unified Studio.

Validate data access using Amazon Athena

When Frank logs in to SageMaker Unified Studio using IAM Identity Center authentication, he successfully federates and can access customer data only for the United States. To query with Athena, complete the following steps:

  1. Choose Actions and choose Open Query editor.
  2. Choose Lakehouse in the Data explorer pane.
  3. Explore AwsDataCatalog, expand the database, choose the respective table, and on the options menu (three dots), choose Preview data.

The following demonstration illustrates how user Frank, a BI analyst, can perform SQL analysis using Athena. Due to row-level filtering implemented through Lake Formation, Frank’s access is restricted to customer data from the United States only. Additionally, you can observe that in the Data explorer pane, Frank can only view the customerdb database. The dev@salescatalog database is not visible to Frank because no access has been granted to his respective group from Lake Formation.

The IAM Identity Center authentication integration is complete; you can use both Amazon Redshift and Athena through SageMaker Unified Studio in a simplified, all-in-one interface.Note that, at the time of writing, Athena doesn’t work with Redshift Managed Storage (RMS).

Clean up

Complete the following steps to clean up the resources you created as part of this post:

  1. Delete the data from the S3 bucket.
  2. Delete the Data Catalog objects.
  3. Delete the Lake Formation resources and Athena account.
  4. Delete the SageMaker Unified Studio project and associated domain.
  5. If you created new Redshift cluster for testing this solution, delete the cluster.

Conclusion

In this post, we provided a comprehensive guide to enabling trusted identity propagation within SageMaker Unified Studio. We covered the setup of a SageMaker Unified Studio domain with SSO, the creation of tailored projects, efficient user onboarding with appropriate permissions, and the management of AWS Glue and Amazon Redshift managed catalog permissions using Lake Formation. Through practical examples, we demonstrated how to use both Amazon Redshift and Athena within SageMaker Unified Studio, showcasing secure data access and analysis capabilities. This approach helps organizations maintain strict identity controls while helping data scientists and analysts derive valuable insights from both data lake and data warehouse environments, supporting both security and productivity in machine learning workflows.

For more information on this integration, refer to Trusted identity propagation.

About the authors

Maneesh Sharma

Maneesh Sharma

Maneesh is a Sr. Architect at AWS with 15 years of experience designing and implementing large-scale data warehouse and analytics solutions. He works closely with customers to help them modernize their legacy applications to AWS cloud-based platforms.

Srividya Parthasarathy

Srividya Parthasarathy

Srividya is a Senior Big Data Architect with Amazon SageMaker Lakehouse. She works with the product team and customers to build robust features and solutions for their analytical data platform. She enjoys building data mesh solutions and sharing them with the community.

Arun A K

Arun A K

Arun is a Senior Big Data Specialist Solutions Architect at Amazon Web Services. He helps customers design and scale data platforms that power innovation through analytics and AI. Arun is passionate about exploring how data and emerging technologies can solve real-world problems. Outside of work, he enjoys sharing knowledge with the tech community and spending time with his family.

How and Why Netflix Built a Real-Time Distributed Graph: Part 1 — Ingesting and Processing Data…

Post Syndicated from Netflix Technology Blog original https://netflixtechblog.com/how-and-why-netflix-built-a-real-time-distributed-graph-part-1-ingesting-and-processing-data-80113e124acc

How and Why Netflix Built a Real-Time Distributed Graph: Part 1 — Ingesting and Processing Data Streams at Internet Scale

Authors: Adrian Taruc and James Dalton

This is the first entry of a multi-part blog series describing how we built a Real-Time Distributed Graph (RDG). In Part 1, we will discuss the motivation for creating the RDG and the architecture of the data processing pipeline that populates it.

Introduction

The Netflix product experience historically consisted of a single core offering: streaming video on demand. Our members logged into the app, browsed, and watched titles such as Stranger Things, Squid Game, and Bridgerton. Although this is still the core of our product, our business has changed significantly over the last few years. For example, we introduced ad-supported plans, live programming events (e.g., Jake Paul vs. Mike Tyson and NFL Christmas Day Games), and mobile games as part of a Netflix subscription. This evolution of our business has created a new class of problems where we have to analyze member interactions with the app across different business verticals. Let’s walk through a simple example scenario:

  1. Imagine a Netflix member logging into the app on their smartphone and beginning to watch an episode of Stranger Things.
  2. Eventually, they decide to watch on a bigger screen, so they log into the app on a smart TV in their home and continue watching the same episode.
  3. Finally, after completing the episode, they log into the app on their tablet and play the game “Stranger Things: 1984”.

We want to know that these three activities belong to the same member, despite occurring at different times and across various devices. In a traditional data warehouse, these events would land in at least two different tables and may be processed at different cadences. But in a graph system, they become connected almost instantly. Ultimately, analyzing member interactions in the app across domains empowers Netflix to create more personalized and engaging experiences.

In the early days of our business expansion, discovering these relationships and contextual insights was extremely difficult. Netflix is famous for adopting a microservices architecture — hundreds of microservices developed and maintained by hundreds of individual teams. Some notable benefits of microservices are:

  1. Service Decomposition: The overall platform is separated into smaller services, each responsible for a specific business capability. This modularity allows for independent service development, deployment, and scaling.
  2. Data Isolation: Each service manages its own data, reducing interdependencies. This allows teams to choose the most suitable data schemas and storage technologies for their services.

However, these benefits also led to drawbacks for our data science and engineering partners. In practice, the separation of business concerns and service development ultimately resulted in a separation of data. Manually stitching data together from our data warehouse and siloed databases was an onerous task for our partners. Our data engineering team recognized we needed a solution to process and store our enormous swath of interconnected data while enabling fast querying to discover insights. Although we could have structured the data in various ways, we ultimately settled on a graph representation. We believe a graph offers key advantages, specifically:

  • Relationship-Centric Queries: Graphs enable fast “hops” across multiple nodes and edges without expensive joins or manual denormalization that would be required in table-based data models.
  • Flexibility as Relationships Grow: As new connections and entities emerge, graphs can quickly adapt without significant schema changes or re-architecture.
  • Pattern and Anomaly Detection: Our stakeholders’ use cases often require identifying hidden relationships, cycles, or groupings in the data — capabilities much more naturally expressed and efficiently executed using graph traversals than siloed point lookups.

This is why we set out to build a Real-Time Distributed Graph, or “RDG” for short.

Ingestion and Processing

Three main layers in the system power the RDG:

  1. Ingestion and Processing — receive events from disparate upstream data sources and use them to generate graph nodes and edges.
  2. Storage — write nodes and edges to persistent data stores.
  3. Serving — expose ways for internal clients to query graph nodes and edges.

The rest of this post will focus on the first layer, while subsequent posts in this blog series will cover the other layers. The diagram below depicts a high-level overview of the ingestion and processing pipeline:

Building and updating the RDG in real-time requires continuously processing vast volumes of incoming data. Batch processing systems and traditional data warehouses cannot offer the low latency needed to maintain an up-to-date graph that supports real-time applications. We opted for a stream processing architecture, enabling us to update the graph’s data as events happen, thus minimizing delay and ensuring the system reflects the latest member interactions within the Netflix app.

Kafka as the Ingestion Backbone

Member actions in the Netflix app are published to our API Gateway, which then writes them as records to Apache Kafka topics. Kafka is the mechanism through which internal data applications can consume these events. It provides durable, replayable streams that downstream processors, such as Apache Flink jobs, can consume in real-time.

Our team’s applications consume several different Kafka topics, each generating up to roughly 1 million messages per second. Topic records are encoded in the Apache Avro format, and Avro schemas are persisted in an internal centralized schema registry. In order to strike a balance between maintaining data availability and managing the financial expenses of storage infrastructure, we tailor retention policies for each topic according to its throughput and record size. We also persist topic records to Apache Iceberg data warehouse tables, which allows us to backfill data in scenarios where older data is no longer available in the Kafka topics.

Processing Data with Apache Flink

The event records in the Kafka streams are ingested by Flink jobs. We chose Flink because of its strong capabilities around near-real-time event processing. There is also robust internal platform support for Flink within Netflix, which allows jobs to integrate with Kafka and various storage backends seamlessly. At a high level, the anatomy of an RDG Flink job looks like this:

For the sake of simplicity, the diagram above depicts a basic flow in which a member logs into their Netflix account and begins watching an episode of Stranger Things. Reading the diagram from left to right:

  • The actions of logging into the app and watching the Stranger Things episode are ultimately written as events to Kafka topics.
  • The Flink job consumes event records from the upstream Kafka topics.
  • Next, we have a series of Flink processor functions that:
  1. Apply filtering and projections to remove noise based on the individual fields that are present — or in some cases, not present — in the events.
  2. Enrich events with additional metadata, which are stored and accessed by the processor functions via side inputs.
  3. Transform events into graph primitives — nodes representing entities (e.g., member accounts and show/movie titles), and edges representing relationships or interactions between them. In this example, the diagram only shows a few nodes and an edge to keep things simple. However, in reality, we create and update up to a few dozen different nodes and edges, depending on the member actions that occurred within the Netflix app.
  4. Buffer, detect, and deduplicate overlapping updates that occur to the same nodes and edges within a small, configurable time window. This step reduces the data throughput we publish downstream. It is implemented using stateful process functions and timers.
  5. Publish nodes and edges records to Data Mesh, an abstraction layer that connects data applications and storage systems. We write a total (nodes + edges) of more than 5 million records per second to Data Mesh, which handles persisting the records to various data stores that other internal services can query.

From One Job to Many: Scaling Flink the Hard Way

Initially, we tried having just one Flink job that consumed all the Kafka source topics. However, this quickly became a big operational headache since different topics can have different data volumes and throughputs at different times during the day. Consequently, tuning the monolithic Flink job became extremely difficult — we struggled to find CPU, memory, job parallelism, and checkpointing interval configurations that ensured job stability.

Instead, we pivoted to having a 1:1 mapping from the Kafka source topic to the consuming Flink job. Although this led to additional operational overhead due to more jobs to develop and deploy, each job has been much simpler to maintain, analyze, and tune.

Similarly, each node and edge type is written to a separate Kafka topic. This means we have significantly more Kafka topics to manage. However, we decided the tradeoff of having bespoke tuning and scaling per topic was worth it. We also designed the graph data model to be as generic and flexible as possible, so adding new types of nodes and edges would be an infrequent operation.

Acknowledgements

We would be remiss if we didn’t give a special shout-out to our stunning colleagues who work on the internal Netflix data platform. Building the RDG was a multi-year effort that required us to design novel solutions, and the investments and foundations from our platform teams were critical to its successful creation. You make the lives of Netflix data engineers much easier, and the RDG would not exist without your diligent collaboration!

—

Thanks for reading the first season of the RDG blog series; stay tuned for Season 2, where we will go over the storage layer containing the graph’s various nodes and edges.

How and Why Netflix Built a Real-Time Distributed Graph: Part 1 — Ingesting and Processing Data… was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Securing Amazon Bedrock API keys: Best practices for implementation and management

Post Syndicated from Jennifer Paz original https://aws.amazon.com/blogs/security/securing-amazon-bedrock-api-keys-best-practices-for-implementation-and-management/

Recently, AWS released Amazon Bedrock API keys to make calls to the Amazon Bedrock API. In this post, we provide practical security guidance on effectively implementing, monitoring, and managing this new option for accessing Amazon Bedrock to help you build a comprehensive strategy for securing these keys. We also provide guidance on the larger family of service-specific credentials, so that you can also reinforce your AWS CodeCommit and Amazon Keyspaces (for Apache Cassandra) implementation if needed.

Note: For the remainder of this post, the terms service-specific credentials and API keys will be used interchangeably.

Choosing the best mechanism to access Amazon Bedrock

Our recommendation is to use temporary security credentials provided by AWS Security Token Service (AWS STS) service whenever possible as a preferred authentication method.

API keys can be used when your use case blocks the use of temporary AWS STS credentials. A common example is when using third-party or packaged software that specifically requires API key authentication through HTTP bearer tokens and cannot be configured to use SigV4 signing with temporary AWS STS credentials.

If you find that you don’t need to use API Keys, consider using service control policies (SCPs) to deny the creation and use of these keys.

If you conclude that your use case requires API keys, then consider the two types of API keys:

  • Short-term API keys: Consider using short-term API keys if AWS STS credentials cannot be used, because they provide a built-in expiration mechanism and will automatically expire after a specified duration, stopping credentials from being used indefinitely if they are exposed.
  • Long-term API keys: Long-term API Keys should only be used when neither AWS STS credentials nor short-lived credentials can be used, such as with packaged software and SDKs that expect a static long-lived API key and cannot be modified.

While implementing the controls in this post addresses most API key security concerns, remember that security is an ongoing process. Continue following AWS security best practices and regularly review your security posture as part of a comprehensive security strategy.

Understanding service-specific credentials

Service-specific credentials are specialized authentication credentials that provide direct access to specific AWS services. These credentials are different from other AWS security credentials (such as access keys, secret access keys, and session tokens) and are designed for use with specific AWS services.

The key characteristics of service-specific credentials include:

Let’s learn more about service-specific credentials and their use with Amazon Bedrock.

Amazon Bedrock API keys

Amazon Bedrock API keys are service-specific credentials that provide direct access to Amazon Bedrock. The bedrock:CallWithBearerToken permission grants the ability to use these tokens to perform Amazon Bedrock API actions.

Key types and characteristics

There are two types of API keys, and they have the following characteristics.

Short-term API keys:

  • Uses pre-signed SigV4 authentication
  • Short-term API keys are generated locally on the client side, therefore their creation of these short-term keys won’t be recorded in CloudTrail
  • Cannot be retrieved through credential reports or AWS CLI calls
  • Last as long as the IAM session that generated the API key or 12 hours, whichever is shortest
  • Have the same permissions as the role that you use to generate the key
  • Pattern: bedrock-api-key-YmVkcm9jay5hbWF6b25hd3MuY29tLz9BY3Rpb249Q2FsbFdpdGhCZWFyZXJUb2tlbiZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsP[A-Za-Z0-9\\]+={0,2}

Long-term API keys:

  • When an Amazon Bedrock long-term API key is created through the Amazon Bedrock console, AWS automatically generates a dedicated IAM user with the naming convention BedrockAPIKey-xxx and attaches the AmazonBedrockLimitedAccess managed policy
  • The IAM user created through the Amazon Bedrock console doesn’t have console access enabled, a console password, an access key, or multi-factor authentication (MFA) enabled
  • Alternatively, when an Amazon Bedrock long-term key is created through the IAM console, you can associate the Amazon Bedrock service-specific credential directly to an existing IAM user
  • Each IAM user can have up to two long-term API keys
  • Can be configured with expiration periods ranging from one day to indefinite duration.
  • Duration can be controlled with three new condition keys to govern API keys for Amazon Bedrock. Here is an example SCP.
  • Pattern: ABSKQmVkcm9ja0FQSUtleS[A-Za-z0-9+\/]+={0,2}
  • CloudTrail will log an event when long-term API keys are created, as shown in the following example. You can also identify long-term API keys using the AWS CLI.
{
    "eventTime": "2025-07-23T17:39:08Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "CreateServiceSpecificCredential",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.1",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0",
    "requestParameters": {
        "userName": "BedrockAPIKey-0g21",
        "serviceName": "bedrock.amazonaws.com",
        "credentialAgeDays": 36500
    },
    "responseElements": {
        "serviceSpecificCredential": {
            "createDate": "Jul 23, 2025, 5:39:08 PM",
            "expirationDate": "Oct 7, 2125, 5:39:08 PM",
            "serviceName": "bedrock.amazonaws.com",
            "serviceCredentialAlias": "BedrockAPIKey-1234-56-EXAMPLE
",
            "serviceCredentialId": "ACCA123456789EXAMPLE",
            "userName": "BedrockAPIKey-0g21",
            "status": "Active"
        }
    }
}

Identify

There are several key aspects to understand when working with API keys. Short-term API keys are generated on the client-side and aren’t visible through standard AWS API listings.

Long-term API keys offer some additional visibility and can be managed through multiple methods. You can identify which principal has an associated long-term API key by using the Amazon Bedrock console or IAM console. You can list service-specific credentials using AWS CLI commands or the AWS SDK, which will list the service-specific credentials for a specified user.

Protect

Bedrock has introduced three condition keys that enhance your ability to control and secure API key usage within your AWS environment:

  • You can use the iam:ServiceSpecificCredentialServiceName condition key to allow the AWS services that a principal can create service-specific credentials for.
  • Use the iam:ServiceSpecificCredentialAgeDays condition to enforce security best practices by setting a maximum duration limit for long-term API keys at creation time.
  • Finally, by using the bedrock:BearerTokenType condition key, you can deny or allow the use of a specific type of API key for Amazon Bedrock, whether it’s a short-term or long-term API key.

These condition keys play an important role in managing the distinct security characteristics of short-term and long-term API keys, enabling security teams to enforce organizational policies and security best practices through SCPs at the AWS Organizations level. To learn more, see the GitHub repo for examples of how to apply these SCPs.

Short-term API keys include a native expiration window that helps limit potential security exposure. When implementing these keys, be aware that they inherit the permissions of the signing principal, which can be more than Amazon Bedrock permissions. You can implement comprehensive monitoring as described in the Detect section.

Long-term API keys, which can be configured with extended expiration periods, offer convenience for long-running applications but should have special attention regarding controls and monitoring mechanisms to offset the increased exposure window these credentials present.

If your organization has decided that Amazon Bedrock API keys aren’t required for your environment, you can implement SCPs to block the creation of service-specific credentials (iam:CreateServiceSpecificCredential) and block bearer token use for Amazon Bedrock (bedrock:CallWithBearerToken).

Note: If you do not use the condition iam:ServiceSpecificCredentialServiceName in an IAM policy, iam:CreateServiceSpecificCredential will then also deny the creation of API keys for other services, such as AWS CodeCommit and Amazon Keyspaces (for Apache Cassandra).

Here’s an example SCP that denies the creation of Amazon Bedrock service-specific credentials and the use of API keys in Amazon Bedrock. This prohibits builders in your organization from creating new API keys, reducing the risk of unauthorized key creation. This approach is valuable for organizations that want to maintain strict control over their authentication methods or have no business need for service-specific credentials. A condition can also be added to the SCP to allowlist specific roles to be able to create service-specific credentials by adding a condition ArnNotLikeIfExists for the principals listed under aws:PrincipalArn.

As part of protecting API keys, regularly review and adjust permissions to align with the principle of least privilege. For long-term API keys created through the Amazon Bedrock console, AWS automatically creates an IAM user with the AmazonBedrockLimitedAccess managed policy. This policy grants access to various Amazon Bedrock, AWS Key Management Service (AWS KMS), IAM, Amazon Elastic Compute Cloud (Amazon EC2), and AWS Marketplace actions. For both long-term and short-term API keys, evaluate if your principals have more permissions than required for their use case. If excessive permissions are identified, replace the AmazonBedrockLimitedAccess policy with a custom policy that has scoped down permissions.

Detect

API keys require different monitoring approaches based on their type. While the creation of short-term API keys cannot be detected because they are generated client-side, the creation of long-term API keys can be monitored through CloudTrail events. However, the use of both short-term and long-term API keys can be detected through CloudTrail events. Because of their extended validity period, long-term API keys are more susceptible to unauthorized use, making comprehensive monitoring essential. Organizations should implement stringent monitoring controls including:

  • Monitor CreateUser events with BedrockAPIKey- prefix usernames. If a user was created through the Amazon Bedrock console, the event will look like the following:
    • {
    "eventTime": "2025-07-23T17:39:08Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "CreateUser",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.1",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0",
    "requestParameters": {
        "userName": "BedrockAPIKey-0g21"
    },
    "responseElements": {
        "user": {
            "path": "/",
            "userName": "BedrockAPIKey-0g21",
            "userId": " AIDACKCEVSQ6C2EXAMPLE",
            "arn": "arn:aws:iam: 111122223333:user/BedrockAPIKey-0g21",
            "createDate": "Jul 23, 2025, 5:39:08 PM"
        }
    }
}

    • Track CreateServiceSpecificCredential events for requestparameters.serviceName = bedrock.amazonaws.com
    • Watch for active API key usage indicators:
      • additionalEventData.callWithBearerToken = true
      • eventSource = bedrock.amazonaws.com
    {
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": " AIDACKCEVSQ6C2EXAMPLE",
        "arn": "arn:aws:iam::user/BedrockAPIKey-0g21",
        "accountId": "",
        "userName": "BedrockAPIKey-0g21"
    },
    "eventTime": "2025-07-23T17:39:37Z",
    "eventSource": "bedrock.amazonaws.com",
    "eventName": "Converse",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "",
    "userAgent": "curl/8.11.1",
    "requestParameters": {
        "modelId": "us.anthropic.claude-3-5-haiku-20241022-v1:0"
    },
    "responseElements": null,
    "additionalEventData": {
        "callWithBearerToken": true,
        "inferenceRegion": "us-west-2"
    }
}

    For a list of events to monitor, see Security Playbook for Responding to Amazon Bedrock Security Events.

    Amazon EventBridge rules

    You can enhance your security monitoring by implementing Amazon EventBridge rules to detect and alert on Amazon Bedrock API key lifecycle events, such as CreateServiceSpecificCredential.

    Using EventBridge rules for monitoring has four components.

    • EventBridge rules: CreateServiceSpecificCredentialRule and BearerTokenUsageRule monitor CloudTrail for credential creation and bearer token usage
    • SNS topic: BedrockAlertsTopic delivers encrypted security alerts through email
    • KMS key: SNSEncryptionKey encrypts SNS messages
    • IAM roles: Provide necessary access for service operations

    The preceding EventBridge rules monitor for specific patterns within a CloudTrail log, keying from eventName (the action being performed), eventSource (the service that the action is being performed by or to), and additionalEventData (the block of details of the response).

    The following rule checks for the CloudTrail event CreateServiceSpecificCredential.

            source:
          - aws.iam
        detail-type:
          - AWS API Call via CloudTrail
        detail:
          eventSource:
            - iam.amazonaws.com
          eventName:
            - CreateServiceSpecificCredential

    Use the following rule to look for actions performed with an API key (BearerToken = true):

            detail-type:
          - AWS API Call via CloudTrail
        detail:
          additionalEventData:
            callWithBearerToken:
              - true

    EventBridge rule deployment

    Use the CloudFormation template to set up automated monitoring for both the creation of service-specific credentials and their subsequent use. The template configures EventBridge to send email notifications when the preceding CloudTrail events are detected, providing real-time awareness of API key operations in your environment. To learn more, see the GitHub repo for the details of this solution and the CloudFormation template.

    AWS Config rule for compliance

    Use an AWS Config rule to monitor IAM users for active service-specific credentials to help maintain compliance with security policies.

    The following are the steps taken by the AWS Config rule:

    1. Every 24 hours, the AWS Config rule triggers a Lambda function that enumerates IAM users in the account
    2. For each user, the function checks for active service-specific credentials
      1. Users with service-specific credentials are marked as NON_COMPLIANT
      2. Users without active credentials are marked as COMPLIANT
    3. Results are submitted to AWS Config for reporting and potential remediation

    Config rule deployment

    You can deploy this AWS Config rule by using AWS Config RDK, in CloudShell, or using your local CLI.

    1. git clone https://github.com/awslabs/aws-config-rules.git
    2. cd aws-config-rules/python-rdklib
    3. git fetch && git checkout IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS
    4. pip install rdk rdklib
    5. rdk deploy IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS
    6. aws configservice start-config-rules-evaluation --config-rule-names “IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS”

    Respond and recover

    Every incident response plan starts with the preparation phase. As part of the preparation phase, you should maintain clear records of API key ownership and usage, document which applications and teams use specific keys, and if long-term API keys are necessary, consider using secure storage such as AWS Secrets Manager.

    When a security incident involving API keys is suspected, immediate action is crucial. The first step is to verify the potential compromise by reviewing CloudTrail logs to correlate API key creation use with approved change requests. This helps identify unauthorized key creation or use. Additionally, analyzing the source IP addresses and user agent strings from these logs can help determine if the access originated from approved locations and applications or potentially malicious sources.

    The incident response approach varies significantly between key types. For short-term keys, while their maximum 12-hour expiration window limits potential damage, it’s still important to take immediate action rather than waiting for expiration. Security teams should identify applications or systems using the compromised short-term key and revoke the IAM role session or deny permissions to bedrock:CallWithBearerToken from the identity.

    If an Amazon Bedrock long-term API key is involved in an active security event, security teams can take immediate action through either the console or AWS CLI. Through the console, teams can use the IAM console to quickly deactivate or delete long-term API keys. For organizations with automated response procedures, the AWS CLI provides commands for key management:

    Respond using the AWS CLI

    Use the following steps to respond to an API key event.

    1. Identify service-specific credentials:

    aws iam list-service-specific-credentials --user-name <user name> --service-name bedrock.amazonaws.com

    1. For immediate containment, you can deactivate the credential using the credential ID from the previous step:

    aws iam update-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name> --status Inactive

    1. After you’ve assessed the event, you can permanently remove the associated API keys:

    aws iam delete-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name>

    During the recovery phase, focus on creating new secure keys with appropriate configurations, updating application configurations, and make sure that all affected continuous integration and delivery (CI/CD) pipelines and development teams are notified of the changes.

    Review of Amazon Bedrock API keys

    The following table summarizes the various elements related to Amazon Bedrock API keys mapped to the NIST CSF 2.0 core function.

    Type

    Identify

    Protect

    Detect (using events in CloudTrail)

    Respond

    Short-term API key Whitetexttexttexttext

    Short-term API keys are generated client-side and are not listed by an AWS API.

    Creation: Cannot block creation because short-term API keys are generated client-side.

    Use: Deny action bedrock:CallWithBearerToken to avoid use

    Modify permissions for long-term and short-term Amazon Bedrock API keys

    Creation: Occurs client-side and no events are present in CloudTrail

    Use: CloudTrail events with additionalEventData.callWithBearerToken = true

    EventBridge rules and SNS to detect/notify on the usage of API keys.

    Revoke IAM role session or deny permissions from identityWhitetexttexttext

    Long-term API key Whitetexttexttexttext

    IAM ListServiceSpecificCredentials action using the AWS CLI or SDKs

    Creation: Deny action iam:CreateServiceSpecificCredential to block creation of service specific credentials across the services, including Amazon Bedrock.

    Use: Deny action bedrock:CallWithBearerToken to avoid use

    Modify permissions for long-term and short-term Bedrock API keys

    Creation: CloudTrail events with eventName iam:CreateServiceSpecificCredential, and iam:CreateUser when using the console.

    Use: CloudTrail events with additionalEventData.callWithBearerToken = true

    EventBridge rules and SNS to detect and notify on creation and usage of API keys.

    Config rule

    Use the console or AWS CLI to quickly deactivate or delete long-term API keys Whitetexttexttext

    Broader service-specific credentials: Beyond Amazon Bedrock

    Along with Amazon Bedrock support of API keys, other AWS services support service specific credentials, such as AWS CodeCommit and Amazon Keyspaces.

    The security measures suggested in this post can also be applied to these services. The following table lists common use cases for these service specific credentials.

    Service

    Use case

    Service name in response from iam:ListServiceSpecificCredentials

    Suggested alternatives

    AWS CodeCommit Git credentials

    Used to upload, add, or edit a file in an AWS CodeCommit repository

    codecommit.amazonaws.com

    Methods include SSH authentication and federated authentication: AWS CodeCommit: Setting up using other methods

    Amazon Keyspaces credentials for Apache Cassandra

    Used for Apache Cassandra-compatible access

    cassandra.amazonaws.com

    SigV4 authentication plugin is available and supports multiple programming languages and enables IAM roles and federated identities to authenticate. Create temporary credentials to connect to Amazon Keyspaces using an IAM role and the SigV4 plugin

    Conclusion

    Understanding the implications of long-term API keys and how to manage them helps you to make informed decisions about your Amazon Bedrock API key implementation strategy. The key is to align security controls with risk appetite and operational requirements while maintaining a strong security posture.

    AWS strongly recommends using AWS STS credentials as the primary authentication method wherever possible. If AWS STS credentials cannot be used, consider short-term API keys with their built-in expiration mechanism. Long-term API keys should only be implemented when neither AWS STS credentials nor short-term credentials are viable options. When implementing API keys, organizations should focus on identifying API keys through AWS CLI and CloudTrail logs, protecting by implementing preventive controls such as SCPs to manage API key creation and usage, detecting API key activities through comprehensive monitoring using CloudTrail events, EventBridge and AWS Config rules, and responding by maintaining clear incident response procedures to quickly address potentially compromised API keys.

    Best practice is to implement these controls while maintaining proper access controls through the principle of least privilege. This layered approach helps you maintain a strong security posture while effectively using API keys for your development needs.

Jennifer Paz

Jennifer Paz
Jennifer is a Security Engineer with over a decade of experience, currently serving on the AWS Customer Incident Response Team (CIRT). Jennifer enjoys helping customers tackle security challenges and implementing complex solutions to enhance their security posture. When not at work, Jennifer is an avid runner, pickleball enthusiast, traveler, and foodie, always on the hunt for new culinary adventures.

Kyle Dickinson

Kyle Dickinson
I was once a Gibson explorer turned cloud security expert; as a Sr. Security Solution Architect at AWS, I now protect the systems I once explored. When not safeguarding AWS customers, I’m building LEGO creations or attempting to improve my longboarding skills without major injury. My home life revolves around a tiny dog with massive confidence and my spirited 4-year-old daughter, who keeps me laughing.

Transition of RubyGems Repository Ownership

Post Syndicated from jzb original https://lwn.net/Articles/1042480/

The Ruby community has experienced some turbulence
of late after Ruby Central took
control of the GitHub repositories for a number of projects
including RubyGems
and Bundler. Those projects have historically been developed
separately from Ruby itself. They are now being put under the
control of Ruby’s core team, according to Ruby creator Yukihiro
Matsumoto (a.k.a. “Matz”):

To provide the community with long-term stability and continuity,
the Ruby core team, led by Matz, has decided to assume stewardship of
these projects from Ruby Central. We will continue their development
in close collaboration with Ruby Central and the broader
community.

Ruby Central has also issued a statement.

[$] A brief history of RubyGems.org

Post Syndicated from jzb original https://lwn.net/Articles/1042131/

Ruby libraries and
applications are distributed via a packaging format called a gem. RubyGems.org has been the central
hosting service for gems since about 2010. This article is part one of
a two-part series on the RubyGems.org takeover by Ruby Central. Understanding the
history of RubyGems.org, and the contributor community behind it, is
vital to making sense of the current power
struggle between Ruby Central and members of the Ruby
community who have maintained those services and tools for many
years.

Security updates for Friday

Post Syndicated from daroc original https://lwn.net/Articles/1042452/

Security updates have been issued by AlmaLinux (kernel and libssh), Debian (firefox-esr and pgpool2), Mageia (varnish & lighttpd), Red Hat (python3, python3.11, python3.12, python3.9, and python39:3.9), SUSE (expat, gstreamer-plugins-rs, kernel, openssl1, pgadmin4, python311-ldap, and squid), and Ubuntu (dotnet8, dotnet9, dotnet10 and mupdf).

Конграчулейшънс, Борисов 2.0

Post Syndicated from Емилия Милчева original https://www.toest.bg/congratulations-borisov-2-0/

Конграчулейшънс, Борисов 2.0

Лидерът на ГЕРБ Бойко Борисов е в 42-рата гестационна седмица и скоро ще (се) роди променена власт, която обаче едва ли ще издържи дълго след ремонта. Не и до изборите за президент и вицепрезидент следващата есен. 

Въпреки петъчните изявления, че никой от партията не иска избори, след 42-рата седмица вече е рисково и за „майката“, и за „бебето“ и всеки лекар би посъветвал за секцио по спешност. А Борисов и премиерът Росен Желязков предложиха разговори за укрепване на коалицията, в които освен ГЕРБ–СДС, БСП и „Има такъв народ“ ще включи и ДПС – Ново начало. Там ще се разберат как да узаконят съвместното съжителство с Пеевски.

Резултатите от докладите на областните координатори, кметовете и депутатите показват, че никой не иска да ходи на избори, включително и ГЕРБ.

Тежките отговорности

Егото на Борисов кърви. На партията и на неговия гръб тежат отговорностите на управлението, докато съюзниците във властта берат плодове и правят компоти. Дори сгромолясващата се по нанадолнището БСП получава 493 гласа повече спрямо 2023 г. на извънредните избори за общински съвет в Пазарджик. А ГЕРБ, вместо да получават шестици, са шестаци, защото са на шесто място, и разни хиени ръфат периферията и си проправят път към твърдото партийно ядро. Премиерът Росен Желязков е добре посрещнат на европейски форуми, а в България всички крила на опозицията плюс президента Радев нападат Борисов, че Пеевски му е стъпил на врата, и го ядосват с подигравчийски есемеси. Но в действителност му показват кой глозга ГЕРБ и не се насища.

Олигархът партиен лидер може да е спасение за стабилността, но „ковиден“ за ГЕРБ, тъй като умерените избиратели на партията не приемат този съюз. Не го приемат и някои представители на партийните кръгове. ГЕРБ може да разчита на клиентелисткия си електорат, но заради факта, че властта се споделя с повече политически сили, той също е намалял.

След като всички телевизии ретранслираха гибелния гняв на трикратния премиер и началник на първата политическа сила Бойко Методиев Борисов, държавата спря работа. Министър-председателят отмени заседанията на правителството, парламентът няма кворум и също не работи. Като че ли е обявен национален траур, а не антракт преди второ действие с договаряне и преразпределение на порции в изпълнителната власт. Зад кулисите тръгна „преформатирането“.

В понеделник, все едно че нищо не се е случило, държавата пак ще заработи след дългата пауза, в която нито една министерска или депутатска заплата не е била прекъсната. 

Конкуренцията настъпва

Лидерът на ГЕРБ ще изтръска некои от широкия си гръб, за да гарантира и зрелищата. Засега е изпаднал само директорът на Областната дирекция на МВР в Пазарджик старши комисар Даниел Бараков, иначе трябваше да е министърът на вътрешните работи Даниел Митов, който е и заместник-председател на ГЕРБ.

Каквото и да прави Борисов обаче, нито ще потуши напрежението в управляващата коалиция, нито ще възвърне доминацията му на политическата сцена. А през 2026 г. ще има сериозна конкуренция в лицето на нов партиен лидер – Румен Радев. Защо не и партньор? За разлика от Пеевски, водачът на ГЕРБ не влиза в остра конфронтация с Радев – макар да го нарече „проруска алтернатива“ във вулканичното си слово – и никак не са изключени контакти между двамата далеч от публичността.

Въпреки че всички все още са предпазливи в говоренето за предсрочните избори, никой вече не се съмнява, че настоящият президент има амбиции за изпълнителната власт.

Това означава, че ще напусне „Дондуков“ 2 доста по-рано от януари 2027 г., когато е клетвата на новите президент и вицепрезидент. За да го направи, е необходим взрив на социално напрежение, което да му утъпче пътя на спасител и да го издигне до първите места в социологическите проучвания.

Колко рано? Напролет или наесен? Бързината, с която Борисов поиска да бъде сменена председателката на 51-вото Народно събрание Наталия Киселова (БСП), означава, че може да са по-рано, и за да няма изненади, „домовата книга“ с кандидати за премиери трябва да бъде попълнена с „правилната“ селекция. Председателят на парламента е първият, който ще бъде поканен за служебен премиер при предсрочни избори. А освен че бе нарочена за смяна, Киселова бе и публично опозорена с обидния коментар на Бойко Борисов.

Киселова, където види празник на роза, на ягода, на череша, на слива, на джанка, на маруля – заминава там да се показва. Камо ли ако има мач, ако има нещо волейбол… то е чудо. Деветнайсет депутати или там колко има зад гърба си… Откъде накъде? Трябва да пита, преди да тръгне: имате ли против?

Въпреки това Киселова не може да стигне Бойко-Борисовата Цвета Караянчева, която „дари“ старите килими от парламента на театъра в Кърджали. 

Социалистите дадоха да се разбере, че нямат нищо против да жертват преподавателката по конституционно право. Председателят на БСП Атанас Зафиров, който е и вицепремиер, обяви, че са готови на всякакви разговори, за да запазят правителството. Никой не е и очаквал друго.

Засега не е ясно дали Киселова е „помилвана“ от отстраняване. Все пак беше единствената, чието име беше огласено от Бойко Борисов за незабавна смяна.

А Зафиров даде тон за калесването на ДПС – Ново начало, което за него не било официализирано.

Критика по същество срещу работата на госпожа Киселова аз не съм чул до момента. В същото време, ако се върви към преформатиране на това управление, към ново управленско мнозинство, формално, защото то съществува в момента това мнозинство, но не е официализирано, тогава е съвсем нормално този разговор да започне отначало, включително с позицията председател на НС.

Тоест няма против да се посместят на „Дондуков“ 1, за да пуснат в Министерския съвет и новите депесари.

Санкционираният за корупция от САЩ и Великобритания даже чака пред вратата. „Ако има нужда да споделим отговорността и на ГЕРБ им тежи това нещо, ние сме готови“, каза Пеевски на въпрос ще дадат ли министри. 

Щели да имат решение до понеделник, предполагам, че той изчаква Борисов, всичко е в ръцете на Борисов – дали ще хвърли държавата в бездната… Видяхте колко време подкрепяме този кабинет без нищо, само заради хората. Готови сме и така да продължим да го подкрепяме, готови сме и да споделим отговорността.

Но Европейската народна партия едва ли ще е съгласна с точно това споделяне на отговорности.

Тихо, тихо! Пре-фор-ма-ти-ра-не

„Преформатиране на управлението“ означава пренареждане на участниците и ролите във властта, без формално да се стига до оставка и нови избори. Иначе е известно като „ремонт на кабинета“, но „преформатиране“ звучи някак технократско, по-авторитетно и… трудоемко. Борисов и Пеевски с чукове в ръка скулптират масивния ръбест коалиционен блок, изчуквайки оттук-оттам някое бесепе или итънъ. За да бъде разбран от широката публика, лидерът на ГЕРБ нарича този процес „разсънването на будалата“. 

Борисов не чупи коалицията: „Няма да чупим коалицията, но и няма да стоим тук по този начин.“ Само пречупва партньорите, за да приемат решенията му.

Ако пусне Пеевски през парадния вход на властта, Борисов ще завърши легитимирането му, макар и да не успя да го избели чрез сваляне на санкциите по „Магнитски“. Е, поне опита. БСП са съгласни съжителството с Пеевски да се узакони, остава и ИТН да се произнесат. Засега мълчат. Лидерът Слави Трифонов има опит в развалянето на правителства. Ако реши, че участието в настоящия кабинет е лебедовата им песен във властта, може и да склони. Но може и да се престорят на бегачи на дълги разстояния и да откажат.

С „официален“ Пеевски обаче Борисов би подписал предсмъртното си писмо, а и самият Пеевски няма полза да убие своя гостоприемник. Без партия, на чийто гръб да тежи, той е никой въпреки маниакалното възвеличаване и контрола над съдебната власт. 

А за президента Румен Радев се откриват най-добрите мишени.

Ставаме свидетели как Борисов капитулира пред Пеевски и му предава властта. 

Преддверие на криза

Преформатирането обаче е преддверие на криза и предсрочни избори. От ПП–ДБ виждат две решения: или правителството на Желязков да поиска вот на доверие, или да преформатират правителството с нови лица. „Страната има нелегитимен център на власт – институциите, службите и съдебната система са пленени“, заяви съпредседателят на „Да, България“ Ивайло Мирчев и отбеляза, че това прави невъзможно провеждането на нормални, честни избори. По повод подкрепата, която Борисов поиска от ПП–ДБ, другият съпредседател – Божидар Божанов, коментира, че завладяната държава и ролята на Пеевски в нея са фундаменталните проблеми на политическата система в България:

Ако Борисов не беше тотално приклещен от Пеевски, вече щеше да е представил план за пълното му изолиране от властта.

Лидерът на „Възраждане“ Костадин Костадинов смята, че Борисов е уплашен, и определя речта му като „зов за помощ“. 

Ако беше разгневен, във вторник щеше да е напуснал правителството. Примирено е избрал ролята на Ахмед Доган… Ако намери достатъчно смелост в себе си, ще отиде на избори. Собствената му партия иска избори.

Според Костадинов Борисов и Пеевски са в „смъртоносна схватка за надмощие и оцеляване“, но това няма да продължава вечно, защото ГЕРБ няма как да се примири с ролята си на втора цигулка.

Предвид двете особено трудни задачи пред управляващите – бюджет 2026 и подготовката за еврозоната от 1 януари, кандидатите за властта са се поснишили. Така де, като ГЕРБ са поели отговорността, да си я носят заедно с оглозганите кокали!

Да се остави процесът по въвеждане на еврото в ръцете на служебно правителство е безразсъдно и безотговорно. Смените на няколко министри сега биха разредили напрежението, но няма да се решат структурните слабости на бюджета за догодина, за които предупреждават бизнес и анализатори.

Без структурни мерки ще има дефицити и бюджетът ще катастрофира. Трябва да имаме дефицит, не по-голям от 2% от БВП… България може да стане първата държава в еврозоната, която в първата си година няма да има растеж.

Любомир Дацов, член на Фискалния съвет и бивш заместник-министър на финансите

До края на годината бюджетът за 2026-та ще изглежда нарисуван много добре. Това не означава, че ще бъде полезен. Знаем кой със сигурност ще спечели – хората на висша държавна длъжност, особено т.нар. органи за сигурност. Ако вземете бюджета на съдебната система, особено прокуратурата, той е увеличен два пъти за три години.

Красен Станчев, Институт за пазарна икономика

Дори гуверньорът на БНБ Димитър Радев наруши традиционното за централен банкер мълчание, за да предупреди, че ако бюджет 2026 прилича на тазгодишния, идва криза, а България се отдалечава от модела на пазарна икономика, защото растежът идва от държавните заплати, а не от частния сектор.

„Преформатирането“ няма да реши нито един от тези значими проблеми. Гражданите нямат нужда от моноспектаклите на Борисов (който сигурно е проумял, че повече никога няма да бъде премиер), а от големия разговор за модернизацията на държавата и от законност и справедливост. Този език Борисов не го говори, Пеевски още по-малко.

Тоест разговаряме – епизод 2

Post Syndicated from Владислав Севов original https://www.toest.bg/toest-razgovaryame-epizod-2/

Тоест разговаряме – епизод 2

В разговора с Емилия Милчева стъпихме на нейното кредо за бавна журналистика и основната роля на въпроса „Защо?“. Говорихме за банализираната корупция и културата „имам човек“… Важна тема бяха и протестите – лекуват ли системата и има ли опасност да са в помощ на „други играчи“. Гражданските сдружения и участието им в политиката, нуждата политиците да търсят жива връзка с избирателите, регулаторните комисии и възможните подходи към работата им по същество, а не като „бухалки“ – на такива теми посветихме частта със зрителски въпроси. Завършихме с личното „защо“ на Емилия Милчева към професията и предстоящите ѝ планове – книгата с работно заглавие „Колелото на късмета“ и документалния подкаст за т.нар. Възродителния процес.

Гледайте целия разговор в нашия YouTube канал:

Може да го чуете и като аудиозапис в SoundCloud:



Злодей ли е Пеевски?

Лесно е да се мисли в категориите „черно и бяло“, „добър и лош“ – удобно е предимно от пропагандна гледна точка. Да, той е злодей, защото носи отговорност за една порочна система. Но не цялата отговорност. Част от нея носим и всички ние, които с бездействие или с това, че очакваме и искаме да бъдем корумпирани, съдействаме за нея.

Той е злодей, защото е символ на определен модел на власт – чрез страх и мрежи от интереси. Но той не е аномалия, а резултат от начина, по който българската политическа и икономическа среда „възнаграждава“ бруталните играчи, а съдебната система се страхува да им търси отговорност. Зад гърба на Пеевски се крият много „пеевчета“ – и което е още по-страшно, ние не познаваме техните лица. Те може да са възпитани, мили, красиви, но в същността си да са Пеевски.

Злодеи в демокрацията няма – има неработещи институции, които позволяват на един човек да концентрира власт, без да носи отговорност, и да злоупотребява с нея, както намери за добре.

Преди срещата ви помолихме да отговорите на кратката ни анкета. Ето и резултатите от нея:

Тоест разговаряме – епизод 2

Емилия Милчева е редовна коментаторка на политическите процеси в България, от 2018 г. е авторка на анализи в „Тоест“ и на репортажи за българската редакция на „Дойче Веле“. Журналистка, която не се задоволява с „какво“ – винаги търси „защо“. В текстовете ѝ няма ефектни фрази, а точен поглед върху онова, което често остава под повърхността. Вярва в критичния ум, любопитството и щипката лудост.

Следващата среща на „Тоест разговаряме“ ще бъде с Павлина Върбанова, водещата на рубриката „Порция език“, и ще се проведе на 1 ноември 2025 г., събота, от 16:00 ч. на живо в YouTube Live.

В „Тоест разговаряме“ всеки месец ви срещаме с автори, които познавате добре от анализите или от рубриките им в „Тоест“, но този път ще ги видите и чуете в по-личен и непосредствен формат. Във видеоразговорите, предавани на живо, активно участие имате и вие, нашата публика – със своите въпроси, коментари и включване в тематичната анкета. Водещ на поредицата е Владислав Севов, дългогодишен телевизионен журналист и съосновател на „Тоест“.

Тоест разговаряме – епизод 2

„Тоест разговаряме“ е поредица, подкрепена от Институт „Отворено общество – София“ и съфинансирана от Европейския съюз в рамките на проекта Media Resilience. Изразените възгледи и мнения са само и изцяло на техните автори и не отразяват непременно възгледите и мненията на Европейския съюз, на Европейската изпълнителна агенция за образование и култура (EACEA) или на Институт „Отворено общество – София“ (ИООС). Нито Европейският съюз, нито EACEA, нито ИООС могат да бъдат държани отговорни за тях.

A Surprising Amount of Satellite Traffic Is Unencrypted

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/10/a-surprising-amount-of-satellite-traffic-is-unencrypted.html

Here’s the summary:

We pointed a commercial-off-the-shelf satellite dish at the sky and carried out the most comprehensive public study to date of geostationary satellite communication. A shockingly large amount of sensitive traffic is being broadcast unencrypted, including critical infrastructure, internal corporate and government communications, private citizens’ voice calls and SMS, and consumer Internet traffic from in-flight wifi and mobile networks. This data can be passively observed by anyone with a few hundred dollars of consumer-grade hardware. There are thousands of geostationary satellite transponders globally, and data from a single transponder may be visible from an area as large as 40% of the surface of the earth.

Full paper. News article.

Гласовете на Америка – брой 9

Post Syndicated from Йоанна Елми original https://www.toest.bg/glasovete-na-amerika-broy-9/

Гласовете на Америка – брой 9

„Американците искат умереност и баланс както в живота си, така и у лидерите, които водят държавата – не конфликти и поляризация. Ние не сме нация от фанатици, твърдо решени да превърнат „другите във врагове“. Ние сме общество, което всеки път, когато е било изправено пред криза, рано или късно е намирало общ път напред в името на споделеното ни наследство“, казва политологът Алън Улф, автор на книгата „В крайна сметка една нация. Какво всъщност мислят американците за Бог, държавата, семейството, расизма, помощите, имиграцията, хомосексуалността, работата, дясното, лявото и един за друг“ (One Nation, After All: What Americans Really Think About God, Country, Family, Racism, Welfare, Immigration, Homosexuality, Work, The Right, The Left and Each Other). 

През 2006 г. Улф е един от интелектуалците, които спорят по въпроса има ли, или няма културни войни. На пръв поглед абсурден почти 20 години по-късно, въпросът продължава да е все така актуален във време, в което очевидно неморалното или неправилното лесно се пречупват през призмата на определена културно-политическа идеология и стават основателни, искани, оправдани. Независимо дали говорим за дебати за бъдещето на платформата TikTok в САЩ, за подкрепата за улесняване на пътя на висококвалифицирани имигранти до американско гражданство, или за митата (които дори спечелиха на Тръмп акронима TACO – от Trump Always Chickens Out, или „Тръмп винаги го хваща шубето“), подкрепата или опозицията по даден въпрос обикновено сравнително бързо се разделят по идеологическа линия – докато партията/президентът не промени мнението си. 

Що е то „културна война“? 

Както всяка друга война, и културната цели власт. Словосъчетанието е буквална заемка от немски (Kulturkampf) и набира популярност през 70-те години на XIX в., когато губещата влияние и власт Католическа църква под водачеството на папа Пий IX се изправя срещу зараждащата се идеология на националната държава, в случая Кралство Прусия под властта на Ото фон Бисмарк. Ценностите на Просвещението – не само национализмът, но и секуларизмът, либерализмът и научният реализъм – са в директен конфликт с църковната власт, която от векове държи контрола над държавните работи, образованието и вярата, простичко казано – над обществения ред. 

Пренареждането на обществото от монархия, в която кралят е божи избраник, подкрепян от църквата, към национална държава настъпва не само през зараждането на нови идеологии, методи на мислене и навици, но и с възникването на нова, по-заможна търговска и гражданска класа на фона на обедняването на монархиите и църквата.

Процесът е хем съпоставим с настоящето, хем трудно разбираем от днешна гледна точка: живеем във време, в което държавата и националната принадлежност като обединител на обществото са поставени под въпрос, а корпорации и частни лица имат много по-голям капитал от БВП на множество държави, което им позволява да упражняват и много по-голяма власт, включително през медиите. В такива времена се зараждат нови идеологии и нови идеи как трябва да живеем заедно. Какво точно кристализира накрая, показва само времето. 

В опита си да опази влиянието си Католическата църква се опитва да наложи по-строг контрол над сфери като брака, семейството, образованието. Основават се асоциации, вестници, училища, групи и ордени, които насърчават определени религиозни практики. Католическата пропаганда – включително и за ежедневни събития – се разпространява чрез местни и национални органи из цяла Западна Европа. Папите издават енциклики (папски послания до всички католици), в които заклеймяват либерализма, свободата на пресата, свободата на религиите, разделението между църквата и държавата, гражданския брак, идеята, че народът може да бъде суверен и др. Църквата издава и дълги списъци със забранени книги. Ако ви звучи познато, има причина. От своя страна зараждащият се европейски либерализъм приема църковните догми като война срещу модерната държава, науката и духовната свобода. 

Културната война: на Западния фронт нищо ново

През 1991 г. излиза от печат книгата „Културните войни. Борбата за значението на Америка“ (Culture wars: the struggle to define America) от Джеймс Хънтър, професор във Вирджинския университет. Тезата му е, че е налице война между „традиционалисти“ и „прогресивисти“ – първите поддържат морални идеали, наследени от миналото, а вторите се стремят към промяна и гъвкавост. Тези различни гледни точки са в основата на все по-нажежени дискусии по теми като абортите, сексуалността, образованието и ролята на религиозните институции в обществото. Дебатите се водят от различни групи и проникват чак до нивото на институциите, поради което все по-често се поставя под въпрос какви всъщност са ценностите на САЩ и как трябва да бъде „подредено“ американското общество.

Няколко години по-късно излиза и книгата на Алън Улф, който изказва противоположна теза: ако изобщо има културна война, повечето американци (обикновените хора) изобщо не се вълнуват от нея:

Американците вярват както в традиционните религиозни ценности, така и в правото на лична свобода, така че невинаги е лесно да се каже кое от двете е по-важно за тях. 

Още през 80-те години на миналия век Хънтър забелязва сходни тактики при леви и десни активисти, които се занимават с редица ключови въпроси: аборти, гей права, пушене и протести срещу ядреното оръжие. Според него много от конфликтите се разиграват на местно ниво, без връзка помежду си, но разделителните линии са едни и същи, със силно сходство между използваните културни символи и реторика. 

Според Улф пък става въпрос за процес, който се движи отгоре надолу: политическите партии робуват на все по-екстремни идеологии, позволявайки на най-шумните активисти да задават тона. Въпреки че консервативната партия по онова време е силна, казва Улф, те се възприемат като по-слабата страна, тъй като политическите им победи не успяват да променят поведението и навиците на повечето хора.

Парадоксалното е, че Америка се движи все по-надясно политически, но все по-наляво в културно отношение. Огромна мотивация за консерваторите са гневът и разочарованието от моралния упадък на страната. Но те трябва да се обърнат навътре, интроспективно, и да разберат, че политиката, дори консервативната, няма да им помогне, ако бракът им е нещастен, децата им се бунтуват, а политическата им воля е слаба“, пише Улф. 

Във вакуума се раждат и чудовища 

За Съединените щати десетилетието след края на Студената война е период на спокойствие и успех, но и на затвърждаване и осъзнаване на дълбоките културни промени. Успешното брандиране и проектиране на образа на „свободния свят“ в света след Втората световна война води до желание у много американци мечтата да се превърне в реалност.

Отражение на това са достигналите апогея си през 60-те и 70-те години движения за правата на жените, на работниците, на гей хората и на чернокожите. Тези движения водят до много съществени законови промени (американките могат да отворят своя собствена банкова сметка едва през 1974 г. например). Именно в такъв контекст контракултурата на 60-те и 70-те създава знакова музика, литература и изобщо изкуство, което бързо превзема света (и така до днес).

Всяка реакция има контрареакция: в случая с историята това са избирането на Ричард Никсън и Роналд Рейгън, през чиито мандати се наблюдава връщане на махалото към „традициите“ според широкото им разбиране; но след като гражданските свободи вече са придобити, тяхното ограничаване се оказва трудно. Поне засега. 

Всеки герой се нуждае от антигерой. Към края на 90-те години Близкият изток и Китай стават възможни злодеи по различни, понякога обективни причини. Но още преди атаките на 11 септември американските консервативни движения започват да виждат достоен враг вътре в самата държава – собствените си съграждани с различни политически и културни възгледи, които консерваторите смятат за пагубни за обществената тъкан. 

За какво всъщност се воюва? 

Към разговора за културните войни се присъединява и политологът Морис Фиорина от Станфорд. Той изтъква, че американската политическа система е мажоритарна – мнозинството (победителите) определя политики, които малцинството (загубилите) понася, но за сметка на това пазарната икономика дава свобода и многообразие на културата. Музиката, книгите и филмите, които се харесват на обществото например, може да не отговарят на представите на управляващото мнозинство (в САЩ редовно продължават опитите за забрана и канселиране на книги и друго изкуство). Резултатът е, че предпочитанията, моралните възгледи и вярванията на обикновените хора може да не получават непременно изражение в политическия живот, но със сигурност могат да бъдат разчетени в популярната култура и изведени от нея. 

„Политическият елит съвсем естествено вярва в собствената си важност, но тя е преувеличена“, смята Фиорина. Културните войни между елита могат да доведат до обща поляризация, казва още той, но по-вероятният резултат е хората просто да се отвратят от политиката още повече и да престанат да се интересуват от нея.

Освен това политологът подчертава, че културните войни често пренебрегват значението на по-традиционни разделителни линии, например икономическите: неравенствата и бедността, както и разликата във финансовото положение на демократичните и консервативните избиратели продължават да нарастват и да са основен фактор в американската политика. 

Културата почти винаги води до политика, но не и обратното, казва Фиорина. Придвижването на политиката вдясно и на културата вляво означава, че културните консерватори губят в по-важната битка, защото търсят политически решения на дълбоко културни проблеми. Какво е политическото решение на липсата на морал? На порнографията и вулгарността? На липсата на обноски и на емпатия? Разбира се, че тези въпроси нямат отговор, те нямат политически решения и ако консерваторите продължат да преследват такива, рано или късно ще се провалят. Политологът подчертава и че самите консервативни гласоподаватели са далеч от „традицията“: те сменят религията си (вицепрезидентът Джей Ди Ванс стана католик през 2019 г.), населеното си място, развеждат се, женят се отново (президентът Тръмп има три брака и множество документирани изневери) и т.н. 

Надеждата умира последна 

Културните войни са сигурен симптом за остра социална криза: пренареждане на политическите и финансовите слоеве, дълбоки промени в ценностите и в мисленето на обществата, загуба на сигурни структури (религия, държава) и страх от несигурното бъдеще. Две десетилетия по-късно дебатът на Улф и Хънтър е основополагащ за разбирането на реалността, в която живее Америка – и като резултат светът, включително България, тъй като, подобно на всичко останало, културните войни също са предмет на износ и на експлоатация от източници на дезинформация. 

Въпрос е и доколко културните войни отразяват мисленето на американците извън конкретните казуси, около които се разиграват.

Редица проучвания показват, че американците всъщност изразяват съгласие по множество важни проблеми, като здравеопазването, неравенствата и престрелките в училищата например.

Несъгласията идват тогава, когато започне търсенето на решения, и често се експлоатират за политически ползи. Фактът, че републиканците в момента управляват и трите клона на изпълнителната и законодателната власт – Конгреса, Камарата на представителите и президентството, както и че Върховният съд има консервативно мнозинство, все още не е довел до „Великата Америка“, която бе обещана. Напротив, основните проблеми остават същите (както ще разискваме по-подробно в следващия брой). Въпреки пропагандата, въпреки насилието, въпреки невярната информация, реалността си остава същата – както винаги се случва. 

Накрая Улф и Хънтър постигат съгласие поне за едно: ако има разлики между американците, те са политически, не културни или религиозни. Американците ценят едни и същи основни ценности – толерантност, плурализъм и индивидуалност.

Надеждата е – казва Улф – да бъде постигнато надграждане върху този консенсус между обикновените хора като противоотрова за екстремизма, който характеризира толкова голяма част от управляващия елит. 

И двамата смятат за най-важно, че американците все още вярват в значимостта на демокрацията. Несъгласията са породени от същината ѝ – здравата демокрация по условие дава пространство за различия и несъгласия. Това, разбира се, са думи от отминало десетилетие. Работата по уронването на вярата в демократичната държава тече усилено. Дали основите ще устоят, е въпрос, който всички си задаваме поне веднъж седмично. 

The collective thoughts of the interwebz