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.

Let's suppose that you and I want to exchange encrypted messages. Once I have gen-erated a key pair, I can give you the public key so that you can send me encrypted messages. But if I send you that public key, how do you know that it really came from me and not from an imposter? To establish that I am who I say am, we will need to involve a third party that you trust, and that will vouch for my identity. This is the function of a certificate authority.

فک نکنم زیاد هم جدید باشه، البته شاید تازه براش اصطلاح وضع کردن🤷
نیکس و گیکس هر دوشون خیلی وقته که برای دپلوی سیستم عامل از گیت استفاده میکنن
و خب بسته‌بندی نرم‌افزارشون هم بر همین منواله که میشه روی بقیه‌ی دیستروها هم راه‌اندازیشون کرد(نیکس رو مک هم اومده)
به خاطر همین گیکس(که میشناسم) برای devops یا همین gitops با سیستم عامل یکپارچه میشه بر خلاف Kubernetes یا محیط‌های داکر و … که برای مدیریت کانتینرها استفاده میشن، اینجا هم توسعه نرم‌افزار و هم محیط‌های ایزوله از یک الگو پیروی میکنن
برای ساخت یک نرم‌افزار نیاز نیست یک کانتینر راه‌اندازی کنید که یک سیستم‌عامل رو راه‌اندازی کنه و … بلکه فقط پیش‌نیازها رو اعلام میکنید و بر اساس اون برنامتون رو توسعه میدید، برای اینکه محیط نرم‌افزار رو از محیط کاربریتون جدا کنید میتونید از دستور container استفاده کنید تا محیط ایزوله‌ی خالی از هر ابزاری بهتون بده مگر آنهایی که مشخص کرده باشید(نه یک سیستم‌عامل غیر ضروری)

سوای نرم‌افزار منطقا هر نوع سیستم‌عاملی رو هم میشه باهاش دپلوی کرد‌ چه رو سخت‌افزار و چه در محیط مجازی با قابلیت کامپایل از سورس یا دانلود باینری و بازگشت به عقب و …