ed1703 schreef op maandag 7 september 2020 @ 07:44:
[...]
Docker-ontwikkelaars MOETEN in de dockerfile alle code proppen wat er precies gebeurt. Daar is die file notabene voor. Protip: meer dan 75% downloaden via een dockerfile de code uit gitlab of github, waar je nog zelf aan mag meeschrijven als je een ontwikkelaar hebt die daar open voor staat.
Zolang de soure beschikbaar is, is er weinig aan de hand.
Je One-Man-show heb je gelijk in.
Overigens is DNSmasq daar een voorbeeld van, gemaakt door 1 persoon en die doet nog steeds grotendeels zelf de ontwikkeling.
Ik ben geen container expert. Dus pin min niet vast op uitspraken ik zit hier ook om te leren ;-) het kan zomaar zijn dat ik een verkeerde interpretatie heb van de werking. Dockers is voor mij nieuwe territorium ;-)
Als je weet hoe je de inhouden kan controller op unwanted third party’s dan is er het toch prima.
Maar hoeveel gebruikers kunnen of doen dat niet?
Ik kwam net toevallig op deze blogs over de veiligheid van de inhoud van containers door een nieuws bericht over een security issue wat betreft de monitoring en beveiliging exploit worm voor docker en kubernetes (nogmaals het kan zijn dat ik meer ik duiding nog heb om het goed te begrijpen)
Voor de sys&dev admins hier
Hackers use legit tool to take over Docker
Describing the attack flow from the incident, the researchers say that TeamTNT’s way in was an exposed Docker API. This allowed them to create a clean Ubuntu container configured to mount on the victim server, thus gaining access to files on the host.
https://www.bleepingcompu...2Ta_h_sXZYzu5hfrHEvkL5-L0
Het blijkt toch dat het niet altijd goed gaat.
Als het steeds extra benoemt en gewaarschuwd wordt om op te blijven te letten dat container gedownload worden uit betrouwbare sources. En dus niet zomaar van iemand die hem online zet.
De blogs over waarop te letten voor veilig installeren van containers:
Use trusted images
Speaking about registries, it is important to highlight the importance of using only trusted images when building your containers. Although this seems obvious, but the truth is that there are third-party registries that do not have any governance policies for the images stored in them. It is important to know which images are available for use, understand their provenance, and review the content in them.
In addition, it is recommended to use images that don’t include unnecessary software packages which could lead to a larger attack surface. Having fewer components in your container reduces the number of available attack vectors.
https://pentestmag.com/a-...ther-and-other-endpoints/
Container beveiligings check list.
Use trusted, secure images
Speaking of registries, you should also be sure that the container images you pull come from a trusted source. This may seem overly obvious, but given that there are so many publicly available container images that can be downloaded quickly, it can be easy to pull an image accidentally from a source that is not verified or trusted.
https://resources.whiteso...lenges-and-best-practices
[
Voor 43% gewijzigd door
xbeam op 08-09-2020 23:03
]