cosign VS Zabbix

Cosign: In this context, Cosign from the Sigstore project offers a compelling solution. Its simplicity, registry compatibility, and effective link between images and their signatures provide a user-friendly and versatile approach. The integration of Fulcio for certificate management and Rekor for secure logging enhances Cosign's appeal, making it particularly suitable for modern development environments that prioritize security and agility.

sigstore is another suite of tools that focuses on attestation and provenance. Within the suite are two tools I heard mentioned a few times at KubeCon: Cosign and Rekor.

Since we can distribute Spin applications using popular registry services, we can also take advantage of ecosystem tools such as Sigstore and Cosign, which address the software supply chain issue by signing and verifying applications using Sigstore's new keyless signatures (using OIDC identity tokens from providers such as GitHub).

Use distroless images (which contain only application and its runtime dependencies, and don't include package managers/shells or any other programs you would expect to find in a standard Linux distribution). All distroless images are signed by cosign.

$ COSIGN_EXPERIMENTAL=1 cosign verify-blob --cert https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64-keyless.pem --signature https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64-keyless.sig https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64

Another thing to look for is, whether the image is signed using something like cosign (https://github.com/sigstore/cosign). This lets the publisher digitally sign the image, so you at least know that what's on the registry is what they intended to put there. Handy to avoid the risks of attackers squatting similar names and catching typos.

i’m late but surprised no one has mentioned cosign

name: Docker # This workflow uses actions that are not certified by GitHub. # They are provided by a third-party and are governed by # separate terms of service, privacy policy, and support # documentation. on: push: branches: [ "main" ] # Publish semver tags as releases. tags: [ 'v*.*.*' ] pull_request: branches: [ "main" ] paths: - src/MamisSolidarias.WebAPI.Campaigns/Dockerfile - .github/workflows/docker-publish.yml workflow_dispatch: env: # Use docker.io for Docker Hub if empty REGISTRY: ghcr.io IMAGE_NAME: mamis-solidarias/campaigns jobs: build: runs-on: ubuntu-latest permissions: contents: read packages: write # This is used to complete the identity challenge # with sigstore/fulcio when running outside of PRs. id-token: write steps: - name: Checkout repository uses: actions/checkout@v3 # Install the cosign tool except on PR # https://github.com/sigstore/cosign-installer - name: Install cosign if: github.event_name != 'pull_request' uses: sigstore/cosign-installer@main with: cosign-release: 'v1.13.1' - name: Set up QEMU uses: docker/setup-qemu-action@v2 with: platforms: 'arm64' # Workaround: https://github.com/docker/build-push-action/issues/461 - name: Setup Docker buildx uses: docker/setup-buildx-action@v2 # Login against a Docker registry except on PR # https://github.com/docker/login-action - name: Log into registry ${{ env.REGISTRY }} if: github.event_name != 'pull_request' uses: docker/login-action@v2 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} # Extract metadata (tags, labels) for Docker # https://github.com/docker/metadata-action - name: Extract Docker metadata id: meta uses: docker/metadata-action@v4 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} tags: | type=schedule type=ref,event=branch type=ref,event=pr type=semver,pattern={{version}} type=semver,pattern={{major}}.{{minor}} type=semver,pattern={{major}} type=sha # Build and push Docker image with Buildx (don't push on PR) # https://github.com/docker/build-push-action - name: Build and push Docker image id: build-and-push uses: docker/build-push-action@v3 with: context: . platforms: linux/amd64, linux/arm64 file: src/MamisSolidarias.WebAPI.Campaigns/Dockerfile push: ${{ github.event_name != 'pull_request' }} tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} # Sign the resulting Docker image digest except on PRs. # This will only write to the public Rekor transparency log when the Docker # repository is public to avoid leaking data. If you would like to publish # transparency data even for private images, pass --force to cosign below. # https://github.com/sigstore/cosign - name: Sign the published Docker image if: ${{ github.event_name != 'pull_request' }} env: COSIGN_EXPERIMENTAL: "true" # This step uses the identity token to provision an ephemeral certificate # against the sigstore community Fulcio instance. run: echo "${{ steps.meta.outputs.tags }}" | xargs -I {} cosign sign {}@${{ steps.build-and-push.outputs.digest }}

After inspecting the layers i think you should start thinking about signing your images: https://github.com/sigstore/cosign/

cosign

Zabbix

Zabbix is a comprehensive open-source monitoring solution designed for real-time monitoring and management of various network components, such as servers, networks, and applications. It excels in data collection and processing, enabling proactive monitoring for early issue detection and resolution.

The PHP core package is offered as pre-compiled binary via Ports packages system. In addition, important softwares such as extensions, Composer and PECL libraries are available. So are frameworks such as NextCloud and Zabbix.

Prometheus is a great way to go, however you need to invest time in writing all the alerts. This was a daunting task for us, because we have too many vendors and device types.. we instead went with zabbix, which is a free open source platform similar to Orion. Quite easy to setup. All the device templates for monitoring alerting are provided by the community. There is a grafana plugin which integrates with Zabbix, so you can build beautiful dashboards in grafana while using the polling and alerting logic in zabbix. You can also use grafana OnCall via a zabbix integration. Phase1: You could move to zabbix. Realize cost savings without investing time. Phase2: learn and work on moving things to Prometheus slowly. edit: added links and some rewording

Setup Zabbix (https://www.zabbix.com/) and use SNMP (search for a template for your switches, chances are someone has created one) to pull throughput data from the switchport your proxies are connected to. This will graph them for you on a continual basis, you can then setup some triggers (alerts) that will flag over-utilization (say >80Mbps) for you, can generate an email or SMS alert based on that or just see it in the dashboard.

Look at setting up Zabbix (https://www.zabbix.com/) you can then do ping and latency tests to key hosts/endpoints and get packet loss and other variables in a graphical format. Also will allow you to setup monitoring to alert when there are known issues.

Check out Zabbix. Similar to something like PRTG (I see was already mentioned) but it is a free solution. Only cost is setup time and infrastructure.

now if its more metric data you are using and want to do APM, prometheus is your man https://prometheus.io/, want to make prometheus your full time job? deploy cortex https://cortexmetrics.io/, honorable mention in the metrics space, Zabbix, https://www.zabbix.com/ I've seen use cases of zabbix going way beyond its intended use its a fantastic tool

- NMS / NPM: NetXMS, Zabbix, LibreNMS, PRTG - NCM, updates, automation: Unimus - IaC / automation: Ansible - DCIM / IPAM: NetBox - IPAM / DDI: Infoblox