GitOps is a methodology in which all the configuration information about the state of a system is held under source control, just as the application source code is. When a user wants to make an operational change to the system, they don't apply commands directly but instead check in the desired state in code form (for example, in YAML files for Kubernetes). An automated system called the GitOps operator makes sure that the system is updated to reflect the latest state as defined under code control.
This impacts security in significantly beneficial ways. Users no longer need direct access to the running system because everything is done at arm's length via the source code control system (typically Git, as the name implies).

To get a real picture of whether the packages installed on a server are vulnerable or not, you would need to reference not just the NVD (National Vulnerability Database) but also the security advisories that apply to your distribution.

Regularly rescanning container images allows the scanning tool to check the contents against its most up-to-date knowledge about vulnerabilities (from the NVD and other security advisory sources). A very common approach is to rescan all deployed images every 24 hours, in addition to scanning new images as they are built, as part of an automated CI/CD pipeline.

Container image scanning tools like Trivy, Clair, Anchore, and commercial options such as Aqua or JFrog help detect vulnerabilities in container images. However, the results can vary depending on factors like the data sources used (e.g., NVD vs. distribution-specific feeds), outdated vulnerability databases, unpatched but known issues, or misunderstandings about installed packages and their components. Some tools also scan for malware, setuid binaries, images running as root, or exposed secrets. Since no tool is perfect, it’s important to choose one that supports your base image, uses up-to-date feeds, and fits your specific security needs.

Incorporating vulnerability scanning into the CI/CD pipeline helps detect and fix security issues early, which is faster and more cost-effective than fixing them after deployment. Unlike traditional deployments where packages are shared across apps, containerized applications bundle their own dependencies, allowing for independent updates and easier scanning. Scanning can happen at multiple stages: on a developer’s machine, right after image build (failing the build if critical issues are found), or regularly in the image registry to catch new vulnerabilities in older images. This “shift-left” approach improves security by making it part of the development lifecycle.

Suppose you have two workloads and you don't want them to be able to interfere with each other. One approach is to isolate them so that they are unaware of each other, which at a high level is really what containers and virtual machines are doing. Another approach is to limit the actions those workloads can take so that even if one workload is somehow aware of the other, it is unable to take actions to affect that workload. Isolating an application so that it has limited access to resources is known as sandboxing.

In an ideal world, there would be a tailored profile for each application that permits precisely the set of syscalls that it needs.

docker run —security-opt seccomp=/etc/profile/custom-profile.json <IMAGE_NAME>

تو پروسه ی یادگیری ، هدف درک مسئله هست ، نه حفظ کردن مطالب!

چیزی که وارد مغز میشه اهمیت نداره ، اون مقدار چیزی که توی مغزت میمونه مهمه

You need to be root on the host to run a container in the first place. This is because only root has sufficient capabilities to create namespaces, generally speaking. In Docker, it's the Docker daemon, running as root, that creates containers on your behalf.