Pushpalanka's Blog

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 https://github.com/open-policy-agent/opa/releases/download/v0.10.3/opa_linux_amd64 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

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://abc.com/bill aws:ec2:1234 k8s:namespace:1234 spiffe://xyz.com/account 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 seria