Comments (12)
Wouldn't the appropriate fix for that scenario be to put the credentials into a secret that is exposed to the machine-controller but not the users?
from machine-controller.
This would mean the end user would get a admin account with access to everything except that secret.
That would be quite complicated to solve in Kubernetes. Also it would be complicated to maintain that set of permissions
from machine-controller.
That is not complicated at all, the user gets an account that has a clusterrole with *
on /machine.k8s.io/machines
. He can't be admin anyways because then he could just get the secret from the machine-controller deployment or pod.
And that is the exact way Kubernetes assumes to solve this kind of problems:
Putting this information in a secret is safer and more flexible than putting it verbatim in a pod definition or in a docker image
Ref: https://kubernetes.io/docs/concepts/configuration/secret/
from machine-controller.
In scenarios like Loodse's kubermatic or SAP's gardener (and even RedHats OpenShift Operator), the user has no access to the control plane.
Therefore the user has no access to the deployment of the machine-controller.
from machine-controller.
The only thing we should probably change is to add events and/or conditions to machines whenever we do something
from machine-controller.
In scenarios like Loodse's kubermatic or SAP's gardener (and even RedHats OpenShift Operator), the user has no access to the control plane.
Therefore the user has no access to the deployment of the machine-controller.
Ah. So this is primarily about storing credentials in a different cluster than the one that contains the machines, not about getting them from the environment
from machine-controller.
Its about the machine-controller running in a different environment (Kubernetes or even Systemd for example).
from machine-controller.
I see. So how would you name these env vars? Does something like that look fine to you?
spec:
cloudProvider: openstack
cloudProviderSpec:
password:
machineControllerEnvRef: <name-of-the-env-var>
Just as a sidenote, this opens a potential attack vendor when someone configures a server he or she controls as api endpoint for the cloudprovider, then tries random machineControllerEnvRef
values that could be configured in the machine-controller as credentials and logs that server-side.
We could probably lock that down by having a whitelist and/or only allowing a combination of credentials and api endpoint to be used that way in the relevant providers (just Openstack I think).
from machine-controller.
I would not add this to the ConfigVarString
.
I would rather add this functionality to the Resolver as a fallback.
The resolver accepts 3 parameters:
RawConfig
Config
Prefix
(a string likeopenstack
,aws
, etc.)
Via Reflection we iterate over all fields of the RawConfig:
- Secret ref? -> Resolve to Secret
- ConfigMap ref -> Resolve to ConfigMap
- Value set? -> Resolve to value
- Nothing until here? Try
Prefix_
+name of the field
This way we then also could eliminate missing resolve code within the cloud providers.
Though this might be a bit non obvious? If its too magic, an implementation with something like machineControllerEnvRef
should be fine as well.
from machine-controller.
A global prefix
for the resolver has two issues:
- multi-tenancy does not work, you can only use one account per cloud provider and machine-controller
- field name collisions are possible if more than one cloud provider has a field of a given name (e.G.
token
The latter could be solved by adding the providerName
to the spec, but I think the former can not be solved without using some value that is taken from the field.
Also we must be able to have constraints on field combinations, e.G. if you take user from the env you must also take password and api endpoint
from machine-controller.
A global
prefix
for the resolver has two issues:
- multi-tenancy does not work, you can only use one account per cloud provider and machine-controller
True, preferable over risking security issues IMO
- field name collisions are possible if more than one cloud provider has a field of a given name (e.G.
token
When using the provider name as prefix, that should not occur.
But i haven't considered the downsides here completely.
It might be simple adding support for a second kube-client?
Though this would break support for machines in the customer cluster...
from machine-controller.
A possible way would be to extend the ConfigVarString
& ConfigVarBool
type to look like:
cloudProviderSpec:
accessKeyId:
staticRef:
envVarName: "MACHINE_AWS_ACCESS_KEY_ID"
Though all env vars must begin with the prefix MACHINE_
Just to avoid leak credentials from the machine-controller pod itself
from machine-controller.
Related Issues (20)
- Updating SSH keys on existing Machines HOT 7
- Deterministic way to get private ip of machine HOT 2
- Vultr: Multiple Instances for Single Machine HOT 20
- vSphere: Allow configuration of disk provisioning for VMs HOT 6
- Node not ready due to cloud provider instance network issues HOT 3
- Failing tests for pull-machine-controller-e2e-hetzner HOT 1
- AWS: Support for passing CpuOptions HOT 8
- Support running shell script on Node boot HOT 8
- Can't create MachineDeployment: Post "https://machine-controller-webhook.kube-system.svc:443/machinedeployments?timeout=10s": context deadline exceeded HOT 1
- Stale token in cloud-init-settings/kube-system-hetzner-kubelet-bootstrap-config HOT 6
- KubeVirt GenerateRandMAC HOT 4
- Tags does not appear to work for Equinix provider HOT 4
- Support for networks with disabled port security HOT 4
- Expose metrics for MachineDeployment status HOT 2
- Support enabling cloud drive on OpenStack VMs HOT 5
- vSphere machine deployment with anti-affinity keeps recreating nodes
- Too many reconciliation errors/warnings for machine deployment objects HOT 2
- Future API group conflict with upstream CAPI HOT 3
- Remove user-data plugins from machine-controller
- E2E tests for Azure are failing HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from machine-controller.