TL;DR style notes from articles I read today.
How soon we forget: Security in the age of Docker and Kubernetes
- Don't run binaries as root as that creates a privileged user and higher risks. In a Docker container, use the RUN command to create a user & then use the USER command to make it the default user whenever an image is run as a container. For K8s, use the pod and container security context to force containers to run as non-root.
- Run containers with a read-only file system alone. You should not need to write anything more than a temporary file or cache within a container.
- Terminating encryption (SSL/TSL) at the load balancer is another security risk. If using a Kubernetes cluster, move the TLS termination into the cluster and then encrypt all traffic within the cluster.
- Protect your host CPU and memory against DDOS attacks by setting resource limits on your containers.
- Use the Kubernetes network and pod security policies to control the capabilities of containers.
Full post here, 9 mins read
How to define and spend your tech debt budget
- Define a technical debt budget - the maximum debt you can take on without affecting the business bottom line or your customers. If your tech debt balance sheet is in the red, take the time to pay back some of it; if it is in the green, take more risks to try and beat competitors.
- Identify areas in the codebase where you will want to pay back your tech debt immediately - usually where debt gets in the way of the company’s current objectives. Examples are weak file ownerships and those with low cohesion and high coupling. Prioritize files that check all three boxes.
- If it is not critical or is too complicated or does not need to be improved in the next few months, acknowledge it as debt and let it be.
- Decide what you will work on this sprint, month or quarter and see what part of your tech debt overlaps with that roadmap.
- From the list of files, thus, see which files are going to be needed for the roadmap ahead. Target these for refactoring.
Full post here, 6 mins read
Embedded integration frameworks: Tips from Shopify, Twitch, and more
- Define target personas & use cases of developers who are your potential platform users. Prioritize the platform for one target persona over another only after gathering feedback to determine the right direction for their platform.
- Establish a good experience with your framework that encourages users to not just make requests but to play around and hack the service to do what they want. Treat this as actionable feedback and prioritize these improvements.
- Make integrations as powerful and simple as possible. Instead of asking a partner for a URL to embed, Twitch allows developers to host their front-end code on Twitch itself.
- Build tools on top of APIs to cover common use cases. Include native elements that stay the same across integrations.
- Use event-catching to capture the context around the app environment and automate the app to fine-tune the experience accordingly.
Full post here, 7 mins read
Top comments (4)
People always laugh on me when I recommend this :(
But this kind of people just learn in the hard way, aka after they been breached and paid a huge fine, because if no money losses are involved they may continue with the same attitude... Sadly I have seen this happen.
Generally, there's a lot more chatter on an internal network than on public networks. TLS within a private network definitely provides greater security, but how do you contend with performance loss of encrypting and decrypting internal traffic?
Hey, nice note on Kubernetes security! Do you think security has become more challenging with the advent of k8s and containerization?
Security has always been a challenge in any deployment. Infosec folks have historically been at odds with software engineers who just want stuff to work.
It's important for default settings in all applications to become more secure. Docker's default of running applications as root definitely created security concerns. There's already enough literature on how to secure Docker containers, but most of them involve more work. Orchestration frameworks like k8s are still young and will definitely get better with time and more exposure.