-
A tale about object encryption
Encryption is difficult, it shouldn’t be, but it always seems to be a challenge. While something is difficult to do, its adoption is going to be very slow. At Wealth Wizards, we are keen to ensure that the data we store is safe and secure, this led to the decision to do row level encryption within our databases in order to separate access to the database from access to the data — defence in depth. But this level of encryption does not make using the data very easy. This is a little tale about encrypting objects and managing their encryption keys.
-
Video: Unblocking the release train with Istio traffic management
Recently, Pierre Meunier and I delivered a talk at KubeCon/CloudNativeCon Europe 2019 in Barcelona on our use of the Istio service mesh. You can view this talk on YouTube
-
Istio performance in a multi-tenancy Kubernetes cluster
At Wealth Wizards we run a soft multi-tenancy set up in Kubernetes by defining a namespace to each of our customers and restricting access between tenant namespaces, the number of services and configurations we had caused our Istio installtion to consume a large number of resources due to the amount of unnecessary configuration being pushed around.
-
Unblocking our release train with Istio traffic management
Wealth Wizards employs a microservice architecture. This means lots of services, each being actively developed. To ensure that our changes work a variety of tools are used, including unit-tests, contract tests and linting tools which can be used against work in progress. However, there is still a number of steps that need to happen using the whole suite of services, or at least a reasonable portion of them. This includes end to end testing, review or demonstrations with stakeholders to get feedback.
-
DevOps: I love it when a plan comes together
When I first started in my current role as a platform/operations bod I seemed to spend a good majority of my time sorting out configuration, deploying new software and looking after our growing microservice ecosystem.
-
Privilege escalation in Vault
After using Vault for a period of time we recognised a risk around the KV secrets engine which means that users could accidentally overwrite or delete secrets stored there using the Vault CLI, accidents happen after all. Unlike other secrets engine, like the AWS secrets engines where the secrets are created when requested and if revoked can be requested again, the key value secrets are lost if they are updated or deleted.
-
Working with Vault secrets that expire on Kubernetes
One of the most powerful features of Vault is the dynamic secrets provided by a number of secrets engines. Most of these secrets engines integrate with authenticated services to generate access credentials when they are needed, like a database username and password. The credentials are then revoked after a period of time. In my previous article I discussed how to authenticate a Kubernetes application against Vault so that the application could retrieve secrets and manage it’s own leases. However, what happens if the application you want to run doesn’t know anything about working with Vault?
-
Working with Vault secrets on Kubernetes
Hashicorp’s Vault is more than just a secrets store, it can be used to dynamically create secrets with the relevant permissions at the time that they are required. This has great security benefits, because it not only means that no-one actually needs to know passwords and other secrets as they only exist when they are required, but also it encourages applications and systems to expect secrets to become invalid at some point (expire). This makes the idea of regular passwords/secrets rotation the norm rather than something to be scared of. I’m sure you’ve come across the scenario: “I don’t know what’s using this password and I don’t want to break anything so I’ll leave it as it is”.
-
Avoid Bottlenecks and Improve Quality by Empowering the Delivery Team
One of the biggest bottlenecks in the delivery software changes can be the hand over between teams; whether this is passing a change to a test team to validate the release or handing a release over to the operations team to deploy. What if we could remove those bottlenecks by empowering the delivery team?
-
Continuous Delivery - What is the point?
There are many reasons to adopt continuous delivery, one of them is so that you can release multiple times a day, but it’s not the main reason. In fact, you may implement continuous delivery and not release that frequently, either by choice or due to other restrictions.
