rtempaccount1

Let me guess, Big-4? boutiques in the UK don't usually charge that kind of day-rate and the big banks all use their purchasing power to get day rates down.

£800/day is low, but not unheard of especially if you use freelancers/small boutiques, but £2k/days is more than I've seen for most things in the UK.

Very interesting article, if a bit worrying for the UK's economy in the short/medium term.

I think it could well be right that they're hoping for the (likely impossible) blink from the EU, but between that, the heavy political toll a US trade deal would require (it would have a big impact on the UK farming community+possibly other areas) and the expanding spat with China, it's really not shaping up to be a good period, economically speaking.

Indeed they are not. What I find a bit puzzling is that the UK Gov. absolutely had an easy escape hatch from the cliff edge of end of 2020, by saying "we've got to delay due to the pandemic" I don't think many people would have complained if they had.

Instead they explicitly rejected that opportunity and carried onwards...

I'd imagine it depends on how much attention the operators in this marketplace have been paying.

If they've believed UK Government rhetoric about how Brexit will be a smooth process that will enhance the UK's trading opportunities, this may come as a surprise.

There are (IMO) a reasonable number of UK citizens and businesses who haven't grasped the likely consequences of what's happening on 1/1/21

kube-ps1, kubectx and kubens can help quite a bit here. kube-ps1 to give you a visual indication of current context and the others to make switching easier.

You can also explicitly add namespaces to manifests, which help avoid applying to the wrong namespace.

Interesting looking project, although at the moment it's only useful for a small range of issues.

One of the harder parts of vulnerability scanning is building and maintaining the plugin database. Nessus, which is one of the older and better known VA tools has 10's of thousands of plugins...

There are other, open source, vulnerability scanning tools available as well like OpenVAS https://www.openvas.org/

The people who "win" at Pyramid schemes aren't (IMO OFC) winning through luck, they're winning by being the people that set them up.

And in the US and many other countries gambling is regulated, so that the games have certain parameters and the risks are known, can't see that being applied to pyramid schemes.

Ultimately the end of any pyramid scheme is a large number of people losing money , often money they can't afford to lose.

It doesn't seem likely to be in the interests of most governments to actively encourage straight Ponzi schemes as when the people at the bottom of the pyramid lose their money, they may end up requiring state assistance, transferring the risk to taxpayers.

I'd agree that k8s has a lot of functionality built-in, another important thing to realise is what k8s doesn't do.

In addition to the well-known integration points (Container Runtime/Network/Storage Interfaces), there's things like the lack of a good built-in user authentication mechanism with Kubernetes, which means you pretty much always need some external authentication service for your clusters.

That's not too bad if your on one of the big managed providers (GKE/AKS/EKS) but can get complex for people who want to deploy on-prem.

The problem with Uber et al, is not that they cannot become profitable, but that they cannot become sufficiently profitable to justify their valuations.

Uber has burned through many billions of investor cash. To show a reasonable return on that cash it would need to generate not just profit, but a lot of it.

Whether it can do that in markets like taxi's and food delivery is a quite debatable point as competitors will continue to spring up quickly especially when Uber tries to put the prices up enough to generate the kind of profts needed at their scale.

That theory implies a significant barrier to entry for new competitors.

In some markets that is justified. Those where significant infrastructure is needed to compete. For example Amazon's network of warehouses and datacentres would be hard for a competitor to replicate at scale.

For other markets, that's not justified. For example Uber, a small scale competitor can operate with some taxi's and an app. They won't have all of Uber's capabilities for sure, but they can compete in a locality.

Within the same pod sure, they share the same netns. I was talking about individual container comms.

With rootless podman they use slirp4netns and all get the same IP, with rootful podman or Docker a bridge network is established so that containers that aren't in the same pod can communicate with each other.

LXC takes quite a different approach to containerization compared to Docker (e.g. running full systems in containers by default, instead of a single application process)

What is it about their approach that you feel is superior?

Podman when not run as root has some significant drawbacks (e.g. containers can't communicate with each other). That's not specific to podman it's just hard to do without root.

Podman has long running processes as well, there's a podman process that'll run once you've launched at least one containner, and a conmon for each container (equivalent to containerd-shim)

Packaged directly... it is by RH and SUSE, don't think by debian/ubuntu. At least for ubuntu, 20.04 packages Docker 19.03 just fine.

complexity and overhead. Maintaining Kubernetes is non-trivial (IMO ofc). It has a 9 month support lifecycle, so you need to redeploy everything regularly. There are also API deprecations to deal with periodically, which if you're not keeping up with k8s developments, could be disruptive.

From a complexity perspective, you're adding more places for things to break. Instead of (say) running your apps in containers with Docker, you add pods, services and ingress as layers, which is more places for things to go wrong.

I think what type of k8s environment you use very much depends on what you're looking to get out of it.

If it's experience deploying applications into containerized environments, then micro-k8s and k3s seem like reasonable choices, you don't really care about the setup of the underlying components, just that they present the k8s API.

If you're looking for experience of managing k8s clusters, then either the distribution you're looking to run in prod. or something like kubeadm are perhaps a better option. kubeadm is very "vanilla" in terms of how it's deployed so it's quite representative of production (on-prem) deployments, perhaps unlike k3s which makes changes to how k8s works.

If you're looking to quickly test things in k8s, I'd recommend kind as the easiest way to stand up and remove clusters quickly.

And if you're looking for something to run your home services long term, I would recommend not using Kubernetes :) (unless you have a really complex home network which might justify adding k8s to the mix)

except of course where the system is ossified and you can no longer make changes for fear of affecting that lack of downtime.

In the organizations I've seen with mainframes, what happened was a panoply of supporting systems sprung up where new requirements existed as everyone was afraid of making significant changes to the mainframe environment.

There is a middle ground between those two extremes of course.

I'm not surprised at the mainframe's lack of success at all, the barriers to entry are extreme, meaning there's an inevitable lack of activity.

I've worked in environments which had mainframes deployed and even as an employee it was inordinately difficult to get any access to them.

Combine that with IBM's "enterprise" sales process and it's not a mystery that they lost the fight to attract newer systems...

In many cases (e.g. banks) these systems have been running for decades, they're often badly documented and have had a lot of fixes applied for issues that arise.

Re-writing that, is going to be a nightmare, as you've got no spec. to work from and mistakes may not show up immediately (think monthly or annual payment processes)

It's a very high risk endevour with little immediate reward for the team doing it. If it goes perfectly, no-one notices, if it goes badly it could seriously impact your whole company.

I was at a talk about mainframe security recently where the state of play with one company was, there were three users in their admins group for the mainframe, two had retired, and the third was past retirement age...

When you combine retirements with decades of under-documented code doing critical functions, it's not a recipe for good long term success...

The user who runs the docker command can indeed always get root (with a default install, assuming you're not using rootless) but the process inside the container isn't going to necessarily breakout.

That's why --privileged is generally a bad idea, unless you really need it, as it removes the isolation that Docker adds.

Docker has a number of security layers that can make breakout more challenging, specifically dropped capabilities, a seccomp filter and (on debian/ubuntu) an AppArmor profile installed.

I wouldn't agree that it's trivially possible to breakout of a default configured Docker container, not every attacker is packing a Linux Privesc 0-day and the knowledge to use it.

I'd agree with your assessment that RH are more about the enterprise installs.

Whilst the 4.X series of Openshift has been out as a commercial product since mid last year, there's still (AFAIK) no release version of the open source version of okd.

The Openshift 3.X version is now horribly outdated (based on Kubernetes 1.11), so there's no good non-commercial version that I can see...

Any multiple choice exam is going to not necessarily mimic the real world, but doing exams that do is pretty tricky, and I can't think of one in the pentest world that gets it right (e.g. OSCP can't think of any time I've had a 24 hour window for a pentest, whilst sitting in a single room with no assistance and someone watching me from a webcam).

CRT has a practical element which demonstrates knowledge of tools, and the CCT bumps that up quite a bit.

On the second point, I think accusing CREST of financial shenanigans is a bit of a stretch given you think they should make more money than their public accounts show they do.

Wouldn't it make sense that the university, that is charging the students all this money, ensure they have enough parking spaces to satisfy likely demand?

Doesn't seem unreasonable for universities with very high tuitions, to provide amenities like reliably available parking.

My anecodotal info. on CREST, as someone who's been in the industry a while, and has a CREST cert.

The exams (like any) aren't perfect, but if you pass the CCT, you need to at least be pretty familiar with common pentest tooling and able to use them quickly and under pressure of time.

They're not perfect and some have said they could use some updating.

As to CREST being rolling in cash, you'd be surprised to find out that, as far as I can tell, that's not the case.

The main org. is incorporated in the UK, so you can see their financial statements for free https://beta.companieshouse.gov.uk/company/09805375/filing-h... is the list and from a look at their latest accounts, you can see it's not big business...

Ultimately any country/state needs a variety of services, from utilities like water/sewage/electricity to emergency services like ambulance/fire/police to a military to defend what you've got from other countries. you also need things like roads, telecomms infrastructure and other things that have been built over decades/centuries in established countries.

You also need things like a foreign service to liaise with other countries so that the fate of your state isn't the same as the Thai SeaStedding adventure. Then you may also need things in the longer term like social services, pension funds etc to care for your citizens in the long term.

Those all need to be paid for somehow, and that somehow is taxes. A "low tax" environment inevitably has to skimp on those services somehow. I'd guess that these low tax environments intention would be to skimp on the services that richer people don't need in exchange for having those richer people pay less tax...

So I'm not really surprised by the comments in the article that they're having trouble getting "host" countries to buy into this, what's the upside for them? These low tax environments will obviously not provide good long term environments for workers (the low tax is likely to == low social care standards) so it'd seem likely they'll take in workers where it's suitable and ship them back out once they're not productive any more, back to the host countries they came from.

How do you prove the traffic wasn't sent by you, if you don't know the software that was being used to hijack your connection was even installed?

I don't believe that NordVPN make it clear that user's connections could be treated like that (e.g. as bandwidth for other customers)

Unless they make that clear, it's not a great look.