That said - thinking this through some more I wonder if we could give an AI agent elaborate rules on what is and/or isn't acceptable through an MCP and let it do that "peer review"...
It is a bit of a different thing than pipelines because in every organisation I've worked at you're expected to have a peer review via pull request for anything going to production - and that is before the change is merged/pipeline triggered. The idea is that anything super-nefarious should be caught by the peer during the PR review and questioned/denied before it can happen.
I doubt we'll want each prompt we make that could leverage an MCP to be peer reviewed beforehand in the same way.
At first glance this feels very much like GKE Autopilot and/or AKS Automatic. So now all three cloud providers have a more-fully-managed managed Kubernetes.
Part of the reason why they are including the managed add-ons is that they likely are going to be blocking your ability to escape your container with privileged DaemonSets to run things like those yourself in this model. GKE did something similar but eventually had to build a program for their security and observability partners to have their agent DaemonSets allow-listed through their block so that their tools could run on Autopilot - https://cloud.google.com/kubernetes-engine/docs/resources/au.... We'll see if AWS ends up doing a similar thing there too.
I have been in a platform team who tends towards analysis-paralysis and wanting to not use any of the managed EKS stuff as well as a security/compliance team getting more active/aggressive around our K8s. So it might be nice actually to just have fewer choices "e.g. sorry - we have to use the AWS CNI / Load Balancer Controller because EKS Auto" as well as throw more of the compliance stuff over the fence at AWS (assuming they get all the usual compliance certs on it).
But I am sure there'll be some sort of limitation(s) that keeps us from using it for the foreseeable future - so I am not getting my hopes up in the short term...
I work for an Enterprise SaaS company who has a "Contact Us" pricing and fully agree with the sentiment. This is how it was explained to me:
* Since we sell mainly to Enterprise they all have procurement people who get measured on how much money they save - with some getting crazy bonuses if they can "save" 50%. So we needed to keep the price inflated by 50% until it gets to them so they can "twist our arm" down to the real price to show their value.
* And if a procurement person can get that 50% off our competitor such that the deal with them makes them look better they'll pick them instead.
* And when we used to put that 2X the real price price on our website some people wouldn't know to twist our arm for the discount and instead just thought we were too expensive. It was also abused by our competitors who were all "Contact Us" to make out they were cheaper than us without giving us the chance to compete.
So instead we do this stupid dance that I hate where we can't even tell the real price to the people in the early meetings (keeping that for procurement at the end of the process) - and we have to do all this fishing to find out who else they are looking at and what their price is that we have to beat before giving them our price. The entire purpose of our Sales Execs is to do this dance to decide whether to give a price and which price they tell to various people at the various stages as far as I can tell - though they actually are pretty good at it...
I came from Amazon where the price was public as were the mechanisms to lower it through various types of commitment so I found the whole thing ridiculous. I have since learned that everybody does it this way and this seems to be the reason. I argued "maybe if we are the one who doesn't in our space then we'll get more business for being the easiest one to deal with?" but I was assured that was not the case and it would just mean procurement people would want 50% off our best price instead...
This feels like when a mining company has to remediate/recreclamate their mine(s) at the end of their useful life rather than leave them there to cause people problems in the future.
IE11 has long since needed to die and I am glad that MS is doing the right thing for the world and cleaning up the mess on its way out!
One thing I was surprised by recently as an American ex-pat (living in Australia for years) too was tipping housekeeping in hotels. I was told by an American colleague on a recent trip there that I was meant to leave $5 in the room every day for housekeeping. This was because it might be somebody different every day - and I was expected to directly recognise each one.
I have gotten used to not having to carry/worry about cash and the idea I need all these $5 notes whenever I stayed in a hotel in the States stressed me out a bit.
I moved to Australia from the US in 2006. I swear that when I left the tip was more like ~15% (as the sales tax where I was was 7.5% and the rule was that you doubled the tax to work it out). Every couple years I'd go back and it would seem to creep up. All of the sudden it was 20% and, then when I was back last year, somebody told me 20% was minimum and 25% was really more expected if the service was good.
The last time I was there I was out with 6 people and the bill was $500 and I watched them tip $150 (and then expect us all to evenly split it). The service was not exceptional - if anything I remember waiting ages to get the second drink and the bill. I am sure that person was working at least 5 tables (likely more) and you'd think at least a couple sittings so they'd be making some quite good money for a night at those kinds of numbers.
I made a bit of a comment about how it felt generous and they said "if you can't afford to tip like this you can't afford to go out to eat in America" - and I remember feeling things had gone way too far. It is a bit of a strange flex?
I am an American who has been living in Sydney for years and who stopped tipping here after getting used to it not being expected - but it has gotten a little weird/muddied of late. First it was Uber and the food delivery apps - and I did tip there because the app asked and I knew that in the gig economy the workers were not paid well (unlike others in Australia).
Then I have been to a few restaurants lately that the card machine (often a US-based one like Square) asks for a tip as a mandatory thing (i.e. you have to say no or type 0 to get past it). And the waiter/waitress will stand behind you watching/waiting with the machine they bring to your table. This never happened before - and I do admit that I have started leaving $10-$20 or something if I was happy with the service when this has been forced on me (depending on the size of the bill and the mood I've been in).
I did this with a work drinks with a customer the other day and my Aussie boss called me out on it "what is this tip on here - we don't do this in Australia". And I was like "I was in front of a customer the machine asked me - did you want me to say zero and possibly look cheap/unkind?".
So it is somewhat creeping into things here. Curious the views of other Aussies on how they are dealing with it? Am I just slipping back into this because I am an American and was used to it being a thing?
This is yet another amazing cherry-on-top of an amazing product. I switched Internet providers a couple months ago and was horrified to find that I was now behind a CGNAT. I went looking for a solution to reach my home lab on the go and found Tailscale. Tailscale solved that issue - and I actually had the epiphany that if I couldn't reach my home network without it then nobody else could either. So, maybe the CGNAT is actually a big security benefit in that way - but I digress.
I originally was thinking of it like a network-level VPN but realised if I installed it on everything individually it would give me DNS and HTTPS certs for all the machines in my home lab - that work from anywhere as long as my laptop was connected to Tailscale. That is something I always wanted to do with let's encrypt but never got around to. And now this!
It has really inspired my imagination. I've been running labs teaching 5-15 people k8s and k8s security out of AWS but this means I might be able to just run a bunch of VMs in my home lab all with Tailscale loaded and point people easily at them all. Maybe with code-server (VS code in a browser) on them to give them a browser-based terminal. And that is just one possible usecase...
Thank you Tailscale people - it is such a great product that has exceeded all my expectations!
The difference is that AWS support can recover them and will help you. In that way it is a service not a tool. They are also the support team for the services that are being provisioned/managed so it is "one throat to choke".
On the contrary, I have seen many many destructive terraform applies that really messed everything up - without a helpful support team to call (unless you are paying Hashicorp) that can just get you out of the jam.
Yes it is a bit slower and often you need to wait for it to rollback when something goes wrong - but 9 times out of 10 that rollback succeeds. I'll take that trade-off...
I worked on the cloud/DevOps team of a big customer for more than 5 years then as an AWS SA for almost 5 after that. Now I work for an AWS security partner.
Ahh sorry. AWS IAM is a good model it just struggles to scale to ~13,000 possible API actions in the platform as it’s grown. The models all have trade-offs - but the fact Kubernetes pretty much used the original AWS IAM model for their RBAC so many years later shows it is a good one…
CDK 'compiles' CloudFormation templates basically making it much easier to write using TypeScript/Python/Java/C# instead of JSON/YAML.
The real thing is does though is give you higher-level object-oriented constructs with best practices baked in. It has much more sensible defaults baked in and, almost ironically, the fewer parameters you pass to these classes the more opinionated CloudFormation comes out.
The example that blew my mind is if you don't specify a password for RDS it provisions an AWS SecretsManager Secret, generates a random password and puts it in there and then tells the RDS to use that Secret. If you do specify a password it doesn't do that stuff. Lots of stuff like that - it turns encryption on by default and creates the keys if you don't specify, it creates private subnets and a NAT gateway for VPCs if you don't specify.
It was basically "its too hard to fix the service APIs or their CloudFormation so we'll fix the problem outside of / on top of them with a tool users run on their laptops or in their pipelines to deal with generating the thousands of lines of CF boilerplate that are required to really do the right thing these days.
Of course you can be very explicit in most of these constructs and the more explicit you are about what you want the less of its opinions happen.
If you are developing a simple service that only needs access to an S3 bucket and a DynamoDB table etc. at runtime then it is pretty straightforward to write the explicit allows to the right resources afforded in the 'base' AWS IAM.
Where things usually get tricky is for the CI/CD pipelines and/or the administrative users that need way more access. It is very hard to scope to true least privilege - including for things like lots of ECS/Fargate where you don't want people to mess with each other's Task Definitions/Tasks/Services hosted within the same AWS account for one example. The various AWS services are very hit-and-miss for how well you can scope resources and what conditions they offer you.
Security will say "no resource star" which is a best practice but quite difficult to get right in most larger accounts. Permission Boundaries help in being able to flip the conversation to "lets list all the things these users/pipelines shouldn't be able to do instead of what they should to then constrain the more wildcard-y/star-y IAM policy we need." But even those are getting harder these days because there is soo much you don't want your average operator/admin to be able to do too.
Usually people throw up their hands and over-provision generally or give each team their own AWS account and overly permissive access within it - but ring-fenced to their own stuff at least as a risk trade-off. Though I think the pendulum may be swinging back from a bazillion AWS accounts (with all those problems) back to trying to solve the IAM problem with additional new tools (CIEMs etc) that will help them to manage IAM as-a-service with a pretty UI or by letting you scope down users/roles to only the activity they have done within the last 7 days etc.
There is a great line that "complexity isn't created or destroyed - it is just made somebody else's problem" - do you want to make these an AWS IAM problem or an AWS account-management problem? A pipeline/automation problem or a heavily-staffed security team who can write great IAM policies/PBs/SCPs problem? A SaaS vendor we can procure a CIEM from problem? etc.
The author was doing the right thing with explaining it only makes sense when you know the history of how we got to where we are - but there is a bit more to it. It is all a series of band-aids. Band-aids all the way down. As somebody who has been involved with AWS since 2012 I've seen them all get added incrementally in response to explosions in usage and complexity and customer unhappiness and frustration.
Explicit allows being all you can do in an IAM policy were easy(ish) when there was a handful of AWS services and API actions. As there were more and more services and policy actions etc. they became unwieldy. Enter Permission Boundaries where you could wrap a few explicit denies around them. Kubernetes RBAC is nearly at the same place and could now really use those too - but I digress.
Also, early on in my AWS journey, even two accounts (one non-prod and one prod) was only done half the time and viewed as a best practice to think about - people genrally just opened one AWS account. But when IAM wasn't enough (i.e. there wasn't enough granularity on the resources or the conditions exposed etc.) the answer became separate AWS accounts as the only, or at least the easiest, way enforce these authorization boundaries/separations with a blunt instrument you could trust. It also helped to keep your bills straight before they would do things like break them down by Tag.
Then you often needed cross-account role assumptions to deal with the inevitable cases where things or people needed access between these accounts.
Then the explosion in AWS Accounts led to AWS Organizations to provision and manage them all. And it built in Service Control Policies and OUs as a tool/layer to help further manage/constrain IAM policies/permissions (IAM policies, Permission Boundaries and SCPs now being in a venn diagram with each other these days).
But AWS Organizations managing heaps of accounts was also too painful to use and get right and so they brought in AWS Control Tower to help make setting up Organizations easier.
So, in short, this all makes sense when you understand the inability to totally rewrite/refactor important complex systems used by customers (breaking backward compatibility) and instead trying to keep solving all the challenges with an steady stream of incremental band-aids that you can announce at re:Invent.