axoflow / axosyslog Goto Github PK

AxoSyslog - the scalable security data processor

License: Other

Dockerfile 0.13% Shell 1.68% Smarty 0.02% Python 8.13% CMake 2.36% Makefile 2.80% M4 1.03% Ruby 0.01% Roff 0.04% Perl 0.10% Awk 0.07% C 75.75% Yacc 0.58% Lex 0.23% C++ 4.94% Objective-C 0.29% Java 1.84%

cloud docker kubernetes syslog-ng c log-management logging python syslog cloud-native

axosyslog's Introduction

Axoflow

AxoSyslog - a cloud-native distribution of syslog-ng by Axoflow

This repository contains the AxoSyslog source tree, cloud-ready syslog-ng images, and Helm charts created and maintained by Axoflow.

Container images

You can find the list of tagged versions at https://github.com/axoflow/axosyslog/pkgs/container/axosyslog.

To install the latest stable version, run:

docker pull ghcr.io/axoflow/axosyslog:latest

You can also use it as a base image in your Dockerfile:

FROM ghcr.io/axoflow/axosyslog:latest

If you want to test a development version, you can use the nightly builds:

docker pull ghcr.io/axoflow/axosyslog:nightly

Note: These named packages are automatically updated when a new syslog-ng package is released. To install a specific version, run docker pull ghcr.io/axoflow/axosyslog:<version-number>, for example:
docker pull ghcr.io/axoflow/axosyslog:4.7.1

Difference from upstream images

Our images are different from the upstream syslog-ng images in a number of ways:

They are based on Alpine Linux, instead of Debian testing for reliability and smaller size (thus smaller attack surface).
They incorporate cloud-native features and settings (such as the Kubernetes source).
They incorporate container-level optimizations (like the use of an alternative malloc library) for better performance and improved security.
They support the ARM architecture.

Our images are available for the following architectures:

amd64
arm/v7
arm64

Helm Charts

AxoSyslog provides Helm charts to deploy syslog-ng on Kubernetes.

Helm must be installed to use the charts. Please refer to Helm's documentation to get started.

Once Helm has been set up correctly, add the repo as follows:

helm repo add axosyslog https://axoflow.github.io/axosyslog

If you had already added this repo earlier, run helm repo update to retrieve the latest versions of the packages. You can then run helm search repo axosyslog to see the charts.

To install the axosyslog chart:

helm install my-axosyslog axosyslog/axosyslog

To uninstall the chart:

helm delete my-axosyslog

Documentation

You can find comprehensive documentation for AxoSyslog on the Axoflow website.

The documentation is a combination of the syslog-ng reference guide and the AxoSyslog reference guide. The syslog-ng documentation was included in there as the upstream documentation fell out of maintenance.

Contact and support

In case you need help or want to contact us, open a GitHub issue, or come chat with us in the syslog-ng channel of the Axoflow Discord server.

Contribution

If you have fixed a bug or would like to contribute your improvements to AxoSyslog, open a pull request. We truly appreciate your help.

About Axoflow

The Axoflow founder team consists of successful entrepreneurs with a vast knowledge and hands-on experience about observability, log management, and how to apply these technologies in the enterprise security context. We also happen to be the creators of wide-spread open source technologies in this area, like syslog-ng and the Logging operator for Kubernetes.

To learn more about our products and our open-source projects, visit the Axoflow blog, or subscribe to the Axoflow newsletter.

axosyslog's People

Contributors

Stargazers

Watchers

Forkers

alltilla ryanfaircloth overorion landonix 831jsh nova-platform-io mranno bazsi laszlovarady bshifter akunszt

axosyslog's Issues

ssc-3.4.5

ssc-3.4.5 test failed

ssc-3.2.0

ssc-3.2.0 test failed

ssc-2.49.6

ssc-2.49.6 test failed

ssc-3.22.3

ssc-3.22.3 test failed

ssc-3.23.0

ssc-3.23.0 test failed

ssc-3.22.2

ssc-3.22.2 test failed

ssc-3.4.4

ssc-3.4.4 test failed

ssc-3.4.6

ssc-3.4.6 test failed

systemd-journal support?

I know Alpine Linux does not use systemd so this might be won't do, but I'll ask anyway.

We are using a syslog-ng based DaemonSet to fetch both the node and Kubernetes pod logs. The host logs are fetched with systemd-journald() (required volumes are mounted to the syslog-agent pod) and the pod logs are collected with a wildcard-file() (those volumes mounted too) as no kubernetes() is available in the version we use. This is one of the reason why we would like to upgrade.

Also we are using both AMD64 and ARM64 machines.

Now we are building our own images by installing the packages offered by the distribution. Our issue is that those lags behind the latest and greatest available.

We tried the official syslog-ng image but that does not have ARM64. We tried axosyslog but that does not have journald support. Is there a way where we can have journald support on ARM64?

ssc-3.1.2

ssc-3.1.2 test failed

ssc-3.23.2

ssc-3.23.2 test failed

ssc-3.4.0

ssc-3.4.0 test failed

axosyslog:4.7.1 on CentOS 7: iv_fd_epoll_timerfd_poll: got error 1[Operation not permitted]

Hi team, do you support axosyslog:4.7.1 on CentOS 7?

We have the following error on start after upgrading:

sudo podman run ghcr.io/axoflow/axosyslog:4.7.1
iv_fd_epoll_timerfd_poll: got error 1[Operation not permitted]
iv_fd_epoll_timerfd_poll: got error 1[Operation not permitted]

ssc-3.22.5

ssc-3.22.5 test failed

ssc-3.0.1

ssc-3.0.1 test failed

ssc-3.4.1

ssc-3.4.1 test failed

ssc-3.1.0

ssc-3.1.0 test failed

ssc-2.49.7

ssc-2.49.7 test failed

ssc-3.22.4

ssc-3.22.4 test failed

ssc-3.22.5

ssc-3.22.5 test failed

ssc-2.49.0

ssc-2.49.0 test failed

ssc-2.49.3

ssc-2.49.3 test failed

ssc-3.4.2

ssc-3.4.2 test failed

2 high CVEs on docker image

Docker scout finding 2 high vulnerabilities in docker image.
Just run command docker scout cves ghcr.io/axoflow/axosyslog:4.6.0.

Vuln SC4S 3.4.3+: we have reported vuln in the alpine base image of 3.18

We noticed following vulnerabilities in the base image of axoflow 4.3.0 +

CVE-2022-48174 : https://security.snyk.io/package/linux/alpine:3.18/busybox
CVE-2023-39417 : https://security.snyk.io/vuln/SNYK-ALPINE318-POSTGRESQL15-5840784
CVE-2023-38039 : https://security.snyk.io/vuln/SNYK-ALPINE318-CURL-5914628
CVE-2023-39418 : https://security.snyk.io/vuln/SNYK-ALPINE318-POSTGRESQL13-5840796

@bazsi @MrAnno FYI.

ssc-2.49.1

ssc-2.49.1 test failed

Use of environment variables

It might make sense to use environment variables to configure syslog-ng instances.

Something like proposed here syslog-ng-container

This way it is possible to start multiple syslog-ng instances for different types of logs and place shared and instance-specific configuration snippets within the same git repository.