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.
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.
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.
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.
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.
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.
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.
There are lots of ways to use Osquery to query the underlying system. However, no one wants a slow computer.
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.
Kicking off with Windows.
In windows the primary table you’ll want to use to grab a system disk information is the
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.
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.
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
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.
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.
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.
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.
Real-time security and compliance delivered.