saltstack / salt

Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:
https://repo.saltproject.io/
Apache License 2.0
14.1k stars 5.47k forks source link

salt-cloud's map with "saltify" seeds the master with private key, but master still retains it if deployment fails #55758

Open arizvisa opened 4 years ago

arizvisa commented 4 years ago

Description of Issue

Is this intended behaviour? After running salt-cloud -m w/ a mapfile, some of the hosts failed to be deployed, but the keys are still created despite that failure.

You can see this in the code under the create() method from the Cloud class in salt.cloud.__init__.py where the following creates the key and then assigns it to a dict.

        if deploy:
            if not make_master and 'master' not in minion_dict:
                log.warning(
                    'There\'s no master defined on the \'%s\' VM settings.',
                    vm_['name']
                )

            if 'pub_key' not in vm_ and 'priv_key' not in vm_:
                log.debug('Generating minion keys for \'%s\'', vm_['name'])
                priv, pub = salt.utils.cloud.gen_keys(
                    salt.config.get_cloud_config_value(
                        'keysize',
                        vm_,
                        self.opts
                    )
                )
                vm_['pub_key'] = pub
                vm_['priv_key'] = priv

A little bit later, it calls create. Note the error handler doesn't result in anything different happening which would imply that output would be checked by the caller, but when you look at any of the caller methods such as the "run_profile()" method, there's no error handling even attempting to remove the key.

        try:
            alias, driver = vm_['provider'].split(':')
            func = '{0}.create'.format(driver)
            with salt.utils.context.func_globals_inject(
                self.clouds[fun],
                __active_provider_name__=':'.join([alias, driver])
            ):
                output = self.clouds[func](vm_)
...
        except KeyError as exc:
            log.exception(
                'Failed to create VM %s. Configuration value %s needs '
                'to be set', vm_['name'], exc
            )

Setup

Setup something simple that uses deploy and can be easily made to fail. You can use the saltify driver with this as your provider.

saltify-linux:
    driver: saltify
    deploy: true
    force_minion_config: true
    remove_config_on_destroy: true
    shutdown_on_destroy: true

Now create some simple profile.

fuzz-linux@softmaker-office:
    ssh_username: doesnt matter
    password: letitdie
    provider: saltify-linux

Now produce a mapfile for the profile pointing to a host that doesn't exist, so that way it cannot possibly succeed.

fuzz-linux@softmaker-office:
 - shouldfail:
     ssh_host: 1.1.1.255

Steps to Reproduce Issue

Simply run salt-cloud -y -m /path/to/mapfile, let it fail, and then check salt-key. You'll see that the key for the host was still created despite the host not possibly succeeding, and salt-cloud emitting a failure. Even if you hit ctrl+c, before it tries to connect to the host, the key is still created which means salt-cloud is not handling errors.

Versions Report

The described logic is from the master branch, but if you really need a versions-report.

Salt Version:
           Salt: 2019.2.2

Dependency Versions:
 Apache Libcloud: Not Installed
            cffi: 1.12.3
        cherrypy: Not Installed
        dateutil: 2.8.0
       docker-py: Not Installed
           gitdb: 2.0.3
       gitpython: 3.0.5
           ioflo: 2.0.0
          Jinja2: 2.10.1
         libgit2: 0.28.2
         libnacl: 1.7
        M2Crypto: Not Installed
            Mako: 1.1.0
    msgpack-pure: Not Installed
  msgpack-python: 0.6.2
    mysql-python: Not Installed
       pycparser: 2.14
        pycrypto: 2.6.1
    pycryptodome: 3.9.4
          pygit2: 0.28.2
          Python: 3.7.5 (default, Dec 15 2019, 17:54:26)
    python-gnupg: Not Installed
          PyYAML: 5.1.2
           PyZMQ: 18.0.2
            RAET: Not Installed
           smmap: 0.9.0
         timelib: Not Installed
         Tornado: 4.5.3
             ZMQ: 4.3.2

System Versions:
           dist: Ubuntu 19.04 disco
         locale: UTF-8
        machine: x86_64
        release: 5.0.0-37-generic
         system: Linux
        version: Ubuntu 19.04 disco
stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

arizvisa commented 4 years ago

not stale, still being considered.

stale[bot] commented 4 years ago

Thank you for updating this issue. It is no longer marked as stale.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

arizvisa commented 4 years ago

not stale, tagged as considered.

stale[bot] commented 4 years ago

Thank you for updating this issue. It is no longer marked as stale.