Kubernetes does not come secure out of the box. There is a lot of configuration needed to achieve a secure cluster. One important security configuration to consider is how pods communicate with each other. This is where Network Policies come into play, making sure that your pods are not exchanging data with unknown or malicious sources, which can compromise your cluster.

Network Policies are rules on how pods can communicate with other pods as well as endpoints. They are pretty much a firewall for your internal cluster network.

GitLab provides Container Network Security using Cilium as a GitLab-managed application. Cilium is a CNI network plugin for Kubernetes that can be used to implement support for Network Policies.

The video below provides an introduction on how to easily implement Network Policies from GitLab, as well as a demo on testing Network Policies:

Network Policies in action

There are many different ways of configuring Network Policies within your Kubernetes cluster. You can configure the ingress from as well as the egress to traffic. There are four kinds of selectors which can be used to configure traffic between pods:

• podSelector: Selects provided pods in the same namespace
• namespaceSelector: Selects all pods on given namespace
• podSelector & namespaceSelector: Selects provided pods in given namespace
• ipBlock: Blocks external IP CIDR ranges provided

More information on the behavior of "to" and "from" selectors can be found in the Kubernetes documentation.

Below is an example of a Network Policy that only allows ingress traffic to pod with label app: "notes" from pods with label access: "true".

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-notes
spec:
  podSelector:
    matchLabels:
      app: "notes"
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"

Installing Cilium as a GitLab-managed application

Cilium is provided by GitLab as a managed application, meaning that GitLab installs and upgrades Cilium for you. There is no need to worry about how to get Cilium up and running. Cilium as well as your Network Policies can be configured as needed.

In order to install and configure Cilium as a GitLab managed application, you can follow the steps provided in the GitLab cluster applications documentation. This sample project Simply Simple Notes, is configured to use Cilium. It will install Cilium on the Kubernetes cluster associated with the project.

This guide can be used to test your Network Policies once Cilium has been installed.

Threat monitoring dashboard

By default Cilium installs with Hubble, a monitoring daemon which collects packet flow metrics per namespace. These metrics are sent to the GitLab Threat Monitoring dashboard.

Packet Metrics displayed in the Threat Management dashboard

The packet flow metrics collected are:

• The total number of inbound and outbound packets for the given time period
• The proportion of packets dropped according to the configured policies
• The average rate per-second of forwarded and dropped packets for the requested time interval

Within the Threat Monitoring dashboard, you can also view and configure the Network Policies in your project. This makes it easy to navigate your container network configuration in one interface.

Network Policies displayed in the Threat Management dashboard

Network Policies can also be created and edited through an intuitive UI. You can just select the network rules you wish to use and the YAML will be automatically created and applied to your cluster. This eliminates the need to edit the complicated YAML structure for Network Policies directly, and allows you to make sure the correct rules are being applied without confusion.

Network Rules can be created using the following rule types:

• Labels
• Entities
• IP/CIDR
• DNS
• Level 4

Policy being created in the Threat Management dashboard

Learn more about GitLab Security

I hope this blog can help get you started with Network Policies in Kubernetes. Check out some other ways GitLab can help with security.

• How application security engineers can use GitLab to secure their projects
• How to capitalize on GitLab Security tools with external CI
• What you need to know about Kubernetes RBAC

Cover image by Diane Helentjaris on Unsplash

Every six weeks, we create a new branch of V8 as part of our release process. Each version is branched from V8’s Git master immediately before a Chrome Beta milestone. Today we’re pleased to announce our newest branch, V8 version 8.7, which is in beta until its release in coordination with Chrome 87 Stable in several weeks. V8 v8.7 is filled with all sorts of developer-facing goodies. This post provides a preview of some of the highlights in anticipation of the release.

JavaScript #

Unsafe fast JS calls #

V8 v8.7 comes with an enhanced API for doing native calls from JavaScript.

The feature is still experimental and can be enabled through the --turbo-fast-api-calls flag in V8 or the corresponding --enable-unsafe-fast-js-calls flag in Chrome. It is designed to improve performance of some native graphics APIs in Chrome, but can also be used by other embedders. It provides new means for developers to create instances of v8::FunctionTemplate, as is documented in this header file. Functions created using the original API will remain unaffected.

For more information and a list of available features, please see this explainer.

Atomics.waitAsync #

Atomics.waitAsync is now available in V8 v8.7.

Atomics.wait and Atomics.notify are low-level synchronization primitives useful for implementing mutexes and other means of synchronization. However, since Atomics.wait is blocking, it’s not possible to call it on the main thread (trying to do so will throw a TypeError). The non-blocking version, Atomics.waitAsync, is usable also on the main thread.

Check out our explainer on Atomics APIs for more details.

V8 API #

Please use git log branch-heads/8.6..branch-heads/8.7 include/v8.h to get a list of the API changes.

Developers with an active V8 checkout can use git checkout -b 8.7 -t branch-heads/8.7 to experiment with the new features in V8 v8.7. Alternatively you can subscribe to Chrome’s Beta channel and try the new features out yourself soon.

Posted by Jennifer Kohl, Google Developers Global Communities Program Manager

Luiza in her hometown, Magas

Magas is the capital of the Republic of Ingushetia, the smallest region in Russia. Centered between Chechnya and North Ossetia, the area is no stranger to conflict. Even as it rebuilds, the region has seen its unemployment numbers rise to as high as 50 percent. Magas, a mostly rural area, is home to a small population of just under six-thousand people - it’s estimated that under 100 of them are developers.

Yet one day that small group of developers decided to take their first step towards becoming a community. These founders heard of Google Developer Groups (GDG) and had seen their community meetups in action on trips to other larger cities in Russia. Inspired by how GDG brought developers together, they believed starting a community in Magas was just what they all needed to grow.

GDG Magas was up and running immediately, hosting small community events in classrooms and meeting spaces across town. And it was there, at a local meetup, where GDG Magas met Luiza.

Luiza speaking at a University competition

At the time, Luiza was a student at a local university. Equipped with a curious mind, she was hungry to learn more. She often challenged herself to think about how women could grow professionally and personally within traditional cultures. Luiza was interested in technology, a mostly unheard of career path in this small town. At the same time, Women Techmakers, a Google program that provides resources for women in technology, started collaborating with GDG chapters around the world to help women like Luiza get started on their journey.

So together, GDG Magas and Women Techmakers started hosting talks and workshops for women in the community. Eventually, they began running a programming class for beginners, and that’s where Luiza realized she had the space to truly explore her interest in code. The community organized thirteen classes, and each Saturday Luiza would join GDG Magas to learn everything from arrays, to Python, to JavaScript, and more.

With GDG Magas providing Luiza with this access to learning materials and mentorship, there has been no turning back. Luiza landed a competitive role working for an internet company, will soon give her own talks at GDG events, and is even starting her own Google Developer Student Club as she completes her studies in Magas. Luiza is now at the forefront of helping a rural town become a growing tech scene, taking the lead to shape her future and that of many young developers around her.

GDG Magas and similar developer communities are growing faster than ever, thanks to determined developers just like Luiza.

Ready to find a developer community near you? Join a local Google Developer Group, here.

You might want your program to change its behavior depending on whether the file you are operating on is on an SSD or not. Maybe you’d use Prefetch­Virtual­Memory to get the contents of a memory-mapped file into memory more efficiently if the file is on a hard drive, but not bother if the file is on an SSD, since the SSD can produce the data quickly enough anyway.

bool IsFileOnSsd(PCWSTR filePath)
{
  wil::unique_hfile volume = GetVolumeHandleForFile(filePath);

  STORAGE_PROPERTY_QUERY query{};
  query.PropertyId = StorageDeviceSeekPenaltyProperty;
  query.QueryType = PropertyStandardQuery;
  DWORD bytesWritten;
  DEVICE_SEEK_PENALTY_DESCRIPTOR result{};

  if (DeviceIoControl(volume.get(), IOCTL_STORAGE_QUERY_PROPERTY,
      &query, sizeof(query),
      &result, sizeof(result),
      &bytesWritten, nullptr)) {
    return !result.IncursSeekPenalty;
  }
  return false;
}

This takes advantage of the trick we learned last time where you can make a storage query against a volume, and it will report the answer if the volume has a single extent.

We aren’t so much checking whether it’s on an SSD drive as we are checking whether seeks are free. That is true for SSDs, but it’s also true for RAM drives. But RAM drives are even faster than SSDs, so I think it’s okay to treat them as “super-awesome SSDs”.

The Get­Volume­Handle­For­File function we wrote a few days ago will throw if the file is remote (on a network). We probably want to report network files as “not on an SSD”, because even if they are on an SSD on the server, the network transmission cost will make it feel slow.

wil::unique_hfile GetVolumeHandleForFile(PCWSTR filePath)
{
  wchar_t volumePath[MAX_PATH];
  THROW_IF_WIN32_BOOL_FALSE(GetVolumePathName(filePath,
                                volumePath, ARRAYSIZE(volumePath)));

  wchar_t volumeName[MAX_PATH];
  if (!GetVolumeNameForVolumeMountPoint(volumePath,
                                volumeName, ARRAYSIZE(volumeName))) {
    return {};
  }

  auto length = wcslen(volumeName);
  if (length && volumeName[length - 1] == L'\\')
  {
    volumeName[length - 1] = L'\0';
  }

  wil::unique_hfile result{ CreateFile(volumeName, 0,
                FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
                nullptr, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, nullptr) };
  THROW_LAST_ERROR_IF(!result);
  return result;
}

We would then check whether a volume was gotten:

bool IsFileOnSsd(PCWSTR filePath)
{
  wil::unique_hfile volume = GetVolumeHandleForFile(filePath);
  if (!volume) return false;

  STORAGE_PROPERTY_QUERY query{};
  query.PropertyId = StorageDeviceSeekPenaltyProperty;
  query.QueryType = PropertyStandardQuery;
  DWORD bytesWritten;
  DEVICE_SEEK_PENALTY_DESCRIPTOR result{};

  if (DeviceIoControl(volume.get(), IOCTL_STORAGE_QUERY_PROPERTY,
      &query, sizeof(query),
      &result, sizeof(result),
      &bytesWritten, nullptr)) {
    return !result.IncursSeekPenalty;
  }
  return false;
}

As we noted last time, the query against a volume will fail if the volume spans multiple physical disks. If you have a volume that spans multiple SSDs, this function will nevertheless report that it isn’t an SSD.

So we probably would be better off checking the SSD-ness of every physical drive in the volume. That’s a lot of work, so I’m going to cheat and check just the first physical drive in the volume, on the theory that when people create multi-drive volumes, they’re going to be drives of similar performance characteristics.

bool IsFileOnSsd(PCWSTR filePath)
{
  wil::unique_hfile volume = GetVolumeHandleForFile(filePath);
  if (!volume) return false;

  wil::unique_hfile disk =
    GetFirstPhysicalDiskHandleForVolume(volume.get());
  if (!disk) return false;

  STORAGE_PROPERTY_QUERY query{};
  query.PropertyId = StorageDeviceSeekPenaltyProperty;
  query.QueryType = PropertyStandardQuery;
  DWORD bytesWritten;
  DEVICE_SEEK_PENALTY_DESCRIPTOR result{};

  if (DeviceIoControl(disk.get(), IOCTL_STORAGE_QUERY_PROPERTY,
      &query, sizeof(query),
      &result, sizeof(result),
      &bytesWritten, nullptr)) {
    return !result.IncursSeekPenalty;
  }
  return false;
}

Bonus chatter: Many people cheat even further and also assume that the volume is mounted as a drive letter. In that case, obtaining the volume handle for the file is a simple matter of opening \\.\X:, where X: is the drive letter of the file you are interested in.

The post How can I tell whether a file is on an SSD? appeared first on The Old New Thing.

Completing a successful Moon Mission doesn't only involve getting to the moon, but also returning safely to Earth – ideally with some rocks to learn from! Join Dr. G as she draws inspiration from the new Netflix Original Over the Moon and the ingenuity of the NASA Apollo missions to analyze and clean data to predict how much moon rock astronauts might be able to bring back as part of the Artemis Program in 2024. No coding experience required, and you can follow along with the free Microsoft Learn lessons at https://aka.ms/LearnWithDrG/OverTheMoon.

Visual Studio Code Environment Setup:
https://aka.ms/LearnOnVSCode
https://code.visualstudio.com/docs/python/data-science-tutorial

Lunar Rocks Curation Site:
https://curator.jsc.nasa.gov/lunar/