cpitman

Yes

How is the "Man in the Middle" concern different from any other CDN, like Akamai? At this point, I assume any major web presence is fronted by a CDN.

I tried it a couple years ago at PAX Unplugged, and that was exactly my reaction. I felt like I was putting a lot of attention into shifting around my direction to frame the AR, and searching for content, because I was looking through a pipe.

What this effectively means though is that we are still tightly scoping who can get tested in the US. My mom is a primary care provider in the DC suburbs, and their hospital system is still limiting tests to medical providers and first responders. People who "obviously" have Covid-19 are just treated, and mild cases are sent home without testing.

That sounds like Buildah (https://github.com/containers/buildah/blob/master/README.md).

Buildah can work with standard Dockerfiles, but it can also do a lot more. For example, you can mount the container filesystem, modify it (say using make), then use those updates as a new layer.

I've run keycloak securing internet facing apps with ~1000 users for years. It's so stable, I usually forget it's even there.

For my more routine analysis of LOE/budget, where it is mostly a straightforward summation, I have a template spreadsheet that I just reuse. For more complex cases, I hand write the equations and error-propagation into a custom sheet. A little time intensive, but it gives me an excuse to practice multi-variable calculus.

I use these techniques for day-to-day estimation in software development, usually for things like project timelines, system requirements, etc.

I often run into developers who think "there is no way to estimate when we will be done". What I think they usually mean is that they cannot estimate a single time in which it will be done, which is completely fair. However, if they are being honest with themselves, I think they can often estimate a range of possible outcomes. Adding a new "Contact Us" form may take a few hours or a few days, but it isn't going to take 1 year.

One of my bigger successes with this kind of model was sizing the resource requirements for a brand new high-performance system that was in it's early stages of development. I created a model that started with what we knew so far from out performance testing, with uncertainty for everything, and projected forward to different confidence levels of sizing. We ended up being pretty having just a little extra, which was perfect considering the multi-month procurement process.

Let me take a stab at this, as a Red Hat architect that spends a lot of time on OpenShift(OCP) implementations:

OpenShift helps mitigate the following, by providing secure defaults. It is totally possible for someone (a cluster level admin) to un-configure these security controls, so keep that in mind.

These are partially mitigated by Red Hat providing trusted image content and having a well oiled machine for patching/CVE response:

* Compromised images in registry (use Red Hat base images, and in-cluster source or docker builds to lock down registry access. Registry not exposed by default.) * Application vulnerability/Application exploit (again, Red Hat base images for runtime, regularly patched by Red Hat. Images have to run as non-root user. Doesn't solve self-created app vulnerabilities)

These are mitigated by OCP's locked down default RBAC:

* Writable host-path (host-path locked down by default. Not sure why host-path is special here though, seems like any PV could be used for persistence) * Privileged container (also locked down, admin must enable for a user/service account) * host-path mount (specifically for getting access to the file system, OCP locks down this via RBAC by default. Layer on SELinux to prevent an escalation from allowing file-system access) * list kubernetes secrets (RBAC to limit scope, and additionally a node can only access secrets for pods scheduled to it, in case node is exploited) * access container service-account (default service-account has pretty limited permissions) * access Kubernetes dashboard (containers have no special access to the console, which requires auth)

These are just miscellaneous config/security controls:

* Exposed dashboard (OCP console has authentication by default, no default passwords) * clear container-logs (built in log aggregation would require an additional exploit to defeat) * cluster internal networking (depends on the sdn plugin, but most installs limit networking to containers in the same namespace by default) * access tiller endpoint (No Helm 2, support for Helm 3 without tiller coming soon. Driven by tiller security/RBAC concerns)

No kidding! Ok, that makes more sense then.

Is that really a limitation of WFH? Even when someone is in the office, if the intent is to bypass monitoring someone can use their phone. I tether my laptop to my phone all the time on client sites (instead of fighting with yet another captive portal).

I've really appreciated that Android has started telling me when apps are pulling my location in the background. Every once in a while I am ok with that application doing it, but for the vast majority I immediately disable that app's location access.

After a couple weeks, I'm much more confident that my location data isn't leaking all over the place.

Does it? I don't think you need to correlate packets, you could probably just block small packets that look like they have only part of the hostname. If they wanted to be slightly more selective, they could block small packets that have a partial hostname and have a prefix that is blocked.

In order for traffic to be open for any substantial time, the technique either has to stay hidden/unpopular or the traffic has to be hard to distinguish from normal traffic.

Alternatively, load has gone up across the board in a short period of time, so that preventive scaling has fallen behind and are in recovery mode.

If Roosevelt enabled/required these back doors, what would stop all future administrations, including the current one, from doing what they want? IE, why is it any different for a past administration to make these changes compared to the current administration? Expansions of executive power tend to be permanent.

Which previous administration would you be ok with passing these laws?

This only makes any sense if you believe that censorship will _only_ be used for misinformation, as opposed to information people do not like. Otherwise, you could end up raising the density of misinformation as "true" information is filtered out.

If YouTube existed a hundred years ago, and censorship of "misinformation" was an accepted practice, would there be any doubt that videos on women's suffrage, black rights, the perils of McCarthyism, that any of those would have stayed up?

I'm always happier when I see a follow up analysis by the Jepsen team, as a third party verification that the issues have been fixed and no major new ones introduced. Any chance Elastic is going to contract out to them for a follow up?

Loki and similar solutions are leveraging object storage (not just Ceph) as a way to store chunks of logs relatively cheaply, and scale performance. Loki can work on a single system, storing logs on the local filesystem, but that will eventually become an availability or performance bottleneck. Putting logs in object storage allows multiple systems to store/query/etc.

One project worth keeping an eye on is Loki (https://github.com/grafana/loki), which eschews full text search for more basic indexing off of "labels", ie it works a lot like prometheus.

There's a writeup on the differences with the EFK stack here: https://github.com/grafana/loki/blob/master/docs/overview/co...

After working with a client for multiple years continually hitting bottlenecks and complexity with the EFK stack, I'm really looking forward to something different.

Different state's Department of Transportation seem to do this themselves! When adjusting lanes on highways, they will paint over the old stripes with "black" paint. During good lighting conditions it is clear what you are supposed to do. But as soon as conditions are worse, like heavy rain in low light, all I can see are crisscrossing lane markers!

So a malicious actor could put black "tape" down on a highway, and just wait for the right conditions for people to get confused.

If you are using public images, then you are already giving up on optimizing image sizes anyways.

It's starting to feel like this is a lost battle though. People have decided that Dockerfiles are "the kubernetes way", even though it exposes developers to details they just shouldn't need to care about.

Add anything on top, and it is no longer "vanilla kubernetes". Never mind that means everyone roles their own Rube Goldberg build process, and somehow that is ok...

I don't see what would have changed. Most large companies still have arcane reporting structures and strong silos that prevent clear communication and collaboration.

Not really. From our perspective, IBM is a partner (we have lots of those) that we just happen to have alignment on both sides to work more with. That means that on the sales side we spend more time trying to find ways to collaborate. Usually there is this long awkward dance with a partner, where you're not sure who is committed and how committed they are. The IBM acquisition cuts a lot of that out, we know that we're tied together so we have to figure out how to partner together, even if we are two separate companies.

On the actual consulting side, 95%+ of consultants have seen no impact. Those that are being impacted are working on projects that have more IBM products involved. For example, some of my team is starting to work with OpenShift on Z.

I agree, as a consultant I have grown into a generalist over time, and consulting rewards those that do.

As a concrete example, I'm at Red Hat Consulting. We have products that range from RHEL, to Kubernetes/OpenShift, to language runtimes/tools/middleware, and finally to more process focussed transformation. You can specialize, but the more of these you are competent in the more useful you become. I am in more of a leadership role now, and in any one project I am likely involved in all of the above.

The key skills you haven't mentioned are the "Soft" skills: mentoring, client facing leadership, presentation skills, etc. If these are a strength for you, then consulting would be perfect.

Shameless plug at the end, Red Hat is hiring: https://careers-redhat.icims.com/jobs/search?ss=1&searchCate...

My first internship was with Intel in the early 2000's with the group that was designing Intel's Infiniband NICs. Between when I accepted the internship and started they already knew they were going to abandon that product development, and the engineering group was all getting moved to chipset development. I got to catalog discontinued hardware.

The one thing it is not is Federal government Shutdown proof (https://www.washingtonpost.com/local/shutdown-is-an-unwelcom...). Diversification is valuable in itself.

This is great, thanks for sharing.

Sure, distribute your own root CA, but then how do people get signed certificates? I tend to work with large companies, where getting a signed certificate involves opening a ticket and waiting for someone on the other side to respond.

ACME would be ideal, but the official response of Let's Encrypt is that ACME is overkill for corporate environments and you should roll your own certificate automation.