Keeping your data lake clean and compliant with Amazon Athena

Post Syndicated from David Roberts original https://aws.amazon.com/blogs/big-data/keeping-your-data-lake-clean-and-compliant-with-amazon-athena/

With the introduction of CTAS support for Amazon Athena (see Use CTAS statements with Amazon Athena to reduce cost and improve performance), you can not only query but also create tables using Athena with the associated data objects stored in Amazon Simple Storage Service (Amazon S3). These tables are often temporary in nature and used to filter or aggregate data that already exists in another Athena table. Although this offers great flexibility to perform exploratory analytics, when tables are dropped, the underlying Amazon S3 data remains indefinitely. Over time, the accumulation of these objects can increase Amazon S3 costs, become administratively challenging to manage, and may inadvertently preserve data that should have been deleted for privacy or compliance reasons. Furthermore, the AWS Glue table entry is purged so there is no convenient way to trace back which Amazon S3 path was mapped to a deleted table.

This post shows how you can automate  deleting Amazon S3 objects associated with a table  after dropping it using Athena. AWS Glue is required to be the metadata store for Athena.

Overview of solution

The solution requires that the AWS Glue table record (database, table, Amazon S3 path) history is preserved outside of AWS Glue, because it’s removed immediately  after a table is dropped. Without this record, you can’t delete the associated Amazon S3 object entries after the fact.

When Athena CTAS statements  are issued, AWS Glue generates Amazon CloudWatch events that specify the database and table names. These events are available from Amazon EventBridge and can be used to trigger an AWS Lambda function (autoCleanS3) to fetch the new or updated Amazon S3 path from AWS Glue and write the database, table, and Amazon S3 path into an AWS Glue history table stored in Amazon DynamoDB (GlueHistoryDDB). When Athena drop table queries are detected, CloudWatch events are generated that trigger autoCleanS3 to look up the Amazon S3 path from GlueHistoryDDB and delete all related objects from Amazon S3.

Not all dropped tables should trigger Amazon S3 object deletion. For example, when you create a table using existing Amazon S3 data (not CTAS), it’s not advisable to automatically delete the associated Amazon S3 tables, because other analysts may have other tables referring to the same source data. For this reason, you must include a user-defined comment (--dropstore ) in the Athena drop table query to cause autoCleanS3 to purge the Amazon S3 objects.

Lastly, after objects are successfully deleted, the corresponding entry in GlueHistoryDDB  is updated for historical and audit purposes. The overall workflow is described in the following diagram.

The workflow contains the following steps:

  1. A user creates a table either via Athena or the AWS Glue console or API.
  2. AWS Glue generates a CloudWatch event, and an EventBridge rule triggers the Lambda function.
  3. The function creates an entry in DynamoDB containing a copy of the AWS Glue record and Amazon S3 path.
  4. The user drops the table from Athena, including the special comment --dropstore.
  5. The Lambda function fetches the dropped table entry from DynamoDB, including the Amazon S3 path.
  6. The function deletes data from the Amazon S3 path, including manifest files, and marks the DynamoDB entry as purged.

Walkthrough overview

To implement this solution, we complete the following steps:

  1. Create the required AWS Identity and Access Management (IAM) policy and role.
  2. Create the AWS Glue history DynamoDB table.
  3. Create the Lambda autoCleanS3 function.
  4. Create the EventBridge rules.
  5. Test the solution.

If you prefer to use a preconfigured CloudFormation template, launch one of the following stacks depending on your Region.

Region Launch Button
us-east-1 (N. Virginia)
us-west-2 (Oregon)
eu-west-1 (Ireland)

Prerequisites

Before implementing this solution, create an AWS Glue database and table with the data residing in  Amazon S3. Be sure your user has the necessary permissions to access Athena and  perform CTAS operations writing  in a sample Amazon S3 location.

For more information about building a data lake, see Build a Data Lake Foundation with AWS Glue and Amazon S3.

Creating an IAM policy and role

You need to first create the required IAM policy for the Lambda function role to use to query AWS Glue and write to DynamoDB.

  1. On the IAM console, choose Policies.
  2. Choose Create policy.
  3. On the JSON tab, enter the following code (update the Region, account ID, and S3 bucket accordingly, and the table name GlueHistoryDDB if you choose to change it):
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": [
                    "s3:GetObject",
                    "s3:ListBucket",
                    "s3:ListObjectsV2",
                    "s3:DeleteObjectVersion",
                    "s3:DeleteObject"
                ],
                "Resource": [
                    "arn:aws:s3:::<athena-query-results-s3-bucket>",
                    "arn:aws:s3:::<athena-query-results-s3-bucket>/*"
                ],
                "Effect": "Allow"
            },
            {
                "Action": [
                    "dynamodb:PutItem",
                    "dynamodb:Scan",
                    "dynamodb:Query",
                    "dynamodb:UpdateItem"
                ],
                "Resource": [
                    "arn:aws:dynamodb:<region>:<accountId>:table/GlueHistoryDDB"
                ],
                "Effect": "Allow"
            },
            {
                "Action": [
                    "glue:GetTable"
                ],
                "Resource": [
                    "arn:aws:glue:<region>:<accountId>:catalog",
                    "arn:aws:glue:<region>:<accountId>:database/*",
                    "arn:aws:glue:<region>:<accountId>:table/*"
                ],
                "Effect": "Allow"
            },
            {
                "Action": [
                    "logs:CreateLogGroup"
                ],
                "Resource": [
                    "arn:aws:logs:<region>:<accountId>:*"
                ],
                "Effect": "Allow"
            },
            {
                "Action": [
                    "logs:CreateLogStream",
                    "logs:PutLogEvents",
                    "logs:DescribeLogStreams"
                ],
                "Resource": [
                    "arn:aws:logs:<region>:<accountId>:log-group:/aws/lambda/autoCleanS3:*"
                ],
                "Effect": "Allow"
            }
        ]
    }

  1. Choose Review policy.
  2. For Name, enter autoCleanS3-LambdaPolicy.
  3. For Description, enter Policy used by Lambda role to purge S3 objects when an Amazon Athena table is dropped.
  4. Choose Create policy.

Next, you need to create an IAM role and attach this policy.

  1. On the IAM console, choose Roles.
  2. Choose Create role.
  3. Choose AWS service.
  4. Choose Lambda.
  5. Choose Next: Permissions.

  1. For Filter policies, enter autoCleanS3-LambdaPolicy.
  2. Choose Next: Tags.
  3. Choose Next: Review.
  4. For Role name, enter autoCleanS3-LambdaRole.
  5. For Description, enter Role used by Lambda to purge S3 objects when an Amazon Athena table is dropped.
  6. Choose Create role.

Creating the AWS Glue history DynamoDB table

You use this DynamoDB table to hold the current and historical list of AWS Glue tables and their corresponding Amazon S3 path. Create the table as follows:

  1. On the DynamoDB console, choose Dashboard.
  2. Choose Create table.
  3. For Table name, enter GlueHistoryDDB.
  4. For Partition key, enter database (leave type as String).
  5. Select Add sort key.
  6. Enter table_date (leave type as String).
  7. For Table settings, select Use default settings.
  8. Choose Create.

The following table summarizes the GlueHistoryDDB table attributes that the Lambda function creates.

Column Type Description
database partition key The name of the AWS Glue database.
table_date sort key A composite attribute of AWS Glue table name plus date created. Because the same database and table name can be created again, the date must be used to ensure uniqueness.
created_by attribute The user or Amazon EC2 instance ARN from which the table was created.
owner attribute The owner of the table or account number.
purged attribute A boolean indicating whether the Amazon S3 objects have been deleted (True/False).
s3_path attribute The Amazon S3 path containing objects associated with the table.
table attribute The AWS Glue table name.
update_time attribute The last time the table was updated (the Amazon S3 path changed or objects purged).
view_sql attribute The view DDL if a view was created.

Creating the Lambda function autoCleanS3

A CloudWatch event triggers the Lambda function autoCleanS3 when a new table is created, updated, or dropped. If the --dropstore keyword is included in the Athena query comments, the associated Amazon S3 objects are also removed.

  1. On the Lambda console, choose Create function.
  2. Select Author from scratch.
  3. For Function name¸ enter autoCleanS3.
  4. For Runtime, choose Python 3.8.
  5. Under Permissions, for Execution role, select Use an existing role.
  6. Choose the role you created (service-role/autoCleanS3-LambdaRole).
  7. Choose Create function.
  8. Scroll down to the Function code section.
  9. If using Region us-west-2, on the Actions menu, choose Upload a file to Amazon S3.

  1. Enter the following:
    https://aws-bigdata-blog.s3.amazonaws.com/artifacts/aws-blog-keep-your-data-lake-clean-and-compliant-with-amazon-athena/autoCleanS3.zip

  2. Choose Save.

If using a Region other than us-west-2, download the Lambda .zip file locally. Then choose Upload a .zip file and choose the file from your computer to upload the Lambda function.

  1. In the Environment variables section, choose Edit.
  2. Choose Add environment variable.
  3. Enter the following key-values in the following table (customize as desired):
Key Value Purpose
Athena_SQL_Drop_Phrase --dropstore String to embed in Athena drop table queries to cause associated Amazon S3 objects to be removed
db_list

Comma-separated regex filter

<.*>

Allows you to limit which databases may contain tables that autoCleanS3 is allowed to purge
ddb_history_table GlueHistoryDDB The name of the AWS Glue history DynamoDB table
disable_s3_cleanup False If set to True, it disables the Amazon S3 purge, still recording attempts in the history table
log_level INFO Set to DEBUG to troubleshoot if needed

You must use a standard regex expression, which can be a simple comma-separated list of the AWS Glue databases that you want autoCleanS3 to evaluate.

 The following table shows example patterns for db_list.

Example Regex Pattern Result
.* Default, includes all databases
clickstream_web, orders_web, default Includes only clickstream_web, orders_web, default
.*_web Includes all databases having names ending in _web
.*stream.* Includes all databases containing stream in their name

For a complete list or supported patterns, see https://docs.python.org/3/library/re.html#re.Pattern.match

  1. Choose Save.

Creating EventBridge rules

You need to create EventBridge rules that invoke your Lambda function whenever Athena query events and AWS Glue CreateTable and UpdateTable events are generated.

Creating the Athena event rule

To create the Athena query event rule, complete the following steps:

  1. On the EventBridge console, choose Create rule.
  2. For Name, enter autoCleanS3-AthenaQueryEvent.
  3. For Description, enter Amazon Athena event for any query to trigger autoCleanS3.
  4. For Define pattern, choose Event pattern.
  5. For Event matching pattern, choose Custom pattern.
  6. For Event pattern, enter the following:
    {
    	"detail-type": [
    		"AWS API Call via CloudTrail"
    	],
    	"source": [
    		"aws.athena"
    	],
    	"detail": {
    		"eventName": [
    			"StartQueryExecution"
    		]
    	}
    }

  1. Choose Save.
  2. For Select targets, choose Lambda function.
  3. For Function¸ choose autoClean3.
  4. Choose Create.

Creating the AWS Glue event rule

To create the AWS Glue table event  rule, complete the following steps:

  1. On the EventBridge console, choose Create rule.
  2. For Name, enter autoCleanS3-GlueTableEvent.
  3. For Description, enter AWS Glue event for any table creation or update to trigger autoCleanS3.
  4. For Define pattern, choose Event pattern.
  5. For Event matching pattern, choose Custom pattern.
  6. For Event pattern, enter the following:
    {
    	"detail-type": [
    		"Glue Data Catalog Database State Change"
    	],
    	"source": [
    		"aws.glue"
    	],
    	"detail": {
    		"typeOfChange": [
    			"CreateTable",
    			"UpdateTable"
    		]
    	}
    }

  1. Choose Save.
  2. For Select targets, choose Lambda function.
  3. For Function¸ choose autoClean3.
  4. Choose Create.

You’re finished!

Testing the solution

Make sure you already have a data lake with tables defined in your AWS Glue Data Catalog and permission to access Athena. For this post, we use NYC taxi ride data. For more information, see Build a Data Lake Foundation with AWS Glue and Amazon S3.

  1. Create a new table using Athena CTAS.

Next, verify that the entry appears in the new GlueHistoryDDB table.

  1. On the DynamoDB console, open the GlueHistoryDDB table.
  2. Choose Items.
  3. Confirm the s3_path value for the table.

You can also view  the Amazon S3 table path and objects associated with the table.

  1. On the Amazon S3 console, navigate to the s3_path found in GlueHistoryDDB.
  2. Confirm the table and path containing the data folder and associated manifest and metadata objects.

  1. Drop the table using the keyword --dropstore.

  1. Check the Amazon S3 path to verify both the table folder and associated manifest and metadata files have been removed.

You can also see the purged attribute for the entry in GlueHistoryDDB is now set to True, and update_time has been updated, which you can use if you ever need to look back and understand when a purge event occurred.

Considerations

The Lambda timeout may need to be increased for very large tables, because the object deletion operations may not complete in time.

To prevent accidental data deletion, it’s recommended to carefully limit which databases may participate (Lambda environment variable db_list) and to enable versioning on the Athena bucket path and set up Amazon S3 lifecycle policies to eventually remove older versions. For more information, see Deleting object versions. 

Conclusion

In this post, we demonstrated how to automate the process of  deleting Amazon S3 objects associated with dropped AWS Glue tables. Deleting Amazon S3 objects that are no longer associated with an AWS Glue table reduces ongoing storage expense, management overhead, and unnecessary exposure of potentially private data no longer needed within the organization, allowing you to meet regulatory requirements.

This serverless solution monitors Athena and AWS Glue table creation and drop events via CloudWatch, and triggers Lambda to perform Amazon S3 object deletion. We use DynamoDB to store the audit history of all AWS Glue tables that have been dropped over time. It’s strongly recommended to enable Amazon S3 bucket versioning to prevent accidental data deletion.

To restore the Amazon S3 objects for the deleted table, you first identify the s3_path value for the relevant table entry in GlueHistoryDDB and either copy or remove the delete marker from objects in that path. For more information, see How do I undelete a deleted S3 object?


About the Author

David Roberts is a Senior Solutions Architect at AWS. His passion is building efficient and effective solutions on the cloud, especially involving analytics and data lake governance. Besides spending time with his wife and two daughters, he likes drumming and watching movies, and is an avid video gamer.

Auditing, inspecting, and visualizing Amazon Athena usage and cost

Post Syndicated from Kalyan Janaki original https://aws.amazon.com/blogs/big-data/auditing-inspecting-and-visualizing-amazon-athena-usage-and-cost/

Amazon Athena is an interactive query service that makes it easy to analyze data directly in Amazon Simple Storage Service (Amazon S3) using standard SQL. It’s a serverless platform with no need to set up or manage infrastructure. Athena scales automatically—running queries in parallel—so results are fast, even with large datasets and complex queries. You pay only for the queries that you run and the charges are based on the amount of data scanned by each query. You’re not charged for data definition language (DDL) statements like CREATE, ALTER, or DROP TABLE, statements for managing partitions, or failed queries. Cancelled queries are charged based on the amount of data scanned.

Typically, multiple users within an organization operate under different Athena workgroups and query various datasets in Amazon S3. In such cases, it’s beneficial to monitor Athena usage to ensure cost-effectiveness, avoid any performance bottlenecks, and adhere to security best practices. As a result, it’s desirable to have metrics that provide the following details:

  • Amount of data scanned by individual users
  • Amount of data scanned by different workgroups
  • Repetitive queries run by individual users
  • Slow-running queries
  • Most expensive queries

In this post, we provide a solution that collects detailed statistics of every query run in Athena and stores it in your data lake for auditing. We also demonstrate how to visualize audit data collected for a few key metrics (data scanned per workgroup and data scanned per user) using Amazon QuickSight.

Solution overview

The following diagram illustrates our solution architecture.

The solution consists of the following high-level steps:

  1. We use an Amazon CloudWatch Events rule with the following event pattern to trigger an AWS Lambda function for every Athena query run:
    {
    "detail-type": [
    "Athena Query State Change"
    ],
    "source": [
    "aws.athena"
    ],
    "detail": {
    "currentState": [
    "SUCCEEDED",
    "FAILED",
    "CANCELED"
    ]
    }
    }

  1. The Lambda function queries the Athena API to get details about the query and publishes them to Amazon Kinesis Data Firehose.
  2. Kinesis Data Firehose batches the data and writes it to Amazon S3.
  3. We use a second CloudWatch event rule with the following event pattern to trigger another Lambda function for every Athena query being run:
    {
    "detail-type": [
    "AWS API Call via CloudTrail"
    ],
    "source": [
    "aws.athena"
    ],
    "detail": {
    "eventName": [
    "StartQueryExecution"
    ]
    }
    }

  1. The Lambda function extracts AWS Identity and Access Management (IAM) user details from the query and publishes them to Kinesis Data Firehose.
  2. Kinesis Data Firehose batches the data and writes it to Amazon S3.
  3. We create and schedule an AWS Glue crawler to crawl the data written by Kinesis Data Firehose in the previous steps to create and update the Data Catalog tables. The following code is the table schemas the crawler creates:
    CREATE EXTERNAL TABLE `athena_query_details`(
      `query_execution_id` string, 
      `query` string, 
      `workgroup` string, 
      `state` string, 
      `data_scanned_bytes` bigint, 
      `execution_time_millis` int, 
      `planning_time_millis` int, 
      `queryqueue_time_millis` int, 
      `service_processing_time_millis` int)
    ROW FORMAT SERDE 
      'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
    STORED AS INPUTFORMAT 
      'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
    OUTPUTFORMAT 
      'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
    LOCATION
      's3://<S3location>/athena-query-details/'
    TBLPROPERTIES (
      'parquet.compression'='SNAPPY')
    
    CREATE EXTERNAL TABLE `athena_user_access_details`(
      `query_execution_id` string, 
      `account` string, 
      `region` string, 
      `user_detail` string, 
      `source_ip` string, 
      `event_time` string)
    ROW FORMAT SERDE 
      'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
    STORED AS INPUTFORMAT 
      'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
    OUTPUTFORMAT 
      'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
    LOCATION
      's3://<S3location>/athena-user-access-details/'
    TBLPROPERTIES (
      'parquet.compression'='SNAPPY')

  1. Athena stores a detailed history of the queries run in the last 30 days.
  2. The solution deploys a Lambda function that queries AWS CloudTrail to get list of Athena queries run in the last 30 days and publishes the details to the Kinesis Data Firehose streams created in the previous steps. The historical event processor function only needs to run one time after deploying the solution using the provided AWS CloudFormation
  3. We use the data available in the tables athena_query_details and athena_user_access_details in QuickSight to build insights and create visual dashboards.

Setting up your resources

Click on the Launch Stack button to deploy the solution in your account.

After you deploy the CloudFormation template, manually invoke the athena_historicalquery_events_processor Lambda function. This step processes the Athena queries that ran before deploying this solution; you only need to perform this step one time. 

Reporting using QuickSight dashboards

In this section, we cover the steps to create QuickSight dashboards based on the athena_query_details and athena_user_access_details Athena tables. The first step is to create a dataset with the athena_audit_db database, which the CloudFormation template created.

  1. On the QuickSight console, choose Datasets.
  2. Choose New dataset.

  1. For Create a Data Set, choose Athena.

 

  1. For Data source name, enter a name (for example, Athena_Audit).
  2. For Athena workgroup, keep at its default [primary].
  3. Choose Create data source.

  1. In the Choose your table section, choose athena_audit_db.
  2. Choose Use custom SQL.

  1. Enter a name for your custom SQL (for example, Custom-SQL-Athena-Audit).
  2. Enter the following SQL query:
    SELECT a.query_execution_id, a.query, a.state, a.data_scanned_bytes, a.execution_time_millis, b.user_detail
    FROM "athena_audit_db"."athena_query_details" AS a FULL JOIN  "athena_audit_db"."athena_user_access_details" AS b
    ON a.query_execution_id=b.query_execution_id
    WHERE CAST(a.data_scanned_bytes AS DECIMAL) > 0

  1. Choose Confirm query.

This query does a full join between the athena_query_details and athena_user_access_details tables.

  1. Select Import to SPICE for quicker analytics.
  2. Choose Edit/Preview data.

  1. Confirm that the data_scanned_bytes and execution_time_millis column data type is set to Decimal.
  2. Choose Save & visualize.

We’re now ready to create visuals in QuickSight. For this post, we create the following visuals:

  • Data scanned per query
  • Data scanned per user 

Data scanned per query

To configure the chart for our first visual, complete the following steps:

  1. For Visual types, choose Horizontal bar chart.
  2. For Y axis¸ choose query_execution_id.
  3. For Value, chose data_scanned_bytes.
  4. For Group/Color, choose query.

If you’re interested in determining the total runtime of the queries, you can use execution_time_milis instead of data_scanned_bytes.

The following screenshot shows our visualization.

 

If you hover over one of the rows in the chart, the pop-out detail shows the Athena query execution ID, Athena query that ran, and the data scanned by the query in bytes.

Data scanned per user

To configure the chart for our second visual, complete the following steps:

  1. For Visual types, choose Horizontal bar chart.
  2. For Y axis, choose query_execution_id
  3. For Value, choose data_scanned_bytes.
  4. For Group/Color, choose user_details.

You can use execution_time_millis instead of data_scanned_bytes if you’re interested in determining the total runtime of the queries.

The following screenshot shows our visualization.

If you hover over one of the rows in the chart, the pop-out detail shows the Athena query execution ID, the IAM principal that ran the query, and the data scanned by the query in bytes. 

Conclusion

This solution queries CloudTrail for Athena query activity in the last 30 days and uses CloudWatch rules to capture statistics for future Athena queries. Furthermore, the solution uses the GetQueryExecution API to provide details about the amount of data scanned, which provides information about per-query costs and how many queries are run per user. This enables you to further understand how your organization is using Athena.

You can further improve upon this architecture by using a partitioning strategy. Instead of writing all query metrics as .csv files to one S3 bucket folder, you can partition the data using year, month, and day partition keys. This allows you to query data by year, month, or day. For more information about partitioning strategies, see Partitioning Data.

For more information about improving Athena performance, see Top 10 Performance Tuning Tips for Amazon Athena.


About the Authors

Kalyan Janaki is Senior Technical Account Manager with AWS. Kalyan enjoys working with customers and helping them migrate their workloads to the cloud. In his spare time, he tries to keep up with his 2-year-old.

 

 

 

Kapil Shardha is an AWS Solutions Architect and supports enterprise customers with their AWS adoption. He has background in infrastructure automation and DevOps.

 

 

 

Aravind Singirikonda is a Solutions Architect at Amazon Web Services. He works with AWS Enterprise customers to provide guidance and technical assistance, helping them improve the value of their solutions when using AWS.

re:Invent 2020 – Your guide to AWS Identity and Data Protection sessions

Post Syndicated from Marta Taggart original https://aws.amazon.com/blogs/security/reinvent-2020-your-guide-to-aws-identity-and-data-protection-sessions/

AWS re:Invent will certainly be different in 2020! Instead of seeing you all in Las Vegas, this year re:Invent will be a free, three-week virtual conference. One thing that will remain the same is the variety of sessions, including many Security, Identity, and Compliance sessions. As we developed sessions, we looked to customers—asking where they would like to expand their knowledge. One way we did this was shared in a recent Security blog post, where we introduced a new customer polling feature that provides us with feedback directly from customers. The initial results of the poll showed that Identity and Access Management and Data Protection are top-ranking topics for customers. We wanted to highlight some of the re:Invent sessions for these two important topics so that you can start building your re:Invent schedule. Each session is offered at multiple times, so you can sign up for the time that works best for your location and schedule.

Managing your Identities and Access in AWS

AWS identity: Secure account and application access with AWS SSO
Ron Cully, Principal Product Manager, AWS

Dec 1, 2020 | 12:00 PM – 12:30 PM PST
Dec 1, 2020 | 8:00 PM – 8:30 PM PST
Dec 2, 2020 | 4:00 AM – 4:30 AM PST

AWS SSO provides an easy way to centrally manage access at scale across all your AWS Organizations accounts, using identities you create and manage in AWS SSO, Microsoft Active Directory, or external identity providers (such as Okta Universal Directory or Azure AD). This session explains how you can use AWS SSO to manage your AWS environment, and it covers key new features to help you secure and automate account access authorization.

Getting started with AWS identity services
Becky Weiss, Senior Principal Engineer, AWS

Dec 1, 2020 | 1:30 PM – 2:00 PM PST
Dec 1, 2020 | 9:30 PM – 10:00 PM PST
Dec 2, 2020 | 5:30 AM – 6:00 AM PST

The number, range, and breadth of AWS services are large, but the set of techniques that you need to secure them is not. Your journey as a builder in the cloud starts with this session, in which practical examples help you quickly get up to speed on the fundamentals of becoming authenticated and authorized in the cloud, as well as on securing your resources and data correctly.

AWS identity: Ten identity health checks to improve security in the cloud
Cassia Martin, Senior Security Solutions Architect, AWS

Dec 2, 2020 | 9:30 AM – 10:00 AM PST
Dec 2, 2020 | 5:30 PM – 6:00 PM PST
Dec 3, 2020 | 1:30 AM – 2:00 AM PST

Get practical advice and code to help you achieve the principle of least privilege in your existing AWS environment. From enabling logs to disabling root, the provided checklist helps you find and fix permissions issues in your resources, your accounts, and throughout your organization. With these ten health checks, you can improve your AWS identity and achieve better security every day.

AWS identity: Choosing the right mix of AWS IAM policies for scale
Josh Du Lac, Principal Security Solutions Architect, AWS

Dec 2, 2020 | 11:00 AM – 11:30 AM PST
Dec 2, 2020 | 7:00 PM – 7:30 PM PST
Dec 3, 2020 | 3:00 AM – 3:30 AM PST

This session provides both a strategic and tactical overview of various AWS Identity and Access Management (IAM) policies that provide a range of capabilities for the security of your AWS accounts. You probably already use a number of these policies today, but this session will dive into the tactical reasons for choosing one capability over another. This session zooms out to help you understand how to manage these IAM policies across a multi-account environment, covering their purpose, deployment, validation, limitations, monitoring, and more.

Zero Trust: An AWS perspective
Quint Van Deman, Principal WW Identity Specialist, AWS

Dec 2, 2020 | 12:30 PM – 1:00 PM PST
Dec 2, 2020 | 8:30 PM – 9:00 PM PST
Dec 3, 2020 | 4:30 AM – 5:00 AM PST

AWS customers have continuously asked, “What are the optimal patterns for ensuring the right levels of security and availability for my systems and data?” Increasingly, they are asking how patterns that fall under the banner of Zero Trust might apply to this question. In this session, you learn about the AWS guiding principles for Zero Trust and explore the larger subdomains that have emerged within this space. Then the session dives deep into how AWS has incorporated some of these concepts, and how AWS can help you on your own Zero Trust journey.

AWS identity: Next-generation permission management
Brigid Johnson, Senior Software Development Manager, AWS

Dec 3, 2020 | 11:00 AM – 11:30 AM PST
Dec 3, 2020 | 7:00 PM – 7:30 PM PST
Dec 4, 2020 | 3:00 AM – 3:30 AM PST

This session is for central security teams and developers who manage application permissions. This session reviews a permissions model that enables you to scale your permissions management with confidence. Learn how to set your organization up for access management success with permission guardrails. Then, learn about granting workforce permissions based on attributes, so they scale as your users and teams adjust. Finally, learn about the access analysis tools and how to use them to identify and reduce broad permissions and give users and systems access to only what they need.

How Goldman Sachs administers temporary elevated AWS access
Harsha Sharma, Solutions Architect, AWS
Chana Garbow Pardes, Associate, Goldman Sachs
Jewel Brown, Analyst, Goldman Sachs

Dec 16, 2020 | 2:00 PM – 2:30 PM PST
Dec 16, 2020 | 10:00 PM – 10:30 PM PST
Dec 17, 2020 | 6:00 AM – 6:30 AM PST

Goldman Sachs takes security and access to AWS accounts seriously. While empowering teams with the freedom to build applications autonomously is critical for scaling cloud usage across the firm, guardrails and controls need to be set in place to enable secure administrative access. In this session, learn how the company built its credential brokering workflow and administrator access for its users. Learn how, with its simple application that uses proprietary and AWS services, including Amazon DynamoDB, AWS Lambda, AWS CloudTrail, Amazon S3, and Amazon Athena, Goldman Sachs is able to control administrator credentials and monitor and report on actions taken for audits and compliance.

Data Protection

Do you need an AWS KMS custom key store?
Tracy Pierce, Senior Consultant, AWS

Dec 15, 2020 | 9:45 AM – 10:15 AM PST
Dec 15, 2020 | 5:45 PM – 6:15 PM PST
Dec 16, 2020 | 1:45 AM – 2:15 AM PST

AWS Key Management Service (AWS KMS) has integrated with AWS CloudHSM, giving you the option to create your own AWS KMS custom key store. In this session, you learn more about how a KMS custom key store is backed by an AWS CloudHSM cluster and how it enables you to generate, store, and use your KMS keys in the hardware security modules that you control. You also learn when and if you really need a custom key store. Join this session to learn why you might choose not to use a custom key store and instead use the AWS KMS default.

Using certificate-based authentication on containers & web servers on AWS
Josh Rosenthol, Senior Product Manager, AWS
Kevin Rioles, Manager, Infrastructure & Security, BlackSky

Dec 8, 2020 | 12:45 PM – 1:15 PM PST
Dec 8, 2020 | 8:45 PM – 9:15 PM PST
Dec 9, 2020 | 4:45 AM – 5:15 AM PST

In this session, BlackSky talks about its experience using AWS Certificate Manager (ACM) end-entity certificates for the processing and distribution of real-time satellite geospatial intelligence and monitoring. Learn how BlackSky uses certificate-based authentication on containers and web servers within its AWS environment to help make TLS ubiquitous in its deployments. The session details the implementation, architecture, and operations best practices that the company chose and how it was able to operate ACM at scale across multiple accounts and regions.

The busy manager’s guide to encryption
Spencer Janyk, Senior Product Manager, AWS

Dec 9, 2020 | 11:45 AM – 12:15 PM PST
Dec 9, 2020 | 7:45 PM – 8:15 PM PST
Dec 10, 2020 | 3:45 AM – 4:15 AM PST

In this session, explore the functionality of AWS cryptography services and learn when and where to deploy each of the following: AWS Key Management Service, AWS Encryption SDK, AWS Certificate Manager, AWS CloudHSM, and AWS Secrets Manager. You also learn about defense-in-depth strategies including asymmetric permissions models, client-side encryption, and permission segmentation by role.

Building post-quantum cryptography for the cloud
Alex Weibel, Senior Software Development Engineer, AWS

Dec 15, 2020 | 12:45 PM – 1:15 PM PST
Dec 15, 2020 | 8:45 PM – 9:15 PM PST
Dec 16, 2020 | 4:45 AM – 5:15 AM PST

This session introduces post-quantum cryptography and how you can use it today to secure TLS communication. Learn about recent updates on standards and existing deployments, including the AWS post-quantum TLS implementation (pq-s2n). A description of the hybrid key agreement method shows how you can combine a new post-quantum key encapsulation method with a classical key exchange to secure network traffic today.

Data protection at scale using Amazon Macie
Neel Sendas, Senior Technical Account Manager, AWS

Dec 17, 2020 | 7:15 AM – 7:45 AM PST
Dec 17, 2020 | 3:15 PM – 3:45 PM PST
Dec 17, 2020 | 11:15 PM – 11:45 PM PST

Data Loss Prevention (DLP) is a common topic among companies that work with sensitive data. If an organization can’t identify its sensitive data, it can’t protect it. Amazon Macie is a fully managed data security and data privacy service that uses machine learning and pattern matching to discover and protect your sensitive data in AWS. In this session, we will share details of the design and architecture you can use to deploy Macie at large scale.

While sessions are virtual this year, they will be offered at multiple times with live moderators and “Ask the Expert” sessions available to help answer any questions that you may have. We look forward to “seeing” you in these sessions. Please see the re:Invent agenda for more details and to build your schedule.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Marta Taggart

Marta is a Seattle-native and Senior Program Manager in AWS Security, where she focuses on privacy, content development, and educational programs. Her interest in education stems from two years she spent in the education sector while serving in the Peace Corps in Romania. In her free time, she’s on a global hunt for the perfect cup of coffee.

Author

Himanshu Verma

Himanshu is a Worldwide Specialist for AWS Security Services. In this role, he leads the go-to-market creation and execution for AWS Data Protection and Threat Detection & Monitoring services, field enablement, and strategic customer advisement. Prior to AWS, he held roles as Director of Product Management, engineering and development, working on various identity, information security and data protection technologies.

AWS On Air – re:Invent Weekly Streaming Schedule

Post Syndicated from Nicholas Walsh original https://aws.amazon.com/blogs/aws/reinvent-2020-streaming-schedule/

Last updated: 11:00 am (PST), November 30

Join AWS On Air throughout re:Invent (Dec 1 – Dec 17) for daily livestreams with news, announcements, demos, and interviews with experts across industry and technology. To get started, head over to register for re:Invent. Then, after Andy Jassy’s keynote (Tuesday, Dec 1 at 8-11 am PST) check back here for the latest livestreams and where to tune-in.

Time (PST) Tuesday 12/1 Wednesday 12/2 Thursday (12/3) 12/3
12:00 AM
1:00 AM
2:00 AM Daily Recap (Italian) Daily Recap (Italian)
3:00 AM Daily Recap (German) Daily Recap (German)
4:00 AM Daily Recap (French) Daily Recap (French)
5:00 AM
6:00 AM Daily Recap
(Portuguese)
7:00 AM Daily Recap (Spanish)
8:00 AM
9:00 AM
9:30 AM
10:00 AM AWS What’s Next AWS What’s Next
10:30 AM AWS What’s Next AWS What’s Next
11:00 AM Voice of the Customer AWS What’s Next
11:30 AM Keynoteworthy Voice of the Customer Keynoteworthy
12:00 PM
12:30 PM
1:00 PM Industry Live Session – Energy AWS What’s Next
1:30 PM
2:00 PM AWS What’s Next AWS What’s Next AWS What’s Next
2:30 PM AWS What’s Next AWS What’s Next AWS What’s Next
3:00 PM Howdy Partner Howdy Partner
3:30 PM This Is My
Architecture
All In The Field This Is My
Architecture
4:00 PM
4:30 PM AWS What’s Next
5:00 PM Daily Recap (English) Daily Recap (English) Daily Recap (English)
5:30 PM Certification Quiz
Show
Certification Quiz
Show
Certification Quiz
Show
6:00 PM Industry Live
Sessions
Industry Live
Sessions
6:30 PM
7:00 PM Daily Recap
(Japanese)
Daily Recap
(Japanese)
Daily Recap
(Japanese)
8:00 PM Daily Recap (Korean) Daily Recap (Korean) Daily Recap (Korean)
9:00 PM
10:00 PM Daily Recap
(Cantonese)
Daily Recap
(Cantonese)
Daily Recap
(Cantonese)
11:00 PM

Show synopses

AWS What’s Next. Dive deep on the latest launches from re:Invent with AWS Developer Advocates and members of the service teams. See demos and get your questions answered live during the show.

Keynoteworthy. Join hosts Robert Zhu and Nick Walsh after each re:Invent keynote as they chat in-depth on the launches and announcements.

AWS Community Voices. Join us each Thursday at 11:00AM (PST) during re:Invent to hear from AWS community leaders who will share their thoughts on re:Invent and answer your questions live!

Howdy Partner. Howdy Partner highlights AWS Partner Network (APN) Partners so you can build with new tools and meet the people behind the companies. Experts and newcomers alike can learn how AWS Partner solutions enable you to drive faster results and how to pick the right tool when you need it.

re:Invent Recaps. Tune in for daily and weekly recaps about all things re:Invent—the greatest launches, events, and more! Daily recaps are available Tuesday through Thursday in English and Wednesday through Friday in Japanese, Korean, Italian, Spanish, French, and Portuguese. Weekly recaps are available Thursday in English.

This Is My Architecture.Designed for a technical audience, this popular series highlights innovative architectural solutions from customers and AWS Partners. Our hosts, Adrian DeLuca, Aarthi Raju, and Boaz Ziniman, will showcase the most interesting and creative elements of each architecture. #thisismyarchitecture

All in the Field: AWS Agriculture Live. Our expert AgTech hosts Karen Hildebrand and Matt Wolff review innovative applications that bring food to your table using AWS technology. They are joined by industry guests who walk through solutions from under the soil to low-earth-orbit satellites. #allinthefield

IoT All the Things: Special Projects Edition. Join expert hosts Erin McGill and Tim Mattison as they showcase exploratory “side projects” and early stage use cases from guest solution architects. These episodes let developers and IT professionals at any level jump in and experiment with AWS services in a risk-free environment. #alltheexperiments

Certification Quiz Show. Test your AWS knowledge on our fun, interactive AWS Certification Quiz Show! Each episode covers a different area of AWS knowledge that is ideal for preparing for AWS Certification. We also deep-dive into how best to gain AWS skills and how to become AWS Certified.

AWS Industry Live. Join AWS Industry Live for a comprehensive look into 14 different industries. Attendees will get a chance to join industry experts for a year in review, a review of common use cases, and learning about customer success stories from 2020.

Voice of the Customer. Tune in for one-on-one interviews with AWS industry customers to learn about their AWS journey, the technology that powers their products, and the innovation they are bringing to their industry.

[$] Scheduling for asymmetric Arm systems

Post Syndicated from original https://lwn.net/Articles/838339/rss

The Arm processor architecture has pushed the boundaries in a number of
ways, some of which have required significant kernel changes in response.
For example, the big.LITTLE architecture
placed fast (but power-hungry) and slower (but more power-efficient) CPUs
in the same system-on-chip (SoC); significant scheduler changes were needed
for Linux to be able to properly distribute tasks on such systems. For all
their quirkiness, big.LITTLE systems still feature CPUs that are in some
sense identical: they can all run any task in the system. What is the
scheduler to do, though, if confronted with a system where that is no
longer true?

pip 20.3 release

Post Syndicated from original https://lwn.net/Articles/838580/rss

The Python Packaging Authority has announced the release of pip 20.3. There
is some potential for disruption with this release. “The new resolver is now *on by default*. It is significantly stricter
and more consistent when it receives incompatible instructions, and
reduces support for certain kinds of constraints files, so some
workarounds and workflows may break.

Security updates for Monday

Post Syndicated from original https://lwn.net/Articles/838579/rss

Security updates have been issued by Arch Linux (c-ares, libass, raptor, rclone, and swtpm), Debian (libproxy, qemu, tcpflow, and x11vnc), Fedora (asterisk, c-ares, microcode_ctl, moodle, pam, tcpdump, and webkit2gtk3), Mageia (jruby and webkit2), openSUSE (buildah, c-ares, ceph, fontforge, java-1_8_0-openjdk, kernel, LibVNCServer, mariadb, thunderbird, ucode-intel, and wireshark), Red Hat (firefox, rh-mariadb103-mariadb and rh-mariadb103-galera, and thunderbird), SUSE (binutils, libssh2_org, LibVNCServer, libX11, and nodejs12), and Ubuntu (mysql-8.0 and qemu).

Check Washing

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/11/check-washing.html

I can’t believe that check washing is still a thing:

“Check washing” is a practice where thieves break into mailboxes (or otherwise steal mail), find envelopes with checks, then use special solvents to remove the information on that check (except for the signature) and then change the payee and the amount to a bank account under their control so that it could be deposited at out-state-banks and oftentimes by a mobile phone.

The article suggests a solution: stop using paper checks.

Improving the Resiliency of Our Infrastructure DNS Zone

Post Syndicated from Ryan Timken original https://blog.cloudflare.com/improving-the-resiliency-of-our-infrastructure-dns-zone/

Improving the Resiliency of Our Infrastructure DNS Zone

In this blog post we will discuss how we made our infrastructure DNS zone more reliable by using multiple primary nameservers to leverage our own DNS product running on our edge as well as a third-party DNS provider.

Improving the Resiliency of Our Infrastructure DNS Zone

Authoritative Nameservers

You can think of an authoritative nameserver as the source of truth for the records of a given DNS zone. When a recursive resolver wants to look up a record, it will eventually need to talk to the authoritative nameserver(s) for the zone in question. If you’d like to read more on the topic, our learning center provides some additional information.

Here’s an example of our authoritative nameservers (replacing our actual domain with example.com):

~$ dig NS example.com +short
ns1.example.com.
ns2.example.com.
ns3.example.com.

As you can see, there are three nameservers listed. You’ll notice that the nameservers happen to reside in the same zone, but they don’t have to. Those three nameservers point to six anycasted IP addresses (3 x IPv4, 3 x IPv6) announced from our edge, comprising data centers from 200+ cities around the world.

The Problem

We store the hostnames for all of our machines, both the ones at the edge and the ones at core data centers, in a DNS zone we refer to as our infrastructure zone. By using our own DNS product to run our infrastructure zone, we get the reliability and performance of our Global Anycast Network. However, what would happen if those nameservers became unavailable due to an issue on our edge? Eventually DNS lookups would fail, as resolvers would not be able to connect to the only authoritative nameservers configured on the zone: the ones hosted on our edge. This is the main problem we set out to solve.

When an incident occurs, our engineering teams are busy investigating, debugging, and fixing the issue at hand. If they cannot resolve the hostnames of the infrastructure they need to use, it will lead to confusion and delays in resolving the incident.

Imagine you are part of a team tackling an incident. As you quickly begin to investigate, you try to connect to a specific machine to gather some debugging information, but you get a DNS resolution error. What now? You know you are using the right hostname. Is this a result of the incident at hand, some side effect, or is this completely unrelated? You need to keep investigating, so you try another way. Maybe you have memorized the IP address of the machine and you can connect. More likely, you ask another resolver which still has the answer in its cache and resolve the IP that way. One thing is certain, the extra “mini-debug” step costs you precious time and detracts from debugging the real root cause.

Unavailable nameservers and the problems they cause are not unique to Cloudflare, and are not specific to our use case. Even if we hosted our authoritative nameservers with a single external provider, they could also experience their own issues causing the nameservers to fail.

Within the DNS community it is always understood that the more diversity, the better. Some common methods include diversifying network/routing configurations and software choices between a standard primary/secondary setup. However, no matter how resilient the network or software stack is, a single authority is still responsible for the zone. Luckily, there are ways to solve this problem!

Our Solution: Multiple Primary Nameservers

Our solution was to set up our infrastructure zone with multiple primary nameservers. This type of setup is referred to as split authority, multi-primary, or primary/primary. This way, instead of using just one provider for our authoritative nameservers, we use two.

We added three nameservers from our additional provider to our zone at our registrar. Using multiple primaries allows changes to our zone at each provider, to be controlled separately and completely by us. Instead of using zone transfers to keep our zone in sync, we use OctoDNS to independently and simultaneously manage the zone at both providers. We’ll talk more about our use of OctoDNS in a bit.

This setup is similar to using a primary and secondary server. The main difference is that the nameservers operate independently from one another, and do not use the usual DNS AXFR/IXFR method to keep the zone up to date. If you’d like to learn more about this type of solution, here is a great blog post by Dina Kozlov, our Product Manager for DNS, about Secondary DNS.

The nameservers in our zone after adding an additional provider would look something like:

~$ dig NS example.com +short
ns1.example.com.
ns2.example.com.
ns3.example.com.
ns1.additional-provider.net.
ns2.additional-provider.net.
ns3.additional-provider.net.

Predictable Query Routing

Currently, we cannot coordinate which provider should be used when querying a record within the zone. Recursive resolvers have different methods of choosing which nameserver should be used when presented with multiple NS records. A popular choice is to use the server with the lowest RTT (round trip time). A great blog post from APNIC on recursive resolver authoritative nameserver selection can be consulted for a detailed explanation.

We needed to enforce specific routing decisions between the two authorities. Our requirement was for a weighted routing policy preferring Cloudflare based on availability checks for requests originating from our infrastructure servers. This reduces RTT, since the queries originate from the same servers hosting our nameservers in the same data center, and do not need to travel further to the external provider when all is well.

Our edge infrastructure servers are configured to use DNSDist as their primary system resolver. DNSDist load balances queries using multiple upstream recursive DNS servers (Unbound) in each data center to provide DNS resolution. This setup is used for internal DNS resolution only, and as such, it is independent from our authoritative DNS and public resolver 1.1.1.1 service.

Additionally, we modified our DNSDist configuration by adding two server pools for our infrastructure zone authoritative servers, and set up active checks with weighted routes to always use the Cloudflare pool when available. With the active checking and weighted routing in place, our queries are always routed internally when available. In the event of a Cloudflare authoritative DNS failure, DNSDist will route all requests for the zone to our external provider.

Maintaining Our Infrastructure DNS Zone

In addition to a more reliable infrastructure zone, we also wanted to further automate the provisioning of DNS records. We had been relying on an older manual tool that became quite slow handling our growing number of DNS records. In a nutshell, this tool queried our provisioning database to gather all of the machine names, and then created, deleted, or updated the required DNS records using the Cloudflare API. We had to run this tool whenever we provisioned or decommissioned  machines that serve our customers’ requests.

Part of the procedure for running this tool was to first run it in dry-run mode, and then paste the results for review in our team chat room. This review step ensured the changes the tool found were expected and safe to run, and it is something we want to keep as part of our plan to automate the process.

Here’s what the old tool looked like:

$ cf-provision update-example -l ${USER}@cloudflare.com -u
Running update-example.sh -t /var/tmp/cf-provision -l [email protected] -u
* Loading up possible records …

deleting: {"name":"node44.example.com","ttl":300, "type":"A","content":"192.0.2.2","proxied":false}
 rec_id:abcdefg
updating: { "name":"build-ts.example.com", "ttl":120, "type":"TXT", "content":"1596722274"} rec_id:123456 previous content: 1596712896

Result    : SUCCESS
Task      : BUILD
Dest dir  :
Started   : Thu, 06 Aug 2020 13:57:40 +0000
Finished  : Thu, 06 Aug 2020 13:58:16 +0000
Elapsed   : 36 secs
Records Changed In API  : 1 record(s) changed
Records Deleted In API  : 1 record(s) deleted

Zone Management with OctoDNS

As we mentioned earlier, when using a multi-primary setup for our infrastructure zone, we are required to maintain the zone data outside of traditional DNS replication. Before rolling out our own solution we wanted to see what was out there, and we stumbled upon OctoDNS, a project from GitHub. OctoDNS provides a set of tools that make it easy to manage your DNS records across multiple providers.

OctoDNS uses a pluggable architecture. This means we can rewrite our old script as a plugin (which is called a ‘source’), and use other existing provider plugins (called ‘providers’) to interact with both the Cloudflare and our other provider’s APIs. Should we decide to sync to more external DNS providers in the future, we would just need to add them to our OctoDNS configuration. This allows our records to stay up to date, and, as an added benefit, records OctoDNS doesn’t know about will be removed during operation (for example, changes made outside of OctoDNS). This ensures that manual changes do not diverge from what is present in the provisioning database.

Our goal was to keep the zone management workflow as simple as possible. At Cloudflare, we use TeamCity for CI/CD, and we realized that it could not only facilitate code builds of our OctoDNS implementation, but it could also be used to deploy the zone.

There are a number of benefits to using our existing TeamCity infrastructure.

  • Our DevTools team can reliably manage it as a service
  • It has granular permissions, which allow us to control who can deploy the changes
  • It provides storage of the logs for auditing
  • It allows easy rollback of zone revisions
  • It integrates easily with our chat ops workflow via Google Chat webhooks

Below is a high-level overview of how we manage our zone through OctoDNS.

Improving the Resiliency of Our Infrastructure DNS Zone

There are three steps in the workflow:

  1. Build – evaluate the sources and build the complete zone.
  2. Compare – parse the built zone and compare to the records on the providers. Changes found are sent to SRE for evaluation.
  3. Deploy – deploy the changes to the providers.

Step 1: Build

Sources
OctoDNS consumes data from our internal systems via custom source modules. So far, we have built two source modules for querying data:

  1. ProvAPI queries our internal provisioning API providing data center and node configuration.
  2. NetBox queries our internal NetBox deployment providing hardware metadata.

Additionally, static records are defined in a YAML file. These sources form the infrastructure zone source of truth.

Providers
The build process establishes a staging area per execution. The YAML provider builds a static YAML file containing the complete zone. The hosts file provider is used to generate an emergency hosts file for the zone. Contents from the staging area are revision controlled in CI, which allows us to easily deploy previous versions if required.

Improving the Resiliency of Our Infrastructure DNS Zone

Step 2: Compare

Following a successful zone build CI executes the compare build. During this phase, OctoDNS performs an octodns-sync in dry-run mode. The compare build consumes the staging YAML zone configuration, and compares the records against the records on our authoritative providers via their respective APIs. Any identified zone changes are parsed, and a summary line is generated and sent to the SRE Chat room for approval. SRE are automatically linked to the changes and associated CI build for deployment.

Improving the Resiliency of Our Infrastructure DNS Zone

Step 3: Deploy

The deployment CI build is access-controlled and scoped to the SRE group using our single sign-on provider. Following successful approval and peer review, an SRE can deploy the changes by executing the deploy build.

The deployment process is simple; consume the YAML zone data from our staging area and deploy the changes to the zone’s authoritative providers via ‘octodns-sync –doit’. The hosts file generated for the zone is packaged and deployed, to be used in the event of complete DNS failure.

Here’s an example of how the message looks. When the deploy is finished, the thread is updated to indicate which user initiated it.

Improving the Resiliency of Our Infrastructure DNS Zone

Future Improvements

In the future, we would like to automate the process further by reducing the need for approvals. There is usually no harm in adding new records, and it is done very often during the provisioning of new machines. Removing the need to approve those records would take out another step in the provisioning process, which is something we are always looking to optimize.

Introducing OctoDNS and an additional provider allowed us to make our infrastructure DNS zone more reliable and easier to manage. We can now easily include new sources of record data, with OctoDNS allowing us to focus more on new and exciting projects and less on managing DNS records.

Какво пропуснахме в мерките за Ковид 19 и защо няма да работят

Post Syndicated from VassilKendov original http://kendov.com/%D0%BA%D0%B0%D0%BA%D0%B2%D0%BE-%D0%BF%D1%80%D0%BE%D0%BF%D1%83%D1%81%D0%BD%D0%B0%D1%85%D0%BC%D0%B5-%D0%B2-%D0%BC%D0%B5%D1%80%D0%BA%D0%B8%D1%82%D0%B5-%D0%B7%D0%B0-%D0%BA%D0%BE%D0%B2%D0%B8%D0%B4-19/

Какво пропуснахме в мерките за Ковид-а и защо няма да работят

В изграждането на всяка система си има стъпки – 1-ва, 2-ра, 3-та… 5-та. В общи линии ние не изпълнихме стъпки от 1 до 4, а сега се опитваме да налагаме стъпка 5.
Аз съм застъпник на тезата, че не Ковид-а ни убива, а липсата на здравеопазване и адекватни мерки за справяне с пандемията.

А какви мерки бяха възможни и нормални?

Най-напред беше редно да се събере щаб от нормални и мислещи хора, а не калинки, който щаб да включва не само лекари, а хора от потенциални сфери, които биха били засегнати от бъдещи мерки – учители, дейци на културата, родителски организации, бизнеса, хотелиерите, транспорта, пенсионерски организации…

В момента имаме повече информация отколкото във времето, коато ген. Мутафчийски се хилише в ТВ предаванията и ни убеждаваше, че това е „просто един вирус”. После се обърна на 180 градуса, но това е нормално. Ненормално е, когато нямаш информация да правиш изводи.

Ето как би трябвало да протече една организация по подготовка за пандемия с минимални средства.

Продължава след рекламата
VIP услуга за фирми – онлайн консултация при проблемен кредит

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

2. На базата на получената информация, нашите учени трябваше да излязат със становище за най-ефективното лечение на заболяванията и единен протолкол. Този протокол да бъде предоставен на мин. на здравето, който да осигури логистиката, обученията на лекарите, организацията и необходимите запаси от лекарства.
Да бъде сведен протокола до GP-тата, които да минат кратък курс, симпозиум или онлайн обучение, но задълително всички да бъдат обучени. Да знаят не само лекарствата, а да са наясно:
– в кои болници има Ковид отделения
– кои лаборатории правт PCR тестове и кои лаборатории анти тела.
– Да са наясно какви документи и какви тестове ще се искат за постъпване в болница, колко струват и кой ги плаща.
– Най важното – как да се пазят те самите от Ковид-а?

А ние какво направихме – изолирахме GP-тата от процеса. Браво на Министерството.

Тук ключовият момент е ценовата политика по отношение на избраните лекарства и тестове
. Повечето хора не знаят, но цените на лекарствата са най-регулираните цени в страната. Всяко лекарство си има предела цена и методика за ценообразуване. Нищо не пречи да се промени наредбата за определен период за тези лекарства с цел да се избегне презапасяването.
С две думи ако го изпише лекар на рецепта – цена по НЗОК примерно 5 лева. Ако е за свободна продажба 105 лева. Щом искате презапасявайте се тогава. Ако нямалеят наличностите, министерството на здравето да има готовност да направи свободната продажба 505 лева (примерно)

Тук идва най-важната стъпка

При проблем с банка или кредит – заявете среща
[contact-form-7]

3. На базата на горните 2 правителството трябва да проведе консултации с посочените по-горе групи и да вземе решение за здравната политика, която ще следва.
– ще следваме шведския и английския модел, където това заболяване не се лекува в леките му форми.
– ще следваме китайския модел, в който се затварят градове или дърава за месец и всичко приключва.

Тук на помощ трябва да дойдат финансистите и тяхната дума трябва да е най-тежка.

Четох хубава статия от 2013 година, как по времето на управлението на ГЕРБ са закрити 17 болници. Болниците добре, но персонала какво мислите, че е направил? Като закриеш болницата в Белоградчик примерно (закрита е), ако персонала трябва да се мести за да упражнява професията си, изборът е Видин (на около 43 км), София (около 116 км.) или Мюнхен (колкото и да е, но при една не лоша заплата и гарантирано взимане на работа. Все пак си здравен работник по време на пандемия в Германия). Така и така се местиш, въпросът е къде. Мисля, че изборът се подразбира.

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

Щетите за икомониката също не са маловажни
, но те зависят от това кой модел ще се избере – Шведския или Китайския. И най-вече за кой модел държавата има ресурс. Защото всички искаме да влезем в болница ако се наложи, да ни приемат и лекуват компетентно, но като са закрити 17 болници, а персонал няма, тогава дали е възможен английския модел?
А ако затворим държавата, кой ще плаща заплатите на стоящите вкъщи и на затворените предприятия? Откъде?

От сегашната гледна точка и информация е по-лесно да се вземе такова решение, но Март 2020 нямахме тази информация, което прави изборът доста труден.

Така или иначе затова е избрано това правителство – за да взима решения. Ако са правилни – още по-добре, но това което направиха от Март 2020 до момента е направо… МАЛОУМНО. Китайски мерки за 30 болни на ден и шведски мерки за 3000 болни дневно.

Ето и още потенцилани въпроси и мерки, които би следвало да се обсъдят преди взимането на каквото и да било решение.

4. Заплащане на лекарите, мед. сестрите и санитарите на първа линия.
– Естествено е да дадеш СОЛИДНИ бонуси на тези, които са в ковид отделения или в бърза помощ. Няма да е вечно, но поне да е добре платено. Все пак те спасяват човешки животи. А ние какво направихме – мярка 60/40 за футболистите на Лудогорец. Какви животи спасяват те не знам, но явно са важни. Кръчмите с намаленото ДДС явно също са важни.

5. Времето от Март 2020 можеше да се иползва за скоростно обучение на санитари и мед. Сестри
, които да изпълняват поне някои операции. Казвам някои защото далеч не става за 3 месеца да създадеш квалифицирана мед. сестра, но поне адмистративните задължения (които не са малко), както и някои по-елементарни операции по взимане на кръв и проби за бързи тестове е напълно възможно. В последствие да помислиш за насочване към допълнителни курсове и програми за мед. сестри на тези полуобучени кадри с вече натрупан опит и практика. И без това има крещящ недостиг на такъв вид персонал. С един куршум два заека – справян с пандемията и реформа в здравеопазването.

Продължава след рекламата
VIP услуга за фирми – онлайн консултация при проблемен кредит.


6. Закупуване на линейки и стиковане на екипи за тях за работа 24 часа
. Една линейка знам, че струва около 120 000 лева (втора употреба – нали все гледаме да минем тънко). При закупуването само на 10 линейки, ще е възможно да се посещават 240 души в по-тежко състояние дневно. При добре обучен персонал и най-вече мед. сестри, докато докторът преглежда и обяснява, мед. сестрата ще може да оформи документите и да намери правилното място за пациента.
Естествено ще има доста спекулации от страна на пациентите и ще се викат линейки безпричинно, но това е положението. Приемаме го и го правим. Просто трябва да бъдат предупреждавани пациентите, че посещението влиза в регистър и последващ специализиран транспорт, свързан с това заболяване е за сметка на пациента. Логиката е като на „лъжливото овчарче”, но от народната мъдрост няма по-правилно решение.
Викнал си линейка, обърнато ти е внимание. Сега е пандемия и обръщаме внимание на следващите. Твоя един час ти е бил даден и всичките въпроси са ти отговорени. Ако си бил за болница ще те вземат и настанят. Ако не си бил за болница, значи грешно си преценил и си отнел възможността за преглед на някой друг. Оттук нататък има GP. Ако мед. сестрата е обучена както трябва, GP-то ще знае какво е било състоянието ти при прегледа и какво лечение ти е предписано. Вече си в ръцете на GP-то, което си избрал и от неговата компетентност и възможности зависи дали ще бъдеш приет в болница и коя болница.

7. Социалната страна на нещата. – Най-голямата глупост, която чух е, че ще се дават помощи на детегледачки за хора, които безработни. Тук искам да направя едно лирично отклонение – АБЕ ИДИОТИ С ИДИОТИТЕ ВИ, НАЛИ СА БЕЗРАБОТНИ И МОГАТ ДА СЕ ГРИЖАТ ЗА ДЕЦАТА СИ, КОГАТО НЕ СА НА УЧИЛИЩЕ?

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

8. Длъжни бяха управляващите през тези няколко месеца от март 2020 до момента да осигурят организация по обучение на деца, учители и родители да работят с програмите за дистанционно обучение. Длъжни бяха да преработят и програмите за такъв начин на обучение. Имаше време, а и ресурс за такава стъпка. Желание и организация обаче липсваше.

9. Възрастните хора – всички знаем, че те са най-податливи. Но знаем също много добре, че по-голямата част от тях имат имоти на село.
Много ми хареса израелският министър председател как в онлайн изказване призова възрастните хора да бъдат пазени. Да се приготвят и карантинират ако имат вили или имоти тип втори дом в малки населени места. Да намалят общуването с децата си и с младите хора, както и социалните контакти.

10. Затварянето на зведенията е мярка без нужда от аргументация, но все пак да отбележим, че персонала на заведението потенциално може да зарази всеки клиент стъпил в заведението. Аз се чудя и доставката на храна по домовете при положение, че е сготвена все пак от персонал как гарантира безопасност, но това си е мое мнение.
Знам, че сега ще „гракнат” много хора и ще започнат дебати как в ресторантите целия персонал си прави тестове на всеки 2 часа, а се дезинфекцира на 3 минути, но разберете едно – един болен служител, може да разнесе заразата на стотици клиенти поръчващи храна за вкъщи онлайн.
И всичко това само и само да не си сготвиш сам. При толкова рецепти в интернет и толкова кулинарни предавания да поръчваш готова храна онлайн с цел да се предпазиш от Ковид за мен е лудост, но това е реалността.
Определено е по-добре да се плащат 80% от заплатите на готвачите в заведенията, за да си стоят вкъщи по време на пандемични мерки.

Други актуални анализи и статии
Ще има ли реална 10 годишна абсолютна давност за лошите кредити в България?
Да даряваш на инат


11. Голям проблем се оказаха връщащите се от чужбина българи
. Тяхното карантиниране и проследяване определено трябваше да бъде приоритет на държавата. Повечето които познавам се карантинираха. Но познавам и такива от малцинствата, които ги кониха по махалите в селата, защото се укриваха. А тези хора от глоби и заплахи не се вълнуват. Те са тук временно, защото на запад всичко е затворено. След месец два пак ще заминат, а ние ще останем с разходите по лечението на заразените.

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

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

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

Та затова няма да проработят новите мерки. Нелогични, ненавременни, неправилно организирани, неправилно финансирани, недемократични и най-вече хората масово не им вярват.

При проблем с банка или кредит – заявете среща
[contact-form-7]

The post Какво пропуснахме в мерките за Ковид 19 и защо няма да работят appeared first on Kendov.com.

New product: Raspberry Pi 4 Case Fan

Post Syndicated from original https://www.raspberrypi.org/blog/new-raspberry-pi-4-case-fan/

Today we’re launching a stocking-filler product to help you squeeze more performance out of your Raspberry Pi 4. The $5 Raspberry Pi 4 Case Fan clips inside the lid of the Official Case, and keeps your Raspberry Pi 4 cool even when running the heaviest workloads, at the most aggressive overclocks.

Raspberry Pi 4 power optimisation

Like all electronic products, Raspberry Pi generates waste heat as it works. Along with most fanless products – like most mobile phones – Raspberry Pi 4 was originally designed to operate in a “sprint-and-recover” mode: if run at maximum performance for an extended period it would heat up, and eventually throttle back to limit its temperature.

What’s in the box?

In practice, the power optimisation work that we’ve done over the last eighteen months has largely eliminated throttling for an uncased board, operating at the stock clock frequency of 1.5GHz, and in a typical ambient temperature.

Here’s a graph of temperature during a quad-core compile of the Linux kernel: you can see the temperature barely exceeds 70C.

Quad-core kernel compile without case

Turning your Raspberry Pi “up to eleven”

But maybe you want to put your Raspberry Pi in a case; or you’ve noticed that your Raspberry Pi will overclock to 1.8GHz or more; or you want to use it in a higher ambient temperature. All of these things can put us back in sprint-and-recover mode.

Here’s the same workload running on a board in a Raspberry Pi official case: now we hit the 80C throttle point and slow down, and the compile job takes (slightly) longer to complete.

Quad-core kernel compile in Raspberry Pi 4 Official Case

To run indefinitely at full speed under these conditions you’ll need either a passive cooling solution (like the excellent Flirc case), or an active one like the Raspberry Pi 4 Case Fan. It draws air in over the USB and Ethernet connectors, passes it over a small finned heatsink attached to the processor, and exhausts it through the SD card slot. Here’s our workload running with the case fan: now the board remains well below 70C, and as expected the compile job takes the same amount of time as on the uncased board.

Gordon Hollingworth will be here on Wednesday to talk about how he designed the Raspberry Pi 4 Case Fan ducting with the aid of a stack of Chinese takeout boxes and a glue gun. 

Get your Raspberry Pi 4 Case Fan today

As with all our products, the Raspberry Pi Case Fan is available from our Raspberry Pi Approved Resellers. Simply head over to the Case Fan page and select your country from the drop-down menu.

If your country isn’t on the list yet, don’t worry, we’re constantly working to add further countries and resellers to the list. Until then, check out some of our Approved Resellers that offer international shipping.

The post New product: Raspberry Pi 4 Case Fan appeared first on Raspberry Pi.

Всичко тече. Нищо не се променя

Post Syndicated from original https://bivol.bg/torlaka101bivol.html

неделя 29 ноември 2020


Когато започнахме да избираме какво точно да включим в сборника „101 текста на Торлака за Биволъ“, още от самото начало ми направи впечатление, че почти всички материали бяха все едно съм ги писал преди броени часове. Независимо, че най-старите от тях са на повече от пет години, че са разнообразни като тематика и насоченост, че логиката е да „щракват“ своеобразни стъпки в дадена посока… Да отразяват моменти от някакъв процес на развитие с минало, настояще и бъдеще. Нищо подобно.

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

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

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

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

Това не е текст, свързан с нощното шкафче на Бойко, къщата в Барселона, милиардите, заглобени в Руски поток или реакцията на Венецианската комисия относно юридическия виц, наречен „проект за Конституция“. Съвсем не. Материалът се казва „За каките и бацетата“ и е публикуван точно преди пет години – на 29-и ноември 2015-а. Или пък:

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

Можеше да е част от текста ми „За честта на бекона“ от преди едва една седмица. Обаче датира от преди почти четири години – 20 ноември 2016-а и е озаглавено „Стига толкова сливи за смет!“.

Факт е, че от една страна е доста тягостно да видиш, че всъщност май нищо не се променя. Ако си се вглъбил достатъчно в четенето, понякога направо ти настръхват косите. Толкова енергия се изсипа по площадите, толкова разследвания направиха колегите, толкова доказателства бяха събрани и толкова пъти гражданското общество показа категорично на управляващите, че е крайно време не само те да си вървят, но и целият политически, икономически и правораздавателен модел да се промени… И накрая всичко си е същото. Вместо да се опитвам да убедя някого, че преди пет години не съм си изсмуквал от пръстите разни измишльотини, за да оклеветя властимащите в България, е напълно достатъчно да протегнем врат и да се огледаме какво става сега. Днес.

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

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

Ще ми се да вярвам, че натискът на гражданското общество и разследващата журналистика са сред основните причини все по-рядко да обсъждаме фигури като Цветан Цветанов, Цецка Цачева, Делян Пеевски, че дори и вездесъщият Ахмед Доган. Да, те все още не са в затвора, но все пак бяха принудени да слязат от сцената. Някои изгоряха като бушони, за да отклонят за пореден път вниманието от системните грешки, други изчезнаха от прожекторите, за да се покрият от народната „любов“ и възмездието на бившите си ортаци. На пръв поглед нищожна промяна, но все пак е някакъв пример за подражание. Защото, ако всички си бяхме мълчали, едва ли и до това щеше да се стигне.

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

Съ рогата напредъ!

101 текста на Торлака за Биволъ

Поръчайте книгата “101 текста на Торлака за Биволъ”. Специално издание по случай десетата годишнина на сайта Биволъ. Промоционална цена от 12 лв. (6 евро) за 1 екземпляр. Можете да поръчате също 2, 3, 5 или 10 екземпляра за приятели и познати. Доставка до адрес в България или в чужбина след 15 ноември. Цената на доставката в България се заплаща на куриерската компания при получаване на пратката на личен адрес или в нейния офис. За доставка в чужбина ще се свържем с Вас, за да уточним подробностите.












6



Възможности за плащане

Информация за Вас



Информация за банковата карта


Плащането е защитено със SSL криптиране


Обща сума:


6€



The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close