KubeCon EU 2024 Paris, let's talk about Kubetrain

Yesterday, KubeCon NA in Chicago came to a close, so now we can start talking about KubeConEU 2024, which will take place in Paris from March 19th to 22nd, 2024 😊.

For Paris, early bird registrations are open until November 28th, and it's still possible to participate in the call for papers.

I wanted to tell you about an interesting initiative called Kubetrain, which aims to reach Paris in a more environmentally sustainable way by choosing trains over planes.

To make everything economically sustainable, the organizers of Kubetrain have come up with the idea of arranging sponsored carriages from some of the major European cities. This way, people can travel to Paris, making it possible to organize networking events during the journey!

The involved cities are as follows:

• Amsterdam
• Berlin
• London
• Lyon
• Milan
• Zurich

The trip from Zurich is already "operational," and for the rest, it's still a work in progress.

I encourage you to follow their website for updates and potentially book your departure from your preferred city.

I find the initiative very interesting—kudos to the organizers!

Why should you contribute to community projects? Some information about CNCF and OpenSSF.

I start with a premise for those who may not already know: the open-source software ecosystem often revolves around foundations, with the most famous probably being the Linux Foundation.

Regarding the cloud-native domain, the reference foundation is the Cloud Native Computing Foundation, commonly known as CNCF.

The CNCF is a foundation created by the Linux Foundation in 2015, specifically to handle the management of projects in the cloud-native domain. In simple terms, we could define it as a third-party, vendor-neutral entity that regulates the development and activities related to all the major projects related to containerized technologies like Kubernetes.

The foundation consists of a large number of sub-entities, working groups that oversee various projects, and much of the work is done by volunteers. To participate, the rules of the CNCF's code of conduct must be adhered to.

Speaking about Kubernetes and the main projects associated with it, you can imagine the amount of work required to make this system function and how many people at all levels can be needed to contribute to both technical and non-technical projects.

Throughout my career, I have always tried to be a part of what surrounded my professional world, taking part in events, speaking at events, and even organizing them.

Even in my current role at SIGHUP, I have maintained the same approach and operating mode. Since the past few months, I have been part of the Italian team responsible for the Italian localization of the CNCF's glossary.

I share this with you because I find it extremely rewarding to participate in these kinds of initiatives, getting to know new people, perhaps stepping out of one's comfort zone a bit, and being of assistance to people and companies one may not know, all for the sake of fostering a better ecosystem.

As you can imagine, contributions can be made at all levels, with different teams for the different scopes. Of course, it's common to work with people from all around the world and from diverse backgrounds.

As a colleague told me a few days ago, "if you enter a meeting and feel like a fool compared to the other participants, it probably means you're in the right place," because participating in meetings, even as an observer, with high-level individuals is a great opportunity for professional growth.

Well, now that I've piqued your interest, how can you participate or find a project that suits you?

I suggest a series of links where you can find information about CNCF events and projects:

• EXPLORE ALL CNCF SITES
• END USER COMMUNITY
• CNCF SLACK
• CNCF repositories GitHub

What I've mentioned above also applies to another foundation, very interesting, born in 2020, called the Open Source Security Foundation, commonly abbreviated as OpenSSF. This foundation is an initiative of the Linux Foundation and focuses on enhancing the security of open-source software.

Since I work in security, I closely follow various initiatives of this foundation.

At the moment, due to time constraints, I'm not an active contributor, but members of my team have already had the opportunity to contribute and participate in various working group meetings. It's important to always adhere to the code of conduct when participating and contributing.

In this case as well, I'll provide you with some useful links where you can find collaboration ideas for OpenSSF:

• OpenSSF Working Groups
• Get Involved
• Repo su GitHub
• OpenSSF SLACK

 

CyberArk Conjur 13.0 it's available!

 During the previous days CyberArk has released the version 13.0 of Conjur enterprise.

What's new? Who should consider to upgrade and why?

I've published an article about this themes here inside the SIGHUP blog.

CyberArk Conjur 12.9 and podman - how fix the logs rotation in case of issues

CyberArk Conjur is released as an appliance and shipped as container images to have a fast setup without errors.

The supported container runtimes are the following:

• docker 20.10 or later
• mirantis container runtime 20.10
• podman 3.x,4.x

Working on several Conjur environments inside our labs or customers we have noted that logs rotation (conjur, nginx, cluster, etc) wasn't performed on podman but that was working correctly on Docker.

After some investigation with the beloved CyberArk support team, we found the solution:

conjur container needs to be re-created adding the capabilities AUDIT_WRITE :

podman run \ ... --cap-add AUDIT_WRITE \ ... registry.tld/conjur-appliance:12.9.0

To avoid some noise inside the nginx logs it's also required to add the following permission inside every Conjur container:

chmod 701 /opt/cyberark/dap/log/nginx

The CyberArk support team was great as usual to assist us and to work together to find the solution.

These issues are now tracked on the CyberArk docs and should be addressed soon. 

In case you had the same issue I recommend to contact the CyberArk support to get confirmation if this solution could apply also to your environment.

SIGHUP Secure Containers: how do you choose the oci base image for your workload?

I believe it's important to start with a premise:

in this article I'll spoke about a product/service built and offered by my actual employer, SIGHUP. 

Nobody from my company asked me to publish this blogpost here, this are my honest opinion about Secure Containers.

Secure Containers is a service with a fee,  built by SIGHUP that brought container base image secure, hardened and updated. 

Developer work with containers and images, compared to the past, offer several advantages like standardisation, automation, and a faster release time.

One of the underestimated aspects of working with containers, is that it's necessary to start from basic images that must be chosen with due caution in order not to run into one or more of the following issues:

• bugs
• CVEs
• outdated images
• malicious code

It is clear that having constantly updated base images, which contain the least number of CVEs possible, is important because any problems, once my software has been deployed, are replicated in the container which we then find running in production environments.

Keeping the base images updated and secure is therefore a non-negligible activity, which becomes a task that must be adequately followed by someone in the company, removing them from other tasks.

Here Secure Containers service can help with the following advantages:

• Comprehensive Container catalog
• Proactively patched against all known CVEs and vulnerabilities
• prometheus friendly images
• Notifications, support status and planned obsolescence
• supports and clear SLAs

If you are interested in Secure Containers, please read the dedicated site to find more info and FAQ where you have also the possibility to enable a free trial of the service.

If you like to read more about the security of container base images, check this article where I'll explain this topic deeper.

How is possible to have devs and security officers happy at the same time? Try Snyk!

Being able to work safely in cybersecurity requires knowledge, attention to detail, and a good software portfolio to rely on.

One of the tools that I've learned and used during the last months is Snyk.

Call Snyk tools is not correct because it's a security platform with a series of tools that could operate on every code built:

• code (SAST)
• open source (SCA)
• container
• infrastructure as a code
• cloud

During the last few years, the lines of code produced were growing exponentially. The availability of tons of open-source libraries and containers has boosted the speed of developers, but how can we be sure that all these resources are safe?

How developers could be responsible for the security of their code and of the work made by someone else? How security officers could handle this scenario without being a bottleneck to productivity?  

Snyk could help integrate his tools in IDE, git repository, or in pipelines CI/CD with fast analysis and suggesting the solution of the detected issue  

To provide some examples Snyk could be installed as VSCode plugin, or could be set to scan git repositories and in case of an issue could open automatically a pull request proposing a resolution.

Snyk is also fully integrable in the customer environment, both for access and security policies, to be full compliance with the customer needs. Customizable dashboards and reports are also available to make security officers able to understand fast the security situation of a project.

Another interesting fact is Snyk has builded also an open-source vulnerability database that catalogues the vulnerabilities and provides examples and tutorials for devs.

The great news is that make a test it's easy because a free (limited) plan is also available!

If you could be interested to have more info about Snyk, please read the blog article published by my colleague Luca Bandini about our experience with Snyk, used also to check the code of Fury the Kubernetes distribution developed by SIGHUP.

CyberArk Conjur follower, system error and reboot during configuration: how troubleshoot it and verify the Postgres communication in the right way

During this period working on a CyberArk Conjur environment, we experienced a strange behavior during Conjur follower setup. 

The setup on the follower was starting, the seed received, imported, and expanded but after some other steps the process was hanging and ending with a generic "System Error".

After the error message, the Conjur follower was restarted. 

We did some troubleshooting inside the Conjur Follower pod and we have verified that the Follower was able to connect to the Conjur API leader successfully but it wasn't able to connect to the Postgres database and finish the initial replication.

The correct way to verify the Postgres connectivity from the follower to the leader is the following command:

echo "" | openssl s_client -starttls postgres -connect <lb_DNS>:5432 -showcerts

if the server certificate will be returned, the Postgres connectivity will work as expected.

In our case, we were unable to get the certificate, so this points us to the network LB where a colleague fixed the issue.

Thanks to CyberArk support which provided us the openssl command, easy to be executed from the container or any server. 

We did the same verification in another way but the openssl s_client could be found easily on containers and servers.

To have more explanation about openssl s_client and see more options, check this nice blog post.