Pseudo-Random Number Generators (PRNGs) are getting a major update in Java with the release of JEP 356. New interfaces and implementations make it easier to use different algorithms interchangeably and offer better support for stream-based programming. This is a great improvement for Java developers who require randomness in their applications. 

The JDK is constantly evolving and improving, and part of that process is ensuring that internal APIs are properly encapsulated. JEP 403 represents a step in that direction, by removing the –illegal-access flag. This will prevent JDK users from accessing internal APIs, except for critical ones like sun.misc.Unsafe.  

To enable BigQuery row-level security, you can follow these steps:

1. Go to the BigQuery console and select the Datasets tab.
2. Click the name of the dataset that you want to enable row-level security for.
3. Click the Security tab.
4. Click the Row-level security tab.
5. Click the Create policy button.
6. In the Create policy dialog, enter a name for your policy.
7. In the Principals section, select the users or groups that you want to grant access to the data.
8. In the Filter section, enter a SQL filter that defines the rows that the users or groups will be able to access.
9. Click the Create button.

Once you have created a row-level security policy, users or groups that are not included in the policy will not be able to access the data in the table.

GCP Cloud IPs by region 

IP range with geolocation

More info here

Apache Beam is an open-source unified programming model and framework for defining and executing big data processing pipelines. It provides a way to write data processing code that is portable across different execution engines or runtimes, such as Apache Flink, Apache Spark, Google Cloud Dataflow, and more.

Apache Beam’s portability framework allows you to write your data processing logic once and then run it on different execution engines without modifying the code. This eliminates the need to rewrite or refactor the code for each specific execution engine, saving time and effort.

Terraform’s Cloud Development Kit (CDK) let’s you use other languages to define your cloud infra.

https://github.com/hashicorp/terraform-cdk/blob/master/examples/

No more copying and pasting modules.

“During April, we observed deployment of a suspect image from a public repository on many different clusters. The image is ddsfdfsaadfs/dfsdf:99. By inspecting the image’s layers, we can see that this image runs an XMRIG miner:” Source

Welcome to the cloud …

1. Check the running containers: The easiest way to spot an XMRIG miner in a Kubernetes cluster is by checking the running containers. Use the kubectl get pods command to get a list of all the running pods in the cluster. Then, use kubectl logs command to check the logs of each container in the pod for any mention of XMRIG or Monero mining.
2. Check resource usage: XMRIG miner consumes a lot of system resources such as CPU and memory. You can use kubectl top command to check the resource usage of each pod in the cluster. If you notice a pod consuming unusually high resources, it might be running an XMRIG miner.
3. Check network traffic: XMRIG miner communicates with mining pools over the internet. You can use tools like Wireshark or tcpdump to capture network traffic and analyze it for any connections to known mining pool servers.
4. Check for unauthorized access: XMRIG miner can be deployed in a Kubernetes cluster without proper authorization. Check for any unauthorized deployments or changes to the Kubernetes configuration that might indicate an XMRIG

A great way to split up your pipeline based on the urgency of results aggregate-data-with-dataflow