Около DevOps – Telegram
Около DevOps
69 subscribers
33 photos
9 files
501 links
О DevOps и не только

@dmitriy_stoyanov
Download Telegram
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
Log4j - impacted products

Самое время посмотреть на те продукты, которые попали под impact от log4j:

https://github.com/NCSC-NL/log4shell/tree/main/software

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Фиксить придется много

#dev #ops #attack
https://aws.amazon.com/blogs/aws/amazon-kinesis-data-streams-on-demand-stream-data-at-scale-without-managing-capacity/
Интересная фича на ReInvent’е была анонсирована, теперь можно датастримы переключить с режима Provisioned ранее единственно возможного, который поднимает кластер и работает в нем постоянно, вне зависимости от того, шлешь ты эти данные через стрим или нет в текущий момент, платить все равно придется, на OnDemand, который позволяет включить автоскейлинг данного кластера в зависимости от потребляемых ресурсов
https://logging.apache.org/log4j/2.x/security.html
Mitigation
Log4j 1.x mitigation: Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.

Log4j 2.x mitigation: Implement one of the mitigation techniques below.

- Java 8 (or later) users should upgrade to release 2.16.0.
- Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
- Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
Forwarded from CatOps
​​Last week, I promised a series of posts about modern application delivery. Last time, we briefly discussed the problems that are generated by the disconnection between application code and its infrastructure dependencies.

Today, let's talk about a proposed formal way of solving this issue - Open Application Model. This is a specification of application bundle definition that contains all the required components as well as traits (we'll talk later on this one). The main purpose is to provide a reasonable abstraction for customers. So, they can use components and traits as building blocks for their application's infra dependencies.

This concept was proposed by people from Alibaba Cloud (and Microsoft?) and the whole thing is fairly new. However, it already has an implementation for Kubernetes - KubeVela. Although, I still have unanswered questions for this tool. For example, is it possible to provide default traits? What should I do if I want all my apps to have an autoscaler, etc.?

In any case, those are implementation details. Nothing stops you from embracing concepts of OAM and implementing them using, let's say, Helm.

As a bonus, here is a great video by Viktor Farcic about KubeVela with some basic "Hello world" example. It helps to better understand the problem that OAM is trying to solve as well as its concepts like components, traits and the difference between them. 'Coz the official documentation, let's be honest, is not that great.

https://youtu.be/2CBu6sOTtwk

#oam #app_bundle #kubernetes
k8s_from_dev_to_prod.pdf
3.2 MB
How Kubernetes traffic management tools work?
Get sense of solving the challenges of resilience, visibility, and security that come with running Kubernetes in production.
An Ingress controller and service mesh topics are included.
"DevOps is not a person".

We have this picture in mind, but to move current situation on client or our side, we need to have some people to bring this culture into it.

Sometimes hiring stuff, client, managers or other people, easy to name it as "DevOps engineer" to just hire such members, who help them to bring this culture.

But I guess we are all Engineers and need to help people to solve their problems.

So possibly like in Agile, in different level of maturity we have separate SCRUM Master, who help team to start working in that behaviour, sometimes it is just a role, and sometimes it is not needed. The same picture with DevOps. At start, when people work in silos, they need someone to share new vision, culture, methodology and experience, because they cannot work in that way. But this process to work as a whole team, not as many separate teams, but as One Team, it can be long time process of transformation. And not always, it can be changed in some understandable period of time. It can go as continuous process.

Just leave it here: https://web.devopstopologies.com/ as a different topologies of DevOps