Security Advisories / Bulletins / vendors Responses linked to Log4Shell (CVE-2021-44228)
Last year I shared an example on how to realize application tracing in Kuberntes with Istio and Jaeger. After that, the industry has made some substantial headway on this front and we are seeing more vendor support as a result. At Buffer, since we primarily use Datadog for Kubernetes and application monitoring, it's only fitting to complete the circle with Datadog APM and Logging. I had a chance to create a small example for the team and would very much love to share with the community.
Okay, without further ado, let's dive in!
First thing first, in order to collect metrics and logs from Kubernetes an Datadog agent has to be installed in the cluster. The Datadog team ma
Tools
Presentations
| knowledge dump on container runtimes | |
| KataContainers | |
| - image coupled with kernel | |
| - light vm layer | |
| - can run in nested virturalization environments if hardware supports and you can enable it in bios (ex. only bare metal EC2 instances, limits many cloud providers) | |
| - slower startup time | |
| - OCI compliant | |
| - previously known as ClearContainers by Intel |
| pipeline { | |
| agent any | |
| parameters { | |
| string(name: 'environment', defaultValue: 'default', description: 'Workspace/environment file to use for deployment') | |
| string(name: 'version', defaultValue: '', description: 'Version variable to pass to Terraform') | |
| booleanParam(name: 'autoApprove', defaultValue: false, description: 'Automatically run apply after generating plan?') | |
| } | |
| environment { |
| Producer | |
| Setup | |
| bin/kafka-topics.sh --zookeeper localhost:2181/kafka-local --create --topic test-rep-one --partitions 6 --replication-factor 1 | |
| bin/kafka-topics.sh --zookeeper localhost:2181/kafka-local --create --topic test-rep-two --partitions 6 --replication-factor 3 | |
| Single thread, no replication | |
| bin/kafka-run-class.sh org.apache.kafka.tools.ProducerPerformance --print-metrics --topic test-rep-one --num-records 6000000 --throughput 100000 --record-size 100 --producer-props bootstrap.servers=kafka_host:9092 buffer.memory=67108864 batch.size=8196 | |
| Single-thread, async 3x replication |
Recently, Let's Encrypt launched free wildcard certificates. While this is good news in and of itself, as it removes one of the last remaining reasons for expensive commercial certificates, I've unfortunately seen a lot of people dangerously misunderstand what wildcard certificates are for.
Therefore, in this brief post I'll explain why you probably shouldn't use a wildcard certificate, as it will put your security at risk.
It's generally pretty poorly understood (and documented!) how TLS ("SSL") works, so let's go through a brief explanation of the parts that are important here.
The general (simplified) idea behind how real-world TLS deployments work, is that you:
This gist is a compilation of two tutorials. You can find the original tutorials here and here. What should you know before using this? Everything can be executed from the home folder. For easier cleanup at the end you can make directory where you'll download everything, and then just use rm -rf .. Although, you should be careful. If some strange bugs arise unexpectedly somewhere sometimes, just keep in mind that some user names have underscores in them (this is probably nothing to worry about).
sudo adduser --no-create-home --disabled-login --shell /bin/false --gecos "Prometheus Monitoring User" prometheus
sudo adduser --no-create-home --disabled-login --shell /bin/false --gecos "Node Exporter User" node_exporter
sudo adduser --no-create-home --disabled-login --shell /bin/false --gecos "Alertm