-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
D04 - Secure Defaults #2
Comments
Hi @danehrlich1, in order to put the cart behind the horse, intended is to provide a structure first for each single D-point. Technical hints will go into one of the parts of the structure. D04 is specific for not only for the container / pod but also and mostly host and container orchestration tool. That is why it is @ #4. The main threat is supposed to be avoid on the system side exposed or misconfigured interfaces from kubernetes and friends. On the host e.g. a ~Debian default where rpc services are offered or any other network based service. For the container part, yes there might be something I could think of. Transport via https doesn't seem so relevant to me as Debian packages you are referring to a signed (do a 1) I haven't researched this but I know other distros which don't do this either. |
Apologies and thanks for helping me understand the intended structure of
the repo.
Also read over your other stuff and all good points / thanks for the
information. I agree and you are right, particularly on the privacy vs
actual security issue.
I’m going to hold off on anything else moving forward for now. Let me know
if there is specific help you need or research I can do though in the
meantime as the repo is built out.
…On Fri, Dec 21, 2018 at 7:00 PM Dirk Wetter ***@***.***> wrote:
Hi @danehrlich1 <https://github.com/danehrlich1>,
in order to put the cart behind the horse, intended is to provide a
structure first for each single D-point. Technical hints will go into one
of the parts of the structure.
D04 is specific for not only for the container / pod but also and mostly
host and container orchestration tool. That is why it is @ #4. The main
threat is supposed to be avoid on the system side exposed or misconfigured
interfaces from kubernetes and friends. On the host e.g. a ~Debian default
where rpc services are offered or any other network based service.
For the container part, yes there might be something I could think of.
Transport via https doesn't seem so relevant to me as Debian packages you
are referring to a signed (do a apt-key list). And if retrieving the
Debian keys come via HTTPS 1) apt-transport-https is a privacy
improvement, not a security improvement.
1) I haven't researched this but I know other distros which don't do this
either.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADM6EjqKMaRk8r6yvzse2GKfpBF3bdMYks5u7YRHgaJpZM4ZfPTE>
.
|
The slides of my talk in Brussels might be useful to understand what is supposed to be in the D sections. Because I saw too often open APIs or dashboards and e.g. Kubernetes does not seem to be able to clean up their crap (open kubelet, CVE-2018-1002105, etc.) D9 moved to D4 though. |
No need to apologize, you probably can't read my thoughts |
Am going to slowly add to this issue, and then eventually merge into repo:
apt install apt-transport-https
I think it's important to use TLS for all package installations. You'll have to have to separate install statements, which can cause slight increase in image size but is worth it.
apt-get --no-install-recommends -y install libtool
reduce surface area of attack by not installing extra packages during installation of packages too.
The text was updated successfully, but these errors were encountered: