Docker context for remote access - over Internet or vpn, whatever.
Swarm-cronjob for scheduled things.
Labels for things that need to run in particular places.
So easy.
Personally, k8s is fine, but its an abstraction for building a service architecture, not the thing an end user (developer) should ever use. If you are in a big company and you are using helm or k8s yaml files to roll things out, your infra or platform teams have missed something out.. building the platform!
Hmm, not sure - the entire point of this sort of thing is that nobody should ever have your private key material. Whether they say they discard it is immaterial, they have had it, so they could use it, and then as far as everyone is concerned, they are you.
Because the key is sent via the web, anyone in the way can see it. In lots of companies, trusts are manipulated so that the content is visible to intermediate proxies.
With a private key that has been given to you by somebody else, it is possible to repudiate any transaction that was made with the key. Its not so much as they could skip any security - its that if they have the key, they don't have to.
keys are protection from anyone, and an audit trail isn't useful when its possible to forge/repudiate literally anything.
imagine if your card pin was also written down in the card factory - you'd be suspicious that anyone can withdraw money from your account - and the bank would say 'ah but only you know it'. In fact this did happen - the bank was only issuing 3 different pin numbers.
When you create an app in GitHub - you are required to create a private key so that you can sign requests on behalf of your app.
Sounds reasonable.
However... to create the private key, they require you to download the private key from them. Which means they have it. So ANY APP on GitHub can be impersonated by GitHub as they have the key material for every app... so what is the point?
Spec driven ddevelopment.. ahh yes, because the formal methods era of computer programming was so quick and successful!
Let me find my:
Requirements Specification
Requirements Analysis
...
The circle will turn once again when people re-realise that by tue time you've written what should happen in enough detail, you've written the software, and English isn't that great at avoiding ambiguity.
Copy and paste once is fine, twice, not so much.
Often I've seen two totally different things exist in one bit of code, no overlap!
Premature generification is bad, and leads the developer to believe that two things are the same, making it harder to see they are not.
Also, can make it much harder to see that a different abstraction would give a cleaner outcome....