Comment 6 for bug 1943182

The credential used to talk to the Juju controller is a different
"credential" to that used to talk to the underlying provider (vsphere).
There are things like changing config, relating applications, etc, that
have nothing to do with the underlying provisioning of instances that are
valid mutations of the "Juju Model".

You can certainly revoke a user's access to the controller at any point,
without invalidating the controller's access to the underlying provisioner.
And you can invalidate the underlying provider credential and use 'juju
update-credential' to change the credential that the Juju controller uses
to maintain instances, etc.

It is certainly fair that "remove-unit"/"remove-application" will have a
pending request to reap the instance, but won't be able to act on them if
the current set of provider credentials is invalid. When it is updated
(juju update-credential) I would expect them to be applied.

I think it is fair to say "we would like better feedback that their request
won't be immediately applied because of other issues".

On Wed, Sep 15, 2021 at 9:40 AM Heitor <email address hidden> wrote:

> Another use case that came to my mind:
>
> A user's credentials leaks. I want to revoke them, so no third party can
> use them.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1943182
>
> Title:
> Invalid Juju Credentials allow users to remove applications
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1943182/+subscriptions
>
>