Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Consider securing etcd #6

Open
pstadler opened this issue May 8, 2017 · 6 comments
Open

Consider securing etcd #6

pstadler opened this issue May 8, 2017 · 6 comments
Labels
security

Comments

@pstadler
Copy link
Member

pstadler commented May 8, 2017

Compromised containers could access and leak important data stored in etcd.

Related comment on Hacker News: https://news.ycombinator.com/item?id=14291817
@pstadler
Copy link
Member Author

pstadler commented May 8, 2017

See: https://raesene.github.io/blog/2017/05/01/Kubernetes-Security-etcd/ via @raesene

@Informatic
Copy link

Informatic commented Jun 9, 2018 •
edited
Loading

Taking into account that kubeadm is able to setup etcd itself on master now (without clustering, of course), is there really any advantage of having it setup manually here, considering all the security implications?

Isn't kubernetes master a SPOF anyway? (All the components talk to kube-apiserver, and that wouldn't be rescheduled to any other node when something breaks, as far as I understand)

Only advantage I can think of is data resiliency, but assuming master gets completly destroyed, you'd still loose kube-apiserver keypair and all... I wouldn't consider it better than sensible backup strategy :(

There's simply no need to make use of additional security layers as long as the service is bound to an end-to-end secured VPN interface.

As seen above, this is very misleading - I think this issue should be linked somewhere in that section, and possibly that full sentece be removed completely.

@pstadler
Copy link
Member Author

Started working on it: https://github.com/hobby-kube/provisioning/pull/39/files

@pstadler
Copy link
Member Author

@Informatic I don't like the idea of having an unclustered etcd running.

@pstadler
Copy link
Member Author

@Informatic just wanted to add that all your points are valid. Will consider your input moving forward 👍🏻

@Govinda-Fichtner
Copy link

Are there any updates regarding this?

backwardn pushed a commit to backwardn/guide that referenced this issue Nov 20, 2019
@abhinav
Avoid string-to-slice: Drop reference to issue (hobby-kube#6)
60a61cc 
The relevant GH issue was closed. This updates this section to a general
"avoid converting the same string to byte slices repeatedly"
recommendation.

To justify the recommendation, I've included the relative performance of
the two cases in the output.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
security
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Govinda-Fichtner @pstadler @Informatic