by Mark McCullough, Senior Technical Consultant at Taos Information security, infosec for short, is traditionally characterized by Mordac, Preventer of Information Services of Dilbert™ fame, where every improvement in security comes at the cost of usability. That model doesn’t work today. Cloud services creates problems of identity and access management and securing access. BYOD is […]
My son plays baseball. He’s a catcher. As a catcher, he is charged with seeing the entire field of play, and calling actions out to his teammates based on his predictions of what is going down. He’s told me before, “Dad I have a choice, I either catch the game they throw me, or I make them throw the game I want to catch.” If he waits to figure out what he’s going to do if the guy on first tries to steal on the pitch once the guy has started to run. He’ll never stop them from trying to steal. But if he learns the patterns a runner executes when they intend to steal, calls a pitchout, has the shortstop move over to 2nd at the right time. He’ll look like the hero and get the runner out.
I often need to work with multiple AWS accounts. There are personal accounts, business accounts, and various client accounts. This adds up to a lot of different credentials. I need a way of quickly and accurately switching between these various credential sets while making it clear to me which account I’m currently working with.
The CLI is a must for any serious work in AWS, but it doesn’t have a great way of managing multiple accounts or credentials. There is a profile system that can be set up in the ~/.aws/config file but that requires tacking –profile onto every command which is easily forgotten and leads to challenges scripting across multiple environments. Otherwise, the CLI relies on environment variables like AWS_ACCESS_KEY_ID being set.
Attacking overtrodden topics almost always a bad idea. The questions of “what is DevOps” and “what isn’t DevOps” have been used, reused, and rehashed to such an extent that there remains little ground to cover in those arenas. But even though that ground has been walked into a muddy rut, while so many people seem to “get” DevOps to the point that discussing it further seems a pointless waste, many organizational leaders still seem unsatisfied with the answers. If you’re among the unconvinced, unhappy with all the direct and explicit answers that abound, let me tempt you with an esoteric and obscure assertion instead.
When I was finishing up my MS in Project and Systems Management I remember my instructor driving the point home that Project Management was all about working within the triple constraints of cost, schedule, and scope, also known as the Iron Triangle. This was the mantra that drove well-intentioned PMs into the belief that life was simply about triple constraints and if the Iron Triangle was managed properly all was good in the world. In the early 1990’s, as a Program Manager at Santa Cruz Operation (SCO), I learned very quickly that managing to the triple constraints only mattered if:
While advising companies on their AWS environments, a few core issues come up again and again. These issues present real challenges for organizations moving to broader adoption and aren’t easily remedied with a quick fix.
1. Cost Management – Moving away from upfront capital expenditures to on-demand usage based pricing is a primary driver of many clients’ cloud adoption strategy. It’s easy at first. The bills start small, a few hundred or thousand dollars a month. Low enough for someone to expense on a purchasing card. Soon they get bigger, 10’s of thousands per month, then 100’s of thousands. At this point, it is a serious expense and starts raising questions about efficiency and forecasting.
Objects are not completely foreign to Puppet, but the concept of them and their application with regard to the node is vastly different from Chef. The framework that Chef provides you with for building new configuration management objects will cause you to use traditional Ruby programming tools more so than with Puppet, and grant you the insight they do as well. There is a clear distinction between the two frameworks in the level of access to core Ruby features, as noted through gem support in Chef. Attention to execution order is key, regardless of your choice of configuration management system. Together with design characteristics, these subtleties in both systems make for a new and refreshing navigational experience.
A long time back I read Stephen Covey’s classic “7 Habits of Highly Effective People” and leveraged them throughout my career as I progressed into the profession of Project Management. What I discovered is a new set of rules emerged. Even with excellent references like the PMBOK rolling out to help guide PMs, a new secret code came forward that was like the Pirate’s Code in the movie “Pirates of the Caribbean”. This unwritten code sometimes was trumpeted as “law” by some and “guidelines” by others, but the gist is I found those that practiced this code were able to generate massive amounts of churn, get lots of visibility and generate project black holes where companies burn tons of money in a PMO dumpster fire. The net effect was to waste productivity like a Dilbert Zone nightmare and experience scope creep resembling a flesh eating bacteria. The one common characteristic is they all follow this code which I call the “7 Habits of Highly Dysfunctional PMs”. This code is quite entertaining for PMs and provides much excitement and drama in what would be an otherwise mundane and productive life for most project team members.
For anyone coming from a Puppet background, one of the first things you’ll learn about Chef is that it emphasizes programming rather than Puppet’s administrative mindset. In other words, mastering Chef takes a commitment to thinking differently. You’ll want to become intimately familiar, first and foremost, with the concept of Ohai and the Chef node object to advance as quickly as possible, and you’ll need to adjust to a series of quirks. Often, your problems will manifest themselves as programmatic rather than administrative, but troubleshooting them will always come down to a matter of using the ingenuity and accumulation of knowledge you already have. Take everything you remember from Puppet, and use it as an overview of concepts to apply to Chef, as a general rule of thumb. Most importantly, never forget, unlike in Puppet where nearly everything is processed on the server and sent to the client to apply locally, EVERYTHING in Chef is client side.
Cross-site scripting (XSS) attacks are one of the more insidious types of Internet malicious activities because customers of a legitimate website may become victims without any direct compromise of the website, and often even without the site operator’s knowledge. Defending against such attacks can be difficult, but a function incorporated into newer web browsers adds a significant defensive tool against XSS.
A quick review: an XSS attack occurs when an attacker is able to insert malicious content into a legitimate website’s pages. The goal is to use the legitimacy of the targeted site to deliver this malicious content to other visitors. Areas of a web site most often targeted are discussion forums and comment sections, areas specifically intended to receive input from one visitor and display to many others.