If you’re discussing using something from the unit (controller machine 0, for instance) within a charm to configure/manipulate juju, I think this breaks the security model and wouldn’t work well if you wanted to land that charm elsewhere in the cloud). Running anything on the controllers should be avoided, though I know we are running some telemetry and alerting subordinates on the controller models today, I think if you want to monitor juju, you’ll need to provide your application with credentials.
I’d suggest passing a registration key to the charm so it can initiate and set it’s own password and manage it’s own juju config files used for libjuju calls. This also allows you to manage the level of access for that credential rather than providing full admin access, you could grant read-only to such a credential to limit the exposure your charm having juju credentials might have.
Also look into the “trust” command which allows your application access to the underlying cloud credentials (this may be more useful for maas activities from a juju charm, as it provides the cloud credentials that juju uses to the charm so a charm can, for instance, request storage resources from the cloud provider (see aws/openstack-integrator charms).