Your Serverless function has a secret... maybe it's a password for a remote API, a private key, or signing certificate. These secrets have to be stored somewhere, and in the old days that usually meant just a plaintext config file on your server. Sure, you could encrypt it, but then you have to put the key on the server, and you haven't gained anything except a bit of obfuscation. Or you could use more complex schemes, like Hiera-Eyaml, which is a small improvement, but you've really just moved the threat to a different part of your infrastructure.
Getting Started with Documentation
Whether you’re running on premise datacenter, using a private or public IaaS (Infrastructure as a Service) hosting platform, security is extremely important. We’ve all seen the horror stories in the news when companies experience data security breaches. The fact of the matter is no one wants to end up in this position and there are tons of bad actors on the internet that have malicious intent.
Last year, I wrote a blog about the performance of various NFS Solutions in AWS. Earlier this year, Amazon announced its own NFS Solution called Elastic File System, “EFS”. I wanted to test EFS the same way and measure its performance compared to the other NFS Solutions I had tested and used in the past.
Amazon Web Service recently introduced support for cross-account roles. What this now means, is that you can use one IAM account to access multiple AWS accounts. For the Metal Toad Managed Services team, this means less logins to keep track of, resulting in higher security for our Custom Cloud clients, as well as a great level of convenience for our Cloud Engineers when they need to switch to the AWS Console for a different client.
Here's part 2 in the series explaining our "full stack" at a high level. If you missed part 1, make sure to give it a read first. If you prefer, you can read the long-form post with all the content in one. Again, feel free to call me on any technicalities or suggest changes/additions in the comments!