Shrivatsa Upadhye

The need for scaling applications based on demand and usage has given rise to infrastructure services like kubernetes(K8s) and serverless paragidm (includes serverless functions). Intially, the applications were built with a single infrastructure in focus. Either it was instances only with auto-scaling or kubernetes environment or pure serverless applications. But as the application architectures’ have evolved, the services are being deployed across a combination of environments like kubernetes plus serverless functions or instances plus kubernetes.

Authorization decides whether a particular user/service is allowed access to a particular route, service or resource. This is where JWT comes into the picture. It has a small overhead and it works across different domains. JWT Concepts JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. It’s one of the most popular ways of authentication. It’s an encoded string that can contain any amount of data and it is cryptographically signed (by the server side).

A couple of weeks ago, I was working on automating my home with Smart IoT Devices. One of the devices I bought was a set of smart bulbs that could be controlled with voice assistants like Alexa. But I couldn’t control all the features of the smart bulb with it. So I started writing my own Alexa Skill to support those features by using the APIs provided by the manufacturer of the smart device. Building the skill itself was a trivial task, a few methods that invoked a specific API calls on saying an (invocation) phrase and returning the results to the user.

In my previous blog, we discussed 3 different ways of aggregating and processing logs from multiple accounts within AWS. These methods were : 1. Cloudwatch Logs plus Lambda Method 2. Cloudwatch Logs plus AWS SQS (Simple Queue Service) Method 3. Cloudwatch Logs plus AWS Kinesis Method After analyzing the pros and cons based on scenarios, we concluded that using Method #3 is ideal for most of the customers having more than 2 accounts. In this blog, I will walk through step by step process for setting up Method #3 for aggregating logs.

Monitoring of infrastructure resources and applications within the public cloud, like AWS and Azure, is critical for audit, security, and compliance within the accounts. As the enterprises grow the number of accounts, the collection of these logs and events becomes more tedious. A common mechanism to achieve this is to use a separate AWS account for collecting all logs. AWS recommends using a separate account for collecting all the logs. So in case of a breach in other member accounts within an organization, the logs are never compromised.

News about data breaches, leaked customer information and stolen passwords for critical infrastructure are becoming very common. Many of these incidents seem to be related to mismanagement of credentials, unencrypted passwords, secrets being pushed to git repositories or secrets being hard coded within the application, leaving no room for rotation. This has led to increasing demand for Secrets Management tools like AWS Secrets Manager, HashiCorp Vault, Confidant and others. In this blog, we will look at

Cloud Native applications have become a norm these days. Developers and Operations engineers are continuously finding ways to improve the quality and speed of deploying and maintaining these applications. It started with folks writing bash scripts, migrating to python like scripting and then over to configuration management and infrastructure as code tools. The philosophy behind these Infrastructure as Code and Configuration Management tools is to treat your infrastructure as programmable assets. That also means use of version control systems like Git.