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

[Security] vsphere cloud provider configuration should use secrets for credentials #194

Closed
sidharthsurana opened this issue Feb 4, 2019 · 5 comments · Fixed by #419
Closed

[Security] vsphere cloud provider configuration should use secrets for credentials #194

sidharthsurana opened this issue Feb 4, 2019 · 5 comments · Fixed by #419
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.

Comments

@sidharthsurana
Copy link
Contributor

Currently the cloud config that we generate as /etc/kubernetes/cloud-config/cloud-config.yaml file on the master node contains the vsphere credentials in plain text format. vsphere cloud provider supports providing these sensitive credentials via secrets out of the box. (for e.g see the test case here). Note that this approach is supported by both in-tree and out-of-tree version of the vsphere cloud provider.
We need to move towards setting the vcenter credentials via secrets for the consumption of the vsphere cloud provider configuration.
However, the only catch here is that today we use kubeadm to setup and configure the kubernetes service with the vsphere cloud provider. Thus, within the workflow if kubeadm we do not have a means to create the secret needed for the vsphere cloud provider prior to starting it. Thus we would need to overcome this limitation somehow.

Note: This issue is different that #9 as that is related to credentials stored as part of the cluster-api objects and this issue is about consumption of the credentials for the vsphere cloud provider that we configure for the target cluster.
@sflxn sflxn added this to the v1alpha1 milestone Feb 11, 2019
@sflxn sflxn added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 11, 2019
@yuyangbj
Copy link
Contributor

yuyangbj commented Mar 5, 2019

I agree, actually I also noticed this problem when I tried the cluster api first time.

@yuyangbj
Copy link
Contributor

yuyangbj commented Mar 5, 2019

In the cluster.yaml file, I am thinking if we need to use fernet to encrypt the vsphere credential.

@sflxn sflxn added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Mar 6, 2019
@sflxn sflxn modified the milestones: v1alpha1, Next Mar 6, 2019
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 4, 2019
@fejta-bot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jul 5, 2019
@moshloop moshloop mentioned this issue Jul 8, 2019
Merged
@frapposelli
Copy link
Member

/remove-lifecycle rotten

@k8s-ci-robot k8s-ci-robot removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Jul 8, 2019
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Cloud provider credentials as secret akutz/cluster-api-provider-vsphere
6 participants
@frapposelli @sflxn @yuyangbj @sidharthsurana @k8s-ci-robot @fejta-bot