The post glossed over how exactly they detected session hijacking. They mentioned “This detection looks for suspicious sessions appearing without an authentication event that are consistent with session hijacking.”, but authentication obviously happened at some point, otherwise the session wouldn’t exist. I’m guessing this is a complicated way of saying the IP changed since login.

Of course the easiest solution is you shouldn’t voluntarily share HAR files for an active session.

How they detected it can be found at the bottom of the blogpost:

> *Indicators of Compromise*

> ...

> Okta activity for a user without any clear indication that the user authenticated (e.g. a user.session.start event for that user from a similar geographic area)

It’s weird to complain about supporting AEG claiming they’re somehow the 2nd “monopoly” after LiveNation. You can only have one “monopoly” in a given industry, otherwise they’re both just close competitors.

Having a close second competitor is still a step in the right direction, even if you disagree with their business practices.

Fine. I used the wrong term. You can't argue anything else I wrote outside of the word "monopoly" though, sooooo...

That’s not true. You can have two or more companies share a market via market splitting and the result is still effectively a monopoly.

That would be a duopoly not a monopoly.

Perhaps. It still sucks for the same reasons.

It sounds like this builds on top of Ethernet to provide a higher performance alternative to UDP/TCP, with some sort of hardware acceleration.

I may be in over my head since I’m not an HPC/datacenter expert, but not sure I understand how you’d use this on the software side. Maybe someone is aware of specific examples? (beyond the vague “HPC/AI”)

edit: as another comment mentioned, the diagram shows it’s on top of UDP/IP, so it’s mostly an alternative to TCP/IP

From a software perspective you probably wouldn't see Falcon at all. You'd use, say, the RDMA verbs API and under the hood it's accelerated by Falcon.

It sounds like they’re trying to emulate Disney/Universal to some extent. I can imagine them having themed restaurants, gift shops, etc. similar to what you see in theme parks.

Technically that’s always been the case. It’s just that now you can tell the computer what to do in a “natural language” like English instead of a “programming language”.

We have reached a point where the computer no longer does exactly that we tell it to do :P I always though of computers being stupid, but very fast. With AI they are slow, and make human errors :P

I've been writing software for 35+ years, and the computer has frequently done something other than what I thought I told it to.

Turns out that I'm not as good at telling computers what to do as I'd like to think.

With the right GPU they can make mistakes almost at the speed of thought.

And now we intentionally tell the computer to ignore what it is told if it’s isn’t deemed proper by the mega corps.

It is true that this is somewhat influenced by how Heroku works, but ConfigMaps and GitOps do not meet the same security and usability requirements as Heroku config/env vars.

If you want secure config storage on Kubernetes, you end up using Secrets, which ends up being key-value like env vars anyway. If you want similar security with Git you need a layer of encryption, which breaks diffs and requires additional tooling. This all leads back to why high-level deployment tools like Heroku were created.

> If you want secure config storage on Kubernetes, you end up using Secrets, which ends up being key-value like env vars anyway.

You can load the secret file directly into the app, no need to load it as env vars or keep it strictly as key-value pairs.

> If you want similar security with Git you need a layer of encryption, which breaks diffs and requires additional tooling. This all leads back to why high-level deployment tools like Heroku were created.

You can use tools like ejson[1] or sops[2] to get encrypted files checked into Git that have key level granularity on diffs.

There is definitely a place for higher level abstractions than Kubernetes. Mostly it gives operators a standard platform to build from when teams outgrow the PaaS sandbox.

[1] https://github.com/Shopify/ejson [2] https://github.com/getsops/sops

> You can load the secret file directly into the app

Now you're getting away from the spirit of 12factor and hard-coupling them again. The intent is for the app to consume the secrets but have no knowledge or care where they came from.

Edit: misread as "load the secrets directly into the app." Yeah, this is just env vars but different.

My trick for this with k8s Secrets, when there's some sort of config file that absolutely must be consumed from disk, is to

1. create a Secret that defines the file as a key

2. mount that Secret into the container (.secret.secretName in the volume definition) under an arbitrary conventional path, e.g. /secrets

3. define an env-var that gives the full path to the file; where the fallback when this env-var isn't defined is to find the file in the working directory with a conventional filename.

If your own code uses the file, it can read the path from this env-var; while if the core of your container is some opaque tool that doesn't know about the env-var but does take the file's path on the command-line, then you can wrap the tool in an entrypoint script that reads the env-var and passes it as a command-line arg to the tool.

IMHO, this approach is flexible but principle-of-least-surprise obeying for both development and production deployment.

That sounds an awful lot like a .env file to me.

yup thats exactly what .env is, and tbh that doesn't change anything in the bigger picture

...no? It's the opposite.

A .env file allows you to go from knowing/assuming where a particular file is, to having environment variables.

What I'm describing is that you can go from being passed environment variables directly, to knowing where certain files are; which therefore allows those files to be mounted into a container-image in arbitrary places, rather than encoding brittle assumptions about config-file locations into the binary within the container-image — assumptions that usually get in the way during development, when you're not running the binary inside a container.

You still didn't understand my point. The thing that I'm talking about is using env-vars to point at config files that do not themselves contain env-vars, but rather are opaque app-specific config files, in formats like YAML or whatever-else.

I don't use kubernates. We have JVM servers running on AWS. We load secrets from Secrets Manager. Configs are mostly HOCON files stored in S3. The knowledge of where to find them is configured via env vars.

We use a custom setup in which the config values are loaded from multiple sources actually, so we could put everything into secrets manager, or load them all from env vars or HOCON files.

If we had to set every config value in ECS / lambda using env vars, it would be a major pain in the ass, and error prone.

> We load secrets from Secrets Manager

And how your apps authenticate to Secrets Manager ? Did you ever call `env` on a pod that has IRSA configured ?

This is just a middle step to do exactly the same thing but instead of using envFromSecret you use envFromSM

Not OP but an IAM role with scoped access to secrets. Better again, using secretsFrom in the task definition which injects the secret as an environment variable for you.

IRSA in pods and containers is translated to env vars. That was the point.

That if you dont want to pull in k8s dependencies to the code, at the end every approach ends up as a mounted file or env vars.

> Now you're getting away from the spirit of 12factor

The entire point here is that 12-factor isn't the be-all, end-all, so this is irrelevant.

> The intent is for the app to consume the secrets but have no knowledge or care where they came from.

This doesn't really make sense, and is an impossible requirement. The app will always have to know where configuration or secrets come from. Environment variables is just one option of "knowing where they come from". Choosing file storage is just as valid.

I'm not really kubernetes expert, but don't they come from /my-secrets and the application doesn't need to care how that got mounted?

> somewhat influenced by how Heroku works

The Twelve-Factor App is marketing content produced by the former Founder & CTO of Heroku. It's a great piece of content no doubt, but it should be viewed with that lens.

If it's marketing content then it's not doing a very good job. I have known about the 12factor app principles for a long time, and only found out today that it has ties to Heroku.

Still, Heroku would look impressively good if you wanted to deploy a 12-factor app, won't it?

Not all marketing is that straightforward.

Likewise.

ExternalSecrets with K8s. Put them into SOPS, Vault, your cloud’s secrets handler etc. - then reference them in the app as though they exist. They get loaded at deployment.

Doesn't break diffs, doesn’t directly couple anything.

I'd say 99% of my configs are not secret, at least not from containers running nearby.

I'm fine reading a few passwords and tokens from a secure key-value store. But the rest of my config can be a bit more expressive.

I wonder why there hasn’t been more effort behind replacing single use plastics for food/beverages. People get all up in arms about plastic straws, but then stick their paper straw in a big plastic single-use cup.

I also find it sad that some companies like Snapple are regressing, changing from glass to plastic bottles.

Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages.

That said, the “infrastructure-from-code” idea is interesting. I’m not a big fan of coupling your code to your infra, but I’m intrigued by the idea of inferring infra dependencies from existing application code.

My productivity in rust is so much higher because of the help I get on correctness. It's not even remotely a competition.

> Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages.

I have to admit that I have limited experience working deeply with Rust, but I've found thus far that my relative productivity is inversely proportional to the size of the project. That is, for large projects, Rust is much more productive than other languages. For small ones, less productive.

The type system makes development much faster than with a language that doesn't have a strong type system.

You got that right. What Shuttle is trying to do, among other things, is to extract the difficulties of getting started, especially in a language like Rust, so that you can focus on writing good code and moving fast (when moving fast is a requirement).

If you find the “infrastructure from code” idea intriguing, then maybe take a look at https://www.winglang.io

It’s a new startup by an ex-engineer on the AWS CDK team.

this is wild

I’ve actually run into this more with debit/cash accounts than with credit cards. I’ve had checking accounts frozen, but I’ve never had a credit card entirely suspended for “unusual activity”. At worst they’ve declined individual charges until I called, or I just switched to a different card, since it’s easy to have many redundant credit cards.

For travel, etc. it's absolutely a good idea to have multiple redundant cards (that aren't issued by the same bank). I haven't had issues for years, but I have had issues in the past and it's a lot easier to just pull out a different card than deal with international calls trying to get a problem resolved on the spot.

I have CCs suspended all the time, requiring verification (often steam purchases..). In this case I'm talking about the entire account, and linked CCs, suspended for activity - all incoming payments, card payments and direct debits suspended.

Anecdotally, I’ve noticed most cafes in NYC with more than a handful of seats have a bathroom (even if they hide it) and WiFi. Outlets are pretty much everywhere, it’s more a matter of whether you can get a seat next to one.