Invalid Juju Credentials allow users to remove applications

[Heitor]

This just happened to me:

```
$ juju add-model test vsphere/region-JUJU-1
ERROR cannot create model: failed to create environ: dialing client: ServerFaultCode: Cannot complete login due to an incorrect user name or password.
```

But I successfully `juju remove-application foo` in a model in this `vsphere/region-JUJU-1` cloud! I can't add models, I can't deploy applications, and I CAN remove-applications.

In Juju Status, i constantly see the message "suspended since cloud credential is not valid".

I can issue some commands to try to understand what is going on, but the output of these juju commands are cryptic:

```
$ juju update-credentials vsphere
This operation can be applied to both a copy on this client and to the one on a controller.
Do you want to update credential "" on cloud "vsphere" on:
    1. client only (--client)
    2. controller "jimm.foo.com" only (--controller jimm.foo.com)
    3. both (--client --controller jimm.foo.com)
Enter your choice, or type Q|q to quit: 2
Controller credential "user-vsphere" for user "user" for cloud "vsphere" on controller "jimm.foo.com" updated.
For more information, see 'juju show-credential vsphere user-vsphere'.

$ juju show-credential vsphere user-vsphere
WARNING removing secrets from credentials for cloud user-vsphere: cloud vsphere not valid
no registered provider for "vsphere"
No credentials from this client or from a controller to display.
```

I don't know what is going on.

[Ian Booth (wallyworld)]

When adding a model, Juju checks that the credential used by the model is valid - it makes a cheap API call to the cloud and reports any error encountered.

The juju remove-application CLI command doesn't talk to the cloud - it updates the Juju model to mark the application as "to be removed" and this is probably what you saw as being a successful run. Juju will then act on this and attempt to destroy any machines and other resources provisioned for that application. If the model credential is invalid, this cleanup will not be able to be done and juju status --formay yaml or even juju show-model should indicate that the model is suspended due to the bad cedential.

Updating the credential on the controller to unblock the model was indeed the right thing to do - when ever the controller sees a model's credential is updated, and the model is suspended, it will attempt to again see if the credential is valid and id so, will unsuspend the model.

The fact that juju show-credential did not work does indeed appear to be a bug that needs to be fixed.

[John A Meinel (jameinel)]

To confirm, the `juju remove-application foo` that you are running is in a different model that happens to use the same credential.

It is currently intentional that you would be able to manipulate the desired model even if the credential was invalid, but it is something that could be argued. What is the particular reason why you feel updating a model should be blocked (to make sure we capture your concrete use case)

[John A Meinel (jameinel)]

We do feel like we can polish the UX around 'juju show-credential'

[Heitor (heitorpbittencourt)]

> It is currently intentional that you would be able to manipulate the desired model even if the credential was invalid,

This raises some serious red flags to me. What else can we do in Juju without valid credentials?

> What is the particular reason why you feel updating a model should be blocked

Imagine I have a controller/cloud/model/etc and give admin permissions to users A, B, and C. User B then leaves the company. I want to revoke user B's permissions, so they can't do anything including, but not limited to, read/modify configs, deploy/remove units/machines, create/destroy models, ssh, etc.

> We do feel like we can polish the UX around 'juju show-credential'

Thank you, that would be very appreciated!

[Heitor (heitorpbittencourt)]

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.

[John A Meinel (jameinel)]

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
>
>

[Erik Lönroth (erik-lonroth)]

My 10 cents on this issue:

Users of juju think credentials are the single most cryptic/difficult thing to manage and understand.

I agree on this and we have spent very, very much time trying to make this a situation manageable to users. There are multiple and too many pitfalls to address them individually and Heitor:s description is very typical.

I've met no-one that can interpret these errors and users are never able to resolve them by them selves - which means that it ends up in my lap to resolve or the users just gives up and believes juju is broken.

I'm not sure what to do really to fundamentally make this a better situation...