Cloud Hosting

PostgreSQL has been hot for years, but that hotness can also be a challenge for enterprises looking to pick between a host of competing vendors. As enterprises look to move off expensive, legacy relational database management systems (RDBMS) but still want to stick with an RDBMS, open source PostgreSQL is an attractive, less-expensive alternative. But which PostgreSQL? AWS was once the obvious default with two managed PostgreSQL services (Aurora and RDS), but now theres Microsoft, Google, Aiven, TimeScale, Crunchy Data, EDB, Neon, and more.

In an interview with the founder and CEO of Neon Nikita Shamgunov, he stressed that among this crowd of pretenders to the PostgreSQL throne, the key differentiator going forward is serverless. We are serverless, and all the other ones except for Aurora, which has a serverless option, are not, he declares. If hes right about the importance of serverless for PostgreSQL adoption, its possible the future of commercial PostgreSQL could come down to a serverless battle between Neon and AWS.

In some ways, serverless is the fulfillment of clouds promise. Almost since the day it started, for example, AWS has pitched the cloud as a way to offload the undifferentiated heavy lifting of managing servers, yet even with services like Amazon EC2 or Amazon RDS for PostgreSQL, developers still had to think about servers, even if there was much less work involved.

In a truly serverless world, developers dont have to think about the underlying infrastructure (servers) at all. They just focus on building their applications while the cloud provider takes care of provisioning servers.In the world of databases, a truly serverless offering will separate storage and compute, and substitute the databases storage layer by redistributing data across a cluster of nodes.

Among other benefits of serverless, asAnna Geller, Kestras head of developer relations, explains, serverless encourages useful engineering practices. For example, if we can agree that its beneficial to build individual software components in such a way that they are responsible for only one thing, she notes, then serverless helps because it encourages code that is easy to change and stateless. Serverless all but forces a developer to build reproducible code. She says, Serverless doesnt only force you to make your components small, but it also requires that you define all resources needed for the execution of your function or container.

The result: better engineering practices and much faster development times, as many companies are discovering. In short, there is a lot to love about serverless.

Shamgunov sees two primary benefits to running PostgreSQL serverless. The first is that developers no longer need to worry about sizing. All the developer needs is a connection string to the database without worrying about size/scale. Neon takes care of that completely. The second benefit is consumption-based pricing, with the ability to scale down to zero (and pay zero). This ability to scale to zero is something that AWS doesnt offer, according to Ampt CEO Jeremy Daly. Even when your app is sitting idle, youre going to pay.

But not with Neon. As Shamgunov stresses in our interview, In the SQL world, making it truly serverless is very, very hard. There are shades of gray in terms of how companies try to deliver that serverless promise of scaling to zero, but only Neon currently can do so, he says.

Do people care? The answer is yes, he insists. What weve learned so far is that people really care about manageability, and thats where serverless is the obvious winner. [It makes] consumption so easy. All you need to manage is a connection stream. This becomes increasingly important as companies build ever-bigger systems with bigger and bigger fleets. Here, Its a lot easier to not worry about how big [your] compute [is] at a point in time. In other systems, you end up with runaway costs unless youre focused on dialing resources up or down, with a constant need to size your workloads. But not in a fully serverless offering like Neon, Shamgunov argues. Just a connection stream and off you go. People love that.

Not everything is rosy in serverless land. Take cold starts, for example. The first time you invoke a function, the serverless system must initialize a new container to run your code. This takes time and is called a cold start. Neon has been putting in a non-trivial amount of engineering budget to solving the cold-start problem, Shamgunov says. This follows a host of other performance improvements the company has made, such as speeding up PostgreSQL connections.

Neon also uniquely offers branching. As Shamgunov explains, Neon supports copy-on-write branching, which allows people to run a dedicated database for every preview or every GitHub commit. This means developers can branch a database, which creates a full copy of the data and gives developers a separate serverless endpoint to it. You can run your CI/CD pipeline, you can test it, you can do capacity or all sorts of things, and then bring it back into your main branch. If you dont use the branch, you spend $0. Because its serverless. Truly serverless.

All of which helps Neon deliver on its promise of being as easy to consume as Stripe, in Shamgunovs words. To win the PostgreSQL battle, he continues, You need to be as developer-friendly as Stripe. You need, in short, to be serverless.

Originally posted here:
Serverless is the future of PostgreSQL - InfoWorld

Last month, the Irish Data Protection Commission (DPC), a leading European Union privacy regulator, issued a landmark ruling suspending Metas cross-border transfer of personal data from its EU users to its U.S.-based servers. The DPCs ruling includes a record $1.3 billion fine and could potentially shutter access to Facebook and Instagram across the EU.

The consequences, though, could extend far beyond Meta. In its ruling, the DPC held that businesses cannot rely on the so-called Standard Contractual Clauses, a legal framework used by Meta and others to transfer data from the EU to the U.S. in compliance with European privacy law. That framework is used by more than 90% of businesses engaged in transatlantic commerce, a nearly $7.1 trillion industry.

A disruption in transatlantic data flows would not only take a bite out of the economy, but also impact any company doing business in the EU which relies on U.S.-based software or cloud hosting.

The DPCs ruling against Meta is the latest in a long line of high-profile EU decisions that raise fundamental questions about whether European privacy law permits any type of transatlantic data transfer given the potential for U.S. intelligence agencies to surveil personal data held by American companies.

Opinion

Get smart opinions on the topics North Texans care about.

In other words, the concern driving the EU to ban data transfers to companies like Meta closely resembles the concern driving Americans to ban TikTok: That a foreign government may be able to surveil personal data held by a foreign company.

The upshot of this overlap aside, perhaps, from a gut check that Europeans view the U.S. like Americans view China is that both problems can be addressed through a single solution: a comprehensive federal privacy law.

This law can empower consumers to manage their own data in a way that minimizes what information businesses can collect or retain and, by extension, what governments can glean from those businesses. This would solve the problem from the bottom up, with consumers themselves limiting what data is potentially subject to corporate misuse or government surveillance.

The U.S. has much to gain from passing a comprehensive federal privacy law. Such a law would not only strengthen consumer privacy (by giving consumers more control) and protect national security (by reducing what data companies like TikTok can collect), but also provide American businesses with much-needed regulatory certainty.

The latter is particularly salient given the DPCs recent ruling against Meta. It is not tenable for American businesses to operate in a state of limbo as to whether their services or software will one day be banned in Europe or other privacy-conscious jurisdictions. And European policymakers have indicated that passing a comprehensive U.S. privacy law is the best way to stabilize EU-U.S. data flows over the long term.

Indeed, the European Commission is currently rushing to finalize a new transatlantic data transfer mechanism known as the EU-U.S. Data Privacy Framework. This new framework accounts for recent changes in U.S. surveillance policy made to address EU concerns. Yet these changes have been poorly received by European policymakers because they are the product of executive rather than legislative action, and the U.S., unlike most developed countries, lacks a comprehensive privacy law that enshrines baseline protections.

In the short term, these concerns should not stop the European Commission from finalizing the new framework to sustain data flows in the wake of the DPCs Meta decision. The commission has already indicated that, at least provisionally, the new framework adequately addresses concerns about mass surveillance, and a $7.1 trillion economic disruption would harm both the U.S. and Europe.

Even if the framework is finalized, though, it may not deliver the long-term certainty that American businesses need. Like its predecessors, it will face almost immediate legal jeopardy unless or until the United States passes a comprehensive privacy law.

Rarely can a single act of legislation serve the interests of industry, consumers and national security. A federal privacy law would do just that, but the clock is ticking.

Jordan E.M. Sessler serves as privacy counsel for BigCommerce, a Texas-based ecommerce software provider. The views expressed are his own and not those of BigCommerce. He wrote this column for The Dallas Morning News.

We welcome your thoughts in a letter to the editor. See the guidelines and submit your letter here.

Follow this link:
A data privacy law is becoming more urgent every day - The Dallas Morning News

Continuous Integration/Continuous Deployment (CI/CD) pipelines have become crucial to modern software development practices. CI/CD pipelines can significantly improve development efficiency and software quality by automating the process of building, testing, and deploying code. Most modern CI/CD platforms (like GitHub actions, Circle CI, etc.) offer an option to run the pipeline process over a self-hosted runner an agent hosted by the user instead of the CI/CD platform, to execute jobs on their own infrastructure.

With self-hosted runners, you can create custom hardware configurations that meet your needs with processing power or memory to run larger jobs. Additionally, you can install software available on your local network and choose an operating system not offered by the platform. Self-hosted runners can be physical, virtual, in a container, on-premises, or in a cloud environment. The alternative is to use a build-as-a-service runner offered by SaaS CI/CD platform where the user has no control over the environment.

One might use self-hosted runners for several reasons:

Compliance and privacy: many organizations are bound to strict regulations that prevent them from building and sending sensitive data to SaaS build services. For example, organizations from the financial or gov sectors often prefer running the build on their internal servers.

Special specifications: when building software for uncommon operating systems or different architectures, the build process needs a machine with specs that match their requirements. This is also the case in many embedded, IoT, or client-side applications.

Cost saving: organizations with existing cloud infra / private cloud can save costs if they choose to use self-hosted runners and manage resource pools themselves.

Given the reasons above, self-hosted runners have gained popularity in many organizations. However, self-hosted runners can pose significant security risks, especially if untrusted workflows run on them. Malicious programs may compromise the build machine, and escape from the runners sandbox, exposing access to the machines network, secrets, and more.

Using a self-hosted runner can offer advantages, such as improved performance and increased environmental control. However, there are also security risks associated with it:

Self-hosted runners require dedicated servers or virtual machines (VMs) to operate. The security of these servers is crucial. If the server hosting the runner is not properly secured, it can become a potential entry point for attackers.

Self-hosted runners typically require privileged access to the repository and the system on which they are installed. Its important to carefully manage access control and restrict the permissions granted to the runner. Unauthorized access to the runner could lead to potential data breaches or malicious code execution.

Failure to isolate self-hosted runners from critical systems and sensitive data increases the risk of a compromised runner leading to unauthorized access and potential data breaches. Without proper isolation, attackers who gain control of the runner may be able to move laterally within the network, potentially compromising other systems and data.

Neglecting to regularly update and monitor the self-hosted runner software exposes the system to known vulnerabilities and leaves it susceptible to attacks. Without timely security patches and updates, attackers can exploit known weaknesses in the runner software. Insufficient monitoring increases the chances of undetected malicious activities and delays in responding to security incidents, potentially resulting in extended periods of unauthorized access or damage.

Using a self-hosted runner without restricting access to authorized users allows anyone to exploit compute resources for activities like crypto-mining and other activities that can inflict financial damage.

GitHub Actions have gained significant adoption in recent years as a powerful CI/CD automation tool for software development. With GitHub Actions, developers can automate tasks like building, testing, and deploying software, allowing them to focus on more important tasks. GitHub Actions offers a wide range of customization options, including pre-built actions, community-built actions, and the ability to create your own actions. As more and more organizations adopt GitHub Actions, it is becoming an increasingly important tool for modern software development.

GitHub also provides the option to use self-hosted runners. You can add self-hosted runners at various levels in the management hierarchy, including repository-level runners dedicated to a single repository, organization-level runners that can process jobs for multiple repositories in an organization, and enterprise-level runners that can be assigned to multiple organizations in an enterprise account.

During our research, weve scanned over three million public repositories. For each repository, weve inspected the different GitHub Actions files and extracted the runner used by each job. We have learned that out of 3,106,445 public repositories checked, 43,803 are using self-hosted runners. Using a self-hosted runner in a public repository increases the aformantioned risks dramatically, as any GitHub user in the world could initiate an attack.

GitHub provides organizations with several options to configure their self-hosted runners. Users need to verify that their organization is following configuration best practices to prevent potential risks.

Runner groups:When a self-hosted runner is defined at the organization or enterprise level, GitHub can schedule workflows from multiple repositories onto the same runner. Consequently, a security compromise in these environments can result in a wide impact. To help reduce the scope of a compromise, you can create boundaries by organizing your self-hosted runners into separate groups.

Disallowing public repositories:If you use self-hosted runners with public repositories and do not properly configure access controls, an attacker can potentially gain access to your self-hosted runner machine by creating a pull request that runs a malicious workflow. This can allow the attacker to execute arbitrary code on your machine, access sensitive data, or perform other malicious actions, depending on the level of access your self-hosted runner machine has.

For example, an attacker could modify the code in a pull request to execute commands that install malware on your self-hosted runner machine or steal sensitive data from your organization. This can lead to serious consequences, including data breaches, loss of intellectual property, and damage to your organizations reputation.

To avoid the risk, its advised to use self-hosted runners only with private repositories. You can limit the attack surface and reduce the risk of unauthorized access to your self-hosted runner machine.

Access control:You can restrict what organizations and repositories can access runner groups. Additionally, you can restrict the runners to specific workflows. For more information, see Managing access to self-hosted runners using groups.

In a blog post posted by @ryotkak, we can see an example of how self-hosted runners impose risk and, if used incorrectly, can lead to sensitive information theft. ryotkak shows an example of workflow created by GitHub. The vulnerable workflow is part of the actions framework itself.Under specific conditions, the self-hosted runner was reachable to any attacker. The token stolen in that example was a token owned by a developer from GitHub itself which attackers could have leveraged to carry a wide-impact software supply chain attack.

In this demo, we show how we created a public GitHub repository with a self-hosted runner. This example shows an external malicious collaborator performing several attacks.

In the first image, we can see the runner pwn_me is added to the runners group pool.

Our next step was to configure a workflow that runs on our self-hosted runner and is triggered by the pull_request trigger:

jobs: hellow_world: runs-on: self-hosted steps: - uses: "actions/checkout@2541b1294d2704b0964813337f33b291d3f8596b" with: fetch-depth: 0 - name: dummy_action run: echo "hello world" && ls -la

Now, all an attacker needs to do is create a fork with a modified workflow file that retrieves the runners secrets and sensitive information. An example of a job created by a malicious contributed:

This video shows how we created a pull request from a fork and gained access to the /etc/passwd file as an example.

The following best practices are relevant to all CI/CD self-hosted platforms. Whether you use GitHub Actions Jenkins, GitLab, or any other platform, these guidelines will help keep your self-hosted runners safe and your software supply chain secure:

Make sure no sensitive information is stored over the runner. For example, private SSH keys, and API access tokens, among others.

Make sure the runner has minimum network access to other internal assets. For example, Azure or AWS management consoles or metadata services. Management consoles and metadata services are panels the cloud vendor provides to retrieve cloud environment management or perform information. An attacker with access to these resources can change the victims cloud configuration or extend their attack surface. The amount of sensitive information in this environment should be minimal. You should always be mindful that any user capable of invoking workflows has access to this environment.

Ensure all services inside the runner are up-to-date and free from known vulnerabilities.

Avoid persistency make sure each job runs on a clean, fresh agent container/VM

If using containers, run at minimum permissions.

Avoid running containers in privileged mode.

Make sure the container is mounted to dedicated devices and does not share resources with the host.

Run only a single container per host.

Use HTTPS for communication: Use HTTPS to encrypt communication between your self-hosted runner and GitHub, and avoid using unencrypted HTTP.

Overall, self-hosting CI/CD pipelines can be risky if not properly managed. To minimize the potential dangers, its essential to follow security best practices, such as regularly updating self-hosted agents, implementing access controls, and monitoring for suspicious activity. Additionally, organizations should consider using cloud-based CI/CD services that can provide better security and reliability than self-hosted solutions.

The Legit Security platform connects to your build environment to detect attack attempts in your pipeline and much more. We identify different misconfigurations, such as a public repository that uses a self-hosted runner. If you are concerned about these security risks and others across your software supply chain, pleasecontact us torequest demo on our website.

*** This is a Security Bloggers Network syndicated blog from Legit Security Blog authored by Nadav Noy. Read the original post at: https://www.legitsecurity.com/blog/securing-your-ci/cd-pipeline-exploring-the-dangers-of-self-hosted-agents

Original post:
Securing Your CI/CD Pipeline: Exploring the Dangers of Self-Hosted Agents - Security Boulevard

Google Cloud has put $1 million on the table to cover customers' unauthorized compute expenses stemming from cryptomining attacks if its sensors don't spot these illicit miners.

Unlike their louder, flashier counterparts (looking at you, ransomware crews), cryptominers are stealthier. Once they've broken into a victims' compute environment often via compromised credentials they keep quiet, deploying mining malware and then raking in cryptocurrencies using the stolen compute resources.

This goes on until they get caught, which usually happens when a victim notices other legit workloads' performance lagging while their computing costs spike.

Plus, according to security researchers, illicit mining is on the rise. Google's Cybersecurity Action Team found that 65 percent of compromised cloud accounts experienced cryptocurrency mining [PDF].

The chocolate factory is confident that it can promptly detect and stop these attacks, and to that end it is adding cryptoming protection with up to $1 million to cover unauthorized Google Cloud compute expenses associated with undetected cryptomining attacks for its Security Command Center Premium customers.

Security Command Center is Google Cloud's built-in security and security and risk-management platform, and the new service scans virtual machine memory for mining malware. In a blog post today, Google Cloud's Greg Smith and Tim Peacock describe the cryptomining detector thus:

And, if this doesn't protect the cloud security product's premium customers, then Google will reimburse them up to $1 million.

Earlier this year, security researchers uncovered a sneaky mining botnet dubbed HeadCrab that uses bespoke malware to mine for Monero crytocurrency and infected at least 1,200 Redis servers in the last 18 months.

The compromised servers span the US, UK, German, India, Malaysia, China and other countries, according to Aqua Security's Nautilus researchers, who discovered the HeadCrab malware and have now found a way to detect it.

Based on the attacker's Monero wallet, the researchers estimate that the crooks expected an annual profit of about $4,500 per infected worker.

Read more:
Google puts $1M behind its promise to detect cryptomining malware - The Register