If you have ever used Docker or any other Linux OCI container system, you inevitably have incurred in the following error:
x509: failed to load system roots and no roots provided This message is remembering you that you forgot to provide Root Certificate Authorities to your application. There are two different ways to solve this:
mount the /etc/ssl/certs folder from the machine where the container is running bundling the root CAs in your image As you may imagine from the title, I believe that the second option is by far better than the first one.
Lately, all website are urging their users to enable second-factors. The push for multi-factor logins is a good thing from my point of view, since the people are putting more and more details of their life online and is a good thing that companies start to understand the security implication of this and are trying to teach their users good security practices. The real problem is what is defined as second-factor.
A couple of months ago, I wrote a blog post about why containerization is not always the answer and I’ve received quite a few comments about it. This article has the goal to analyze an aspect in favor of containerization which I believe to be true but was not mentioned in the previous post: the time aspect of the phenomenon.
In the ICT sector, we are used to new technologies, or at least we should be.
As many other clouds, Google Cloud Platform provides an Object Storage service, Google Cloud Storage. As many other Object Storage service, Google Cloud Storage provides an HTTP server to deliver your files quickly. When I started to use Google Cloud Storage and its HTTP server I have not been entirely pleased by how it works and therefore I wanted to re-implement the HTTP server so that I can manage it completely.
UPDATE: I’ve then written another post to clarify better my point of view on the future of containers.
When I hear people (and usually those people are salespeople) saying that as soon as you put a Container Platform in your company, all your problems go away, I feel bad for the company they are trying to sell it to.
I’ve seen far too many container platforms (as well as many other technologies) fail at customers because they have been sold as this magical problem that makes all your problems go away.
This year, as it has happened for the last few years, I’ve been at FOSDEM. As always I’ve enjoyed it a lot, and that’s why I continue to go there, and every time I have to suggest other people which events to attend in Europe, I always mention FOSDEM as the principal event. This year, differently from previous editions, I tried to stick to a single room during Saturday (the Go one).
I found myself multiple times in situations where people were trying to explain to me how much they are (or would like to be) DevOps and how awesome DevOps is and how productive their teams had become since when they merged the Dev team and the Ops team, and they don’t have any team which is not DevOps and application-centric. I usually stare at them thinking that they have no idea what they are talking about, or they have just outsourced all the non-application-centric side of their IT and have not realized it.
A few months ago, I posted how to create a PKI in Go. Today I’d like to add share a useful function (at least from my point of view) that I found myself to write.
The problem arose when I had a function that required as input a *pem.Block of the public key, but all I had was the PEM file containing, as you can imagine:
the Private Key the Public Key the CA Public Key I think this is a typical situation, and for this, I’d like to share a function I wrote to extract it.
Authentication factors One of the common way to create more secure authentication in systems is adding more “factors”, creating in this way a Multi-Factor Authentication (MFA). The idea behind MFA is that there are many different ways to authenticate a user, and those can be split in different “categories” based on the kind of challenge we require. Generally speaking, it’s common to divide the authentication methods in mainly three categories:
One of the big advantages that Ansible Tower and AWX (the open source and upstream version of Ansible Tower) bring to the table is the Role Base Access Control (RBAC). This will allow you to select which users (or teams) will be able to see which objects in Ansible Tower as well as which jobs they will be able to run.
Obviously to leverage the RBAC, you will have to have personal accounts for every user of your platform.