A long over due update for this year so far. However, we’ve been busy working on three new feature sets. The first of which, we’re releasing today. Identity and access management (IAM) control.

Identity and access management (IAM)

Up until this point its only been possible to give users full access to the platform. With the exception of a few key areas for user specific callbacks e.g. Slack integrations etc.

It is now possible to provide granular access — including additional filters for fine grain control over API requests.

Image for post
Image for post
The Zercurity Identity and access management (IAM) policy generator

The policy management works be defining a JSON policy object which contains a series of policies…


Whats with all the Kubernetes posts? Well, for sometime Zercurity has supported Kubernetes on-premise. However, we’re now bringing it to GitHub alongside our docker-compose setup and soon our helm build.

Why Kubernetes?

Whilst docker-compose is great for smaller and PoC deployments. If you’re looking to support thousands and thousands of clients in a production environment Kubernetes is the way to go for a clustered and highly available deployment.

Installing Zercurity on Kubernetes

This guide is designed to get you up and running with Zercurity on Kubernetes via the provided base configuration. This is designed to be a configuration from which you can pick and customise how…


Following from our last three posts. There are three primary ways of standing up Kubernetes on vSphere. Each with there own benefits and drawbacks. This post will be the final post of our tree part post looking at VMware’s TKGS.

  • Tanzu Kubernetes Grid (TKG)
    Deploy Kubernetes via Tanzu (TKG) without the need for a licensed Tanzu supervisor cluster. This does not provide a load balancer.
  • Tanzu Kubernetes Grid Service (TKGS)
    Deploy and operate Tanzu Kubernetes clusters natively in vSphere with HA Proxy as the load balancer. Without VMware Harbor as a container repository.


Following from our last two posts. There are three primary ways of standing up Kubernetes on vSphere. Each with there own benefits and drawbacks. This post will be the second of three looking at VMwares TKGS.

  • Tanzu Kubernetes Grid (TKG)
    Deploy Kubernetes via Tanzu (TKG) without the need for a licensed Tanzu supervisor cluster. This does not provide a load balancer.
  • Tanzu Kubernetes Grid Service (TKGS)
    Deploy and operate Tanzu Kubernetes clusters natively in vSphere with HA Proxy as the load balancer. Without VMware Harbor as a container repository. …


There are three primary ways of standing up Kubernetes on vSphere. Each with there own benefits and drawbacks. This post will be the first of three looking at VMwares TKGS.

  • Tanzu Kubernetes Grid (TKG)
    Deploy Kubernetes via Tanzu (TKG) without the need for a licensed Tanzu supervisor cluster. This does not provide a load balancer.
  • Tanzu Kubernetes Grid Service (TKGS)
    Deploy and operate Tanzu Kubernetes clusters natively in vSphere with HA Proxy as the load balancer. Without VMware Harbor as a container repository. …


There are lots of ways to use Osquery to query the underlying system. However, no one wants a slow computer.

Image for post
Image for post
Performance testing and bench-marking Osquery queries

Some query methods are more performant than others especially when joining tables. Or continually querying from non-cache-able tables with high disk reads. Whilst we’re not going to dive into too many examples. I do want to look at the tools Query gives you to monitor and audit, query execution. There are a few things you can do to limit the impact on system performance. As well as some common pitfalls and general optimizations. If you are heavily using certain tables.


There are a number of really useful tables within Osquery to determine information about a systems hard drive. Not least the availability of disk space but the disks encryption status and even some performance metrics.

One thing to bear in mind is that there is no common hard drive table within Osquery. Each operating system platform has its own distinct tables. These tables also need to be joined together in most instances to get a full picture.

Image for post
Image for post
Osquery Windows, Mac OS and Linux disk information and monitoring

Windows

Kicking off with Windows.

Basic disk information

In windows the primary table you’ll want to use to grab a system disk information is the logical_drives table…


As with most tables in Osquery. You can gleam a whole load more information by joining tables together. Or enriching results with external data sources.

The wifi_survey table is a perfect example of this. We’re given all the data we need in order to work out the exact location of our asset via Google’s geolocation services.

Image for post
Image for post
Using wifi_survey to get an assets geolocation.

The wifi_survey table is currently only available for Mac OS as of Osquery 4.6.0. It also goes without saying the asset you’re querying will need a working WiFi card. Which you can check the status of by querying the wifi_status table.

osquery> SELECT interface…


Osquery provides a huge amount of flexibility for querying various different aspects of your system which we’ve covered in many posts. What’s really awesome is Osquery also lets you query Docker containers, images, networks and their respective volumes. Which gives you a great insight into sub-systems running on your host you may not ordinarily be able to inspect with conventional tooling.

Image for post
Image for post
Docker’s logo

As of 4.5.1 there are currently 17 tables within Osquery dedicated to Docker. In this post we’re going to explore each one and see how they work.

Prerequisites

This goes without saying that’ll you’ll obviously need Docker installed and running…


Whilst Osquery provides a huge amount of flexibility for retrieving lots of different pieces of information about a system. Sometimes however, there may be a specific part of the system you’re after that isn’t covered by Osquery’s included tables.

Image for post
Image for post
Augeas configuration parsing within Osquery

Within Osquery there’s a table called augeas it’s super helpful for parsing configuration files across Mac OSX and Linux. Important for tasks like compliance, auditing and checking the configuration of deployed services.

Augeas parses configuration files in their native formats and transforms them into a tree. This tree is then translated into a query-able table by Osquery.

If you’re unfamiliar with…

Zercurity

Real-time security and compliance delivered.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store