Showing posts from 2019

JVM Garbage Collection and Optimizations

Overview When troubleshooting systems for performance-related issues, memory optimizations are a place that needs a deep analysis of what each system stores in the memory, how long those are stored, and access patterns. This post is to keep a note on the background information and valuable points to note in such an effort, specific to Java-based implementations as a deep understanding of the JVM behaviors is very beneficial in the process.

Java language provides much convenience to the developers by taking care of the memory management to a great extent letting the focus be on the rest of the logic. Still having a good understanding of how Java does this underneath, rationalize several best practices we follow in Java implementations and help design the programs better and think seriously on some aspects that can later lead to memory leaks and system stability in the long run. Java Garbage Collector has a big role in this been responsible for freeing up memory by removing memory gar…

OPA for HTTP Authorization

Open Policy Agent[1] is a promising, light weight and very generic policy engine to govern authorization is any type of domain. I found this comparion[2] very attractive in evaluating OPA for a project I am currently working on, where they demonstrate how OPA can cater same functionality defined in RBAC, RBAC with Seperation of Duty, ABAC and XACML.  
Here are the steps to a brief demonstration of OPA used for HTTP API authorization based on the sample [3], taking it another level up.
Running OPA Server First we need to download OPA from [4], based on the operating system we are running on.  For linux, curl -L -o opa Make it executable, chmod 755 ./opa Once done, we can start OPA policy engine as a server.
./opa run --server Define Data and Rules Next we need to load data and authorization rules to the server, so it can make decisions. OPA defines these in files in the format of .rego. Below is a sample …

SPIFFE in a Nutshell

SPIFFE in a Nutshell I have been studying SPIFEE(Secure Production Identity Framework For Everyone)[1] for for sometime and here I am drafting the flow as I have understand now, for the benefit of anyone else trying to understand the flow. 
Identity Registry - SPIRE server has a own identity registry which keeps two coarse-grained attributes that decides how the SPIFFE IDs will be issued to a workload. It keeps details as in the below table.
SPIFFE ID Node Selector Process Selector spiffe:// aws:ec2:1234 k8s:namespace:1234 spiffe:// token:7236427472 unix:uid:1002

A separate registration API is provided to manage these entries in the identity registry.

Node Selector - This defines a machine (physical or virtual) where a workload can be running on. The exact type of selector to be used is decided based on the infrastructure provider (AWS, GCP, bare metal) that the workload is running. Eg. AWS EC2 Instance ID, a serial number of a physical machine. Node attestor act base…