What's the key to a more secure Cloud Function? It's a secret!

Google Cloud Functions provides a simple and intuitive developer experience to execute code from Google Cloud, Firebase, Google Assistant, or any web, mobile, or backend application. Oftentimes that code needs secrets—like API keys, passwords, or certificates—to authenticate to or invoke upstream APIs and services.While Google Secret Manager is a fully-managed, secure, and convenient storage system for such secrets, developers have historically leveraged environment variables or the filesystem for managing secrets in Cloud Functions. This was largely because integrating with Secret Manager required developers to write custom code… until now. We listened to customer feedback and today we are announcing Cloud Functions has a native integration with Secret Manager!This native integration has many key benefits including:Zero required code changes. Cloud functions that already consume secrets via environment variables or files bundled with the source upload simply require an additional flag during deployment. The Cloud Functions service resolves and injects the secrets at runtime and the plaintext values are only visible inside the process.Easy environment separation. It’s easy to use the same codebase across multiple environments, e.g., dev, staging, and prod, because the secrets are decoupled from the code and are resolved at runtime.Supports the 12-factor app pattern. Because secrets can be injected into environment variables at runtime, the native integration supports the 12-factor pattern while providing stronger security guarantees.Centralized secret storage, access, and auditing. Leveraging Secret Manager as the centralized secrets management solution enables easy management of access controls, auditing, and access logs.Cloud Functions’ native integration with Secret Manager is available in preview to all Google Cloud customers today. Let’s take a deeper dive into this new integration.ExampleSuppose the following cloud function invoked via HTTP uses a secret token to invoke an upstream API:Without Cloud Functions’ native integration with Secret Manager, this function is deployed via:This approach has a number of drawbacks, the biggest of which being that anyone with viewer permissions on the Google Cloud project can see the environment variables set on a cloud function.To improve the security of this code, migrate the secret to Secret Manager in the same project:Finally, without changing any code in the function re-deploy with slightly different flags:It’s truly that easy to migrate from hard-coded secrets to using secure secret storage with Secret Manager! To add even more layers of security, consider running each cloud function with a dedicated service account and practice the principle of least privilege. Learn more in the Secret Manager Best Practices guide.Making security easySecurity and proper secrets management are core pillars of modern software development, and we’re excited to provide customers a way to improve the security of their cloud functions. To learn more about the new native integration, check out the Cloud Functions documentation. You can also learn more about Cloud Functions or learn more about Secret Manager.Related Article4 new features to secure your Cloud Run servicesWe’re improving the security of your Cloud Run environment with things like support for Secret Manager and Binary Authorization.Read Article
Quelle: Google Cloud Platform

Your Google Cloud database options, explained

Picking the right database for your application is not easy. The choice depends heavily on your use case—transactional processing, analytical processing, in-memory database, and so on—but it also depends on other factors. This post covers the different database options available within Google Cloud across relational (SQL) and non-relational (NoSQL) databases and explains which use cases are best suited for each database option. Click to enlargeRelational databases In relational databases information is stored in tables, rows and columns, which typically works best for structured data. As a result they are used for applications in which the structure of the data does not change often. SQL (Structured Query Language) is used when interacting with most relational databases. They offer ACID consistency mode for the data, which means:Atomic: All operations in a transaction succeed or the operation is rolled back.Consistent: On the completion of a transaction, the database is structurally sound.Isolated: Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially.Durable: The results of applying a transaction are permanent, even in the presence of failures.Because of these properties, relational databases are used in applications that require high accuracy and for transactional queries such as financial and retail transactions. For example: In banking when a customer makes a funds transfer request, you want to make sure the transaction is possible and it actually happens on the most up-to-date account balance, in this case an error or resubmit request is likely fine.There are three relational database options in Google Cloud: Cloud SQL, Cloud Spanner, and Bare Metal Solution.Cloud SQL: Provides managed MySQL, PostgreSQL and SQL Server databases on Google Cloud. It reduces maintenance cost and automates database provisioning, storage capacity management, back ups, and out-of-the-box high availability and disaster recovery/failover. For these reasons it is best for general-purpose web frameworks, CRM, ERP, SaaS and e-commerce applications.Cloud Spanner: Cloud Spanner is an enterprise-grade, globally-distributed, and strongly-consistent database that offers up to 99.999% availability, built specifically to combine the benefits of relational database structure with non-relational horizontal scale. It is a unique database that combines ACID transactions, SQL queries, and relational structure with the scalability that you typically associate with non-relational or NoSQL databases. As a result, Spanner is best used for applications such as gaming, payment solutions, global financial ledgers, retail banking and inventory management that require ability to scale limitlessly with strong-consistency and high-availability. Bare Metal Solution: Provides hardware to run specialized workloads with low latency on Google Cloud. This is specifically useful if there is an Oracle database that you want to lift and shift into Google Cloud. This enables data center retirements and paves a path to modernize legacy applications. Non-relational databasesNon-relational databases (or NoSQL databases) store compex, unstructured data in a non-tabular form such as documents. Non-relational databases are often used when large quantities of complex and diverse data need to be organized. Unlike relational databases, they perform faster because a query doesn’t have to access several tables to deliver an answer, making them ideal for storing data that may change frequently or for applications that handle many different kinds of data. For example, an apparel store might have a database in which shirts have their own document containing all of their information, including size, brand, and color with room for adding more parameters later such as sleeve size, collars, and so on.Qualities that make NoSQL databases fast:Eventual consistency: stores usually exhibit consistency at some later point (e.g., lazily at read time)Horizontal scaling, usually using hashed distributionsTypically, they are optimized for a specific workload pattern (i.e., key-value, graph, wide-column)Typically, they don’t support cross shard transactions or flexible isolation modes.Because of these properties, non-relational databases are used in applications that require large scale, reliability, availability, and frequent data changes.They can easily scale horizontally by adding more servers, unlike some relational databases, which scale vertically by increasing the machine size as the data grows. Although, some relations databases such as Cloud Spanner support scale-out and strict consistency.Non-relational databases can store a variety of unstructured data such as documents, key-value, graphs, wide columns, and more. Here are your non-relational database options in Google Cloud: Document databases: Store information as documents (in formats such as JSON and XML). For example: FirestoreKey-value stores: Group associated data in collections with records that are identified with unique keys for easy retrieval. Key-value stores have just enough structure to mirror the value of relational databases while still preserving the benefits of NoSQL. For example: Datastore, Bigtable, MemorystoreIn-memory database: Purpose-built database that relies primarily on memory for data storage. These are designed to attain minimal response time by eliminating the need to access disks. They are ideal for applications that require microsecond response times and can have large spikes in traffic. For example: MemorystoreWide-column databases: Use the tabular format but allow a wide variance in how data is named and formatted in each row, even in the same table. They have some basic structure while preserving a lot of flexibility. For example: BigtableGraph databases: Use graph structures to define the relationships between stored data points; useful for identifying patterns in unstructured and semi-structured information. For example: JanusGraphThere are three non-relational databases in Google Cloud:Firestore: Is a serverless document database which scales on demand and acts as a backend-as-a-service. It is DBaaS that increases the speed of building applications. It is perfect for all general purpose uses cases such as ecommerce, gaming, IoT and real time dashboards. With Firestore users can interact with and collaborate on live and offline data making it great for real-time application and mobile apps.  Cloud Bigtable: Cloud Bigtable is a sparsely populated table that can scale to billions of rows and thousands of columns, enabling you to store terabytes or even petabytes of data. It is ideal for storing very large amounts of single-keyed data with very low latency. It supports high read and write throughput at sub-millisecond latency, and it is an ideal data source for MapReduce operations. It also supports the open-source HBase API standard to easily integrate with the Apache ecosystem including HBase, Beam, Hadoop and Spark along with Google Cloud ecosystem.Memorystore: Memorystore is a fully managed in-memory data store service for Redis and Memcached at Google Cloud. It is best for in-memory and transient data stores and automates the complex tasks of provisioning, replication, failover, and patching so you can spend more time coding. Because it offers extremely low latency and high performance, Memorystore is great for web and mobile, gaming, leaderboard, social, chat, and news feed applications.ConclusionChoosing a relational or a non-relational database largely depends on the use case. Broadly, if your application requires ACID transactions and your data structure is not going to change much, select a relational database. In Google Cloud use Cloud SQL for any general-purpose SQL database and Cloud Spanner for large-scale globally scalable, strongly consistent use cases. In general, if your data structure may change later and if scale and availability is a bigger requirement than consistency then a non-relational database is a preferable choice.  Google Cloud offers Firestore, Memorystore, and Cloud Bigtable to support a variety of use cases across the document, key-value, and wide column database spectrum.For more comparison resources on each database check out the overview. For more hands-on experience with Bigtable, check out our on-demand training here and learn about migrating databases to managed services check out this whitepaper.  For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev.Related ArticleWhat is Cloud Spanner?Want a relational database that scales globally? Learn all about Cloud Spanner.Read Article
Quelle: Google Cloud Platform

AWS Lambda ergänzt Support für Python 3.9

AWS Lambda unterstützt jetzt Python 3.9 sowohl als verwaltete Laufzeit als auch als Container-Basis-Image. Sie können jetzt AWS Lambda-Funktionen in Python 3.9 verfassen und die neuen Funktionen nutzen, z. B. Unterstützung für TLS 1.3, neue String- und Wörterbuchoperationen und verbesserte Zeitzonenunterstützung. Python 3.9 enthält auch Leistungsoptimierungen, von denen Sie profitieren können, ohne Codeänderungen vorzunehmen. Weitere Informationen zur Lambda-Unterstützung für Python 3.9 finden Sie in unserem Blogbeitrag zur Python 3.9-Laufzeit, die jetzt in AWS Lambda verfügbar ist.
Quelle: aws.amazon.com

AWS Systems Manager Fleet Manager bietet jetzt die Erstellung von Berichten für verwaltete Instances

AWS Systems Manager Fleet Manager, eine Funktion in AWS Systems Manager (SSM), die Sie bei der Rationalisierung und Skalierung Ihrer Remote-Server-Verwaltungsprozesse unterstützt, bietet jetzt die Möglichkeit, auf einen Blick Berichte über Ihre SSM verwaltete Instances zu erstellen. Die neue Funktion ermöglicht es Ihnen, das Fleet Manager-Informationspanel anzupassen, in dem Sie Warnungen, Status und Details der verwalteten Instances anzeigen und zur lokalen Anzeige und Analyse downloaden können. 
Quelle: aws.amazon.com

Neue Version des AWS IoT Device SDK für Embedded C vereinfacht die Authentifizierung und Bereitstellung von IoT-Geräten

AWS IoT Device SDK für Embedded C (C-SDK) Version 202108.00 enthält die AWS SigV4-Bibliothek und eine überarbeitete AWS IoT Flottenbereitstellungs-Client-Bibliothek für IoT-Anwendungen. Diese Version erleichtert Entwicklern, die C-SDK verwenden, die Authentifizierung eingehender API-Anforderungen an AWS-Services von IoT-Geräten, auf denen HTTP läuft, und die Bereitstellung von IoT-Geräten, die nicht über eindeutige Zertifikate verfügen.
Quelle: aws.amazon.com

AWS Marketplace verbessert die ISV-Selbstbedienungsautorisierung von Beratungspartnern

Heute gab AWS Marketplace bekannt, dass unabhängige Softwareanbieter (ISV) jetzt benutzerdefinierte Produktdimensionen hinzufügen und Endbenutzer-Lizenzvereinbarungen (EULA) angeben können, wenn sie ihre bevorzugten Beratungspartner zum Weiterverkauf ihrer Software an AWS Marketplace-Käufer autorisieren. Dieser Start aktiviert ISVs und Beratungspartnern, effizienter zusammenzuarbeiten, um ein privates Angebot für Beratungspartner (Consulting Partner Private Offer, CPPO) zu erstellen, mit dem Kunden Softwarelösungen im AWS Marketplace direkt von Beratungspartnern erwerben können. ISVs und Beratungspartner können nun ihre Produktion weiter vereinfachen und die Bereitstellung für ihre Kunden beschleunigen.
Quelle: aws.amazon.com