How to set admin password during server create but not using user-data file
Hello there, This is how I download an ubuntu cloud image: wget -c https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.im... -O ~/noble-server-cloudimg-amd64.img virt-customize -a noble-server-cloudimg-amd64.img \ --timezone Asia/Tehran \ --root-password password:q \ --run-command 'sed -i "s/^disable_root.*/disable_root: false/" /etc/cloud/cloud.cfg' \ --run-command 'grep -q "^ssh_pwauth:" /etc/cloud/cloud.cfg && sed -i "s/^ssh_pwauth:.*/ssh_pwauth: true/" /etc/cloud/cloud.cfg || echo "ssh_pwauth: true" >> /etc/cloud/cloud.cfg' \ --run-command 'printf "PasswordAuthentication yes\nPermitRootLogin yes\n" > /etc/ssh/sshd_config.d/99-allow-root.conf' \ --run-command "sed -e 's/^[# ]*PasswordAuthentication.*/PasswordAuthentication yes/g' -i /etc/ssh/sshd_config || true" \ --run-command "sed -e 's/^[# ]*PermitRootLogin.*/PermitRootLogin yes/g' -i /etc/ssh/sshd_config || true" \ --run-command 'systemctl enable ssh || systemctl enable sshd' \ --run-command 'systemctl disable systemd-networkd-wait-online.service' openstack image create --file ~/noble-server-cloudimg-amd64.img --disk-format qcow2 --container-format bare --public --property os_distro=ubuntu --property hw_qemu_guest_agent=yes "Ubuntu 24" || true rm -f noble-server-cloudimg-amd64.img cat <<EOF > /root/userdata.txt #cloud-config chpasswd: list: | root:q expire: False ssh_pwauth: True cmd: - systemctl disable systemd-networkd-wait-online.service EOF openstack server create --image "Ubuntu 24" --flavor first --network public_network --config-drive True ahmad --password 'ahmad' This is how I create image. I'm going to find a way if possible, to set the admin password during the "server create". Currently the root login is only possible with password "q". The "ahmad" is not working. I know I can change it via user-data file (I intentionally added there but not using it), but the question is can I set the password during the server create? I tried to use "virt-customize --install qemu-guest-agent", but the virt-customize has no network, so no installation. I also know I can do this: 1. create server 2. do whatever I want (install guest agent, etc) 3. create snapshot 4. create server from that snapshot But the issue is it's not automatic (I should manually login to do the modification) and its size is much more than the cloud image. Like, from 500 megabytes which is cloud image, goes around 3 gigabytes which is the snapshot. Any ways to reach what I'm looking for? Or even any better ways to do that? Regards, Ahmad
Hi Ahmad, When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password, configuring the timezone, installing packages, or running custom scripts. https://docs.openstack.org/nova/2024.1/user/metadata.html#user-data Example: cloud-init.yml ============= #cloud-config timezone: Asia/Tehran user: ahmad password: ahmad chpasswd: { expire: False } ssh_pwauth: True Create Instance: openstack server create --image ubuntu-x86_64 --flavor ubuntu --network internal --user-data cloud-init.yml vm1
Hello Hamid, Thanks for the reply. I know this way, but I'm looking for another way to pass the password as metadata. Do you know any other ways? Regards, Ahmad On Tue, Oct 14, 2025 at 1:50 PM <hamid.lotfi@gmail.com> wrote:
Hi Ahmad, When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password, configuring the timezone, installing packages, or running custom scripts.
https://docs.openstack.org/nova/2024.1/user/metadata.html#user-data
Example: cloud-init.yml ============= #cloud-config timezone: Asia/Tehran user: ahmad password: ahmad chpasswd: { expire: False } ssh_pwauth: True
Create Instance: openstack server create --image ubuntu-x86_64 --flavor ubuntu --network internal --user-data cloud-init.yml vm1
Hi Ahmad, I replied in another thread, which suggested not to use metadata at all, as it's not designed to store or transmit passwords at all, especially in light of https://wiki.openstack.org/wiki/OSSN/OSSN-0074 But likely you have not received it. But I think there is actually a safe way (which is still discouraged in general) of having a password auth on login through os-server-password API in Nova: https://docs.openstack.org/api-ref/compute/#servers-password-servers-os-serv... Though, it would need a modification of all images, or supplying more metadata to them. 1. You'd need to have a script like this: https://paste.openstack.org/show/bn7fIrRf8Olkni9cI4QT/ 2. Add to cloud.cfg: https://paste.openstack.org/show/b1kcVmdbkWC2OUZL9yg3/ 3. In Horizon local_settings add "OPENSTACK_ENABLE_PASSWORD_RETRIEVE = True" What this flow will do: 1. A random password is being generated and set for user `clouduser` 2. A password is being encrypted with public part of SSH key, which you supplied for instance 3. Encrypted version of the password is sent back to the metadata 4. In horizon you can fetch the password from the metadata and decrypt it using your SSH private key I'd suggest to additionally modify the script/image to expire the password after the first login, as well as to prohibit password auth via SSH. But I can totally get why password auth might be valuable, especially in cases where instance get misconfigured and need to have a way to login via console. вт, 14 окт. 2025 г. в 17:44, Ahmad Milad Pour <miladpourahmad94@gmail.com>:
Hello Hamid,
Thanks for the reply. I know this way, but I'm looking for another way to pass the password as metadata.
Do you know any other ways?
Regards, Ahmad
On Tue, Oct 14, 2025 at 1:50 PM <hamid.lotfi@gmail.com> wrote:
Hi Ahmad, When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password, configuring the timezone, installing packages, or running custom scripts.
https://docs.openstack.org/nova/2024.1/user/metadata.html#user-data
Example: cloud-init.yml ============= #cloud-config timezone: Asia/Tehran user: ahmad password: ahmad chpasswd: { expire: False } ssh_pwauth: True
Create Instance: openstack server create --image ubuntu-x86_64 --flavor ubuntu --network internal --user-data cloud-init.yml vm1
On 14/10/2025 17:07, Dmitriy Rabotyagov wrote:
Hi Ahmad,
I replied in another thread, which suggested not to use metadata at all, as it's not designed to store or transmit passwords at all, especially in light of https://wiki.openstack.org/wiki/OSSN/OSSN-0074 But likely you have not received it.
But I think there is actually a safe way (which is still discouraged in general) of having a password auth on login through os-server-password API in Nova: https://docs.openstack.org/api-ref/compute/#servers-password-servers-os-serv...
Though, it would need a modification of all images, or supplying more metadata to them.
1. You'd need to have a script like this: https://paste.openstack.org/show/bn7fIrRf8Olkni9cI4QT/ 2. Add to cloud.cfg: https://paste.openstack.org/show/b1kcVmdbkWC2OUZL9yg3/ 3. In Horizon local_settings add "OPENSTACK_ENABLE_PASSWORD_RETRIEVE = True"
What this flow will do: 1. A random password is being generated and set for user `clouduser` 2. A password is being encrypted with public part of SSH key, which you supplied for instance 3. Encrypted version of the password is sent back to the metadata 4. In horizon you can fetch the password from the metadata and decrypt it using your SSH private key
I'd suggest to additionally modify the script/image to expire the password after the first login, as well as to prohibit password auth via SSH.
But I can totally get why password auth might be valuable, especially in cases where instance get misconfigured and need to have a way to login via console.
yes so this is a mostly undocumetned feature that was impletened specficly for widnows guest in cloud-base init it does however work for any instance as long as you have a first boot script that can generate the password and post it back to the metadata endpoint encypted via the public key the openstack client supprot decryypting the password with your ssh private key locally to print it in plain text. the final way to set a password is via the qemu guest agent. if you have the qemu guest agent installed you can use the nova api to set the admin password on the Administor or root user depending on if its windows or linux. using ssh keys or x509 certs is still the prefered way to access a guest but you can do it other ways even if they are less secure.
вт, 14 окт. 2025 г. в 17:44, Ahmad Milad Pour <miladpourahmad94@gmail.com>:
Hello Hamid,
Thanks for the reply. I know this way, but I'm looking for another way to pass the password as metadata.
Do you know any other ways?
Regards, Ahmad
On Tue, Oct 14, 2025 at 1:50 PM <hamid.lotfi@gmail.com> wrote:
Hi Ahmad, When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password, configuring the timezone, installing packages, or running custom scripts.
https://docs.openstack.org/nova/2024.1/user/metadata.html#user-data
Example: cloud-init.yml ============= #cloud-config timezone: Asia/Tehran user: ahmad password: ahmad chpasswd: { expire: False } ssh_pwauth: True
Create Instance: openstack server create --image ubuntu-x86_64 --flavor ubuntu --network internal --user-data cloud-init.yml vm1
On 14/10/2025 17:26, Sean Mooney wrote:
On 14/10/2025 17:07, Dmitriy Rabotyagov wrote:
Hi Ahmad,
I replied in another thread, which suggested not to use metadata at all, as it's not designed to store or transmit passwords at all, especially in light of https://wiki.openstack.org/wiki/OSSN/OSSN-0074 But likely you have not received it.
But I think there is actually a safe way (which is still discouraged in general) of having a password auth on login through os-server-password API in Nova: https://docs.openstack.org/api-ref/compute/#servers-password-servers-os-serv...
Though, it would need a modification of all images, or supplying more metadata to them.
1. You'd need to have a script like this: https://paste.openstack.org/show/bn7fIrRf8Olkni9cI4QT/ 2. Add to cloud.cfg: https://paste.openstack.org/show/b1kcVmdbkWC2OUZL9yg3/ 3. In Horizon local_settings add "OPENSTACK_ENABLE_PASSWORD_RETRIEVE = True"
What this flow will do: 1. A random password is being generated and set for user `clouduser` 2. A password is being encrypted with public part of SSH key, which you supplied for instance 3. Encrypted version of the password is sent back to the metadata 4. In horizon you can fetch the password from the metadata and decrypt it using your SSH private key
I'd suggest to additionally modify the script/image to expire the password after the first login, as well as to prohibit password auth via SSH.
But I can totally get why password auth might be valuable, especially in cases where instance get misconfigured and need to have a way to login via console.
yes so this is a mostly undocumetned feature that was impletened specficly for widnows guest in cloud-base init
it does however work for any instance as long as you have a first boot script that can generate the password and post it back to the metadata endpoint encypted via the public key
the openstack client supprot decryypting the password with your ssh private key locally to print it in plain text.
the final way to set a password is via the qemu guest agent. if you have the qemu guest agent installed you can use the nova api to set the admin password on the Administor or root user depending on if its windows or linux.
using ssh keys or x509 certs is still the prefered way to access a guest but you can do it other ways even if they are less secure.
this is the api that is used to set the admin password for a server https://docs.openstack.org/api-ref/compute/#change-administrative-password-c... again that requires the qemu guest agent to be installed in the guest image for it to work so you still have to modify your images but that at least is typically insalled in most cloud images by default.
вт, 14 окт. 2025 г. в 17:44, Ahmad Milad Pour <miladpourahmad94@gmail.com>:
Hello Hamid,
Thanks for the reply. I know this way, but I'm looking for another way to pass the password as metadata.
Do you know any other ways?
Regards, Ahmad
On Tue, Oct 14, 2025 at 1:50 PM <hamid.lotfi@gmail.com> wrote:
Hi Ahmad, When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password, configuring the timezone, installing packages, or running custom scripts.
https://docs.openstack.org/nova/2024.1/user/metadata.html#user-data
Example: cloud-init.yml ============= #cloud-config timezone: Asia/Tehran user: ahmad password: ahmad chpasswd: { expire: False } ssh_pwauth: True
Create Instance: openstack server create --image ubuntu-x86_64 --flavor ubuntu --network internal --user-data cloud-init.yml vm1
Hello there and thanks all. Regarding Dmitriy Rabotyagov, I read your suggestion but I was on my mobile and was not able to test. I'll try your way and get you back if it worked or I wasn't able to implement it correctly. I read all the emails and figured out very useful information. Regards, Ahmad On Tue, Oct 14, 2025 at 7:59 PM Sean Mooney <smooney@redhat.com> wrote:
On 14/10/2025 17:26, Sean Mooney wrote:
On 14/10/2025 17:07, Dmitriy Rabotyagov wrote:
Hi Ahmad,
I replied in another thread, which suggested not to use metadata at all, as it's not designed to store or transmit passwords at all, especially in light of https://wiki.openstack.org/wiki/OSSN/OSSN-0074 But likely you have not received it.
But I think there is actually a safe way (which is still discouraged in general) of having a password auth on login through os-server-password API in Nova:
https://docs.openstack.org/api-ref/compute/#servers-password-servers-os-serv...
Though, it would need a modification of all images, or supplying more metadata to them.
1. You'd need to have a script like this: https://paste.openstack.org/show/bn7fIrRf8Olkni9cI4QT/ 2. Add to cloud.cfg: https://paste.openstack.org/show/b1kcVmdbkWC2OUZL9yg3/ 3. In Horizon local_settings add "OPENSTACK_ENABLE_PASSWORD_RETRIEVE = True"
What this flow will do: 1. A random password is being generated and set for user `clouduser` 2. A password is being encrypted with public part of SSH key, which you supplied for instance 3. Encrypted version of the password is sent back to the metadata 4. In horizon you can fetch the password from the metadata and decrypt it using your SSH private key
I'd suggest to additionally modify the script/image to expire the password after the first login, as well as to prohibit password auth via SSH.
But I can totally get why password auth might be valuable, especially in cases where instance get misconfigured and need to have a way to login via console.
yes so this is a mostly undocumetned feature that was impletened specficly for widnows guest in cloud-base init
it does however work for any instance as long as you have a first boot script that can generate the password and post it back to the metadata endpoint encypted via the public key
the openstack client supprot decryypting the password with your ssh private key locally to print it in plain text.
the final way to set a password is via the qemu guest agent. if you have the qemu guest agent installed you can use the nova api to set the admin password on the Administor or root user depending on if its windows or linux.
using ssh keys or x509 certs is still the prefered way to access a guest but you can do it other ways even if they are less secure.
this is the api that is used to set the admin password for a server
https://docs.openstack.org/api-ref/compute/#change-administrative-password-c...
again that requires the qemu guest agent to be installed in the guest image for it to work so you still have to modify your images but that at least is typically insalled in most cloud images by default.
вт, 14 окт. 2025 г. в 17:44, Ahmad Milad Pour <miladpourahmad94@gmail.com>:
Hello Hamid,
Thanks for the reply. I know this way, but I'm looking for another way to pass the password as metadata.
Do you know any other ways?
Regards, Ahmad
On Tue, Oct 14, 2025 at 1:50 PM <hamid.lotfi@gmail.com> wrote:
Hi Ahmad, When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password, configuring the timezone, installing packages, or running custom scripts.
https://docs.openstack.org/nova/2024.1/user/metadata.html#user-data
Example: cloud-init.yml ============= #cloud-config timezone: Asia/Tehran user: ahmad password: ahmad chpasswd: { expire: False } ssh_pwauth: True
Create Instance: openstack server create --image ubuntu-x86_64 --flavor ubuntu --network internal --user-data cloud-init.yml vm1
Hello all and thanks all for the helps, documents and replies. I added the retrieve password, created SSH key. At first I tried with ECDSA, but later I figured out it should be RSA. Now I'm able to get the password both from horizon and cli. Thanks all for the suggestion. Regards, Ahmad On Tue, Oct 14, 2025 at 9:01 PM Ahmad Milad Pour <miladpourahmad94@gmail.com> wrote:
Hello there and thanks all.
Regarding Dmitriy Rabotyagov, I read your suggestion but I was on my mobile and was not able to test.
I'll try your way and get you back if it worked or I wasn't able to implement it correctly.
I read all the emails and figured out very useful information.
Regards, Ahmad
On Tue, Oct 14, 2025 at 7:59 PM Sean Mooney <smooney@redhat.com> wrote:
On 14/10/2025 17:26, Sean Mooney wrote:
On 14/10/2025 17:07, Dmitriy Rabotyagov wrote:
Hi Ahmad,
I replied in another thread, which suggested not to use metadata at all, as it's not designed to store or transmit passwords at all, especially in light of https://wiki.openstack.org/wiki/OSSN/OSSN-0074 But likely you have not received it.
But I think there is actually a safe way (which is still discouraged in general) of having a password auth on login through os-server-password API in Nova:
https://docs.openstack.org/api-ref/compute/#servers-password-servers-os-serv...
Though, it would need a modification of all images, or supplying more metadata to them.
1. You'd need to have a script like this: https://paste.openstack.org/show/bn7fIrRf8Olkni9cI4QT/ 2. Add to cloud.cfg: https://paste.openstack.org/show/b1kcVmdbkWC2OUZL9yg3/ 3. In Horizon local_settings add "OPENSTACK_ENABLE_PASSWORD_RETRIEVE = True"
What this flow will do: 1. A random password is being generated and set for user `clouduser` 2. A password is being encrypted with public part of SSH key, which you supplied for instance 3. Encrypted version of the password is sent back to the metadata 4. In horizon you can fetch the password from the metadata and decrypt it using your SSH private key
I'd suggest to additionally modify the script/image to expire the password after the first login, as well as to prohibit password auth via SSH.
But I can totally get why password auth might be valuable, especially in cases where instance get misconfigured and need to have a way to login via console.
yes so this is a mostly undocumetned feature that was impletened specficly for widnows guest in cloud-base init
it does however work for any instance as long as you have a first boot script that can generate the password and post it back to the metadata endpoint encypted via the public key
the openstack client supprot decryypting the password with your ssh private key locally to print it in plain text.
the final way to set a password is via the qemu guest agent. if you have the qemu guest agent installed you can use the nova api to set the admin password on the Administor or root user depending on if its windows or linux.
using ssh keys or x509 certs is still the prefered way to access a guest but you can do it other ways even if they are less secure.
this is the api that is used to set the admin password for a server
https://docs.openstack.org/api-ref/compute/#change-administrative-password-c...
again that requires the qemu guest agent to be installed in the guest image for it to work so you still have to modify your images but that at least is typically insalled in most cloud images by default.
вт, 14 окт. 2025 г. в 17:44, Ahmad Milad Pour <miladpourahmad94@gmail.com>:
Hello Hamid,
Thanks for the reply. I know this way, but I'm looking for another way to pass the password as metadata.
Do you know any other ways?
Regards, Ahmad
On Tue, Oct 14, 2025 at 1:50 PM <hamid.lotfi@gmail.com> wrote:
Hi Ahmad, When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password, configuring the timezone, installing packages, or running custom scripts.
https://docs.openstack.org/nova/2024.1/user/metadata.html#user-data
Example: cloud-init.yml ============= #cloud-config timezone: Asia/Tehran user: ahmad password: ahmad chpasswd: { expire: False } ssh_pwauth: True
Create Instance: openstack server create --image ubuntu-x86_64 --flavor ubuntu --network internal --user-data cloud-init.yml vm1
Thanks, Dmitriy. I completely agree that sensitive information should not be sent via user-data. However, the point is that if we expire the password by sending it like this: chpasswd: { expire: True } The password shown in the metadata becomes invalid, and the new password is not displayed there.
This assumes that the user will actually login with the password right after VM creation. What I have seen in various clouds, that this might not be the case for years for some VMs, as prevailing amount of users are using ssh keys for first and all consecutive logins. But yes, sure, this really depends on the usecase and policies and setup. On Wed, 15 Oct 2025, 07:20 , <hamid.lotfi@gmail.com> wrote:
Thanks, Dmitriy. I completely agree that sensitive information should not be sent via user-data. However, the point is that if we expire the password by sending it like this: chpasswd: { expire: True } The password shown in the metadata becomes invalid, and the new password is not displayed there.
On 2025-10-14 10:19:32 -0000 (-0000), hamid.lotfi@gmail.com wrote:
When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password [...] password: ahmad [...]
While probably okay for testing purposes, this is not safe in general. See https://wiki.openstack.org/wiki/OSSN/OSSN-0074 for one reason, but there are also other ways metadata might end up exposed. The better solution, and what basically everyone I know does, is to avoid password login and use SSH key authentication instead. Even the risks from instance metadata leaks notwithstanding, passwords can (and will) be remotely brute-forced if your sshd is listening on an Internet-reachable address. If someone manages to fish your SSH public key digest out of metadata on the other hand, there's not really anything they can do with that. -- Jeremy Stanley
On 14/10/2025 15:38, Jeremy Stanley wrote:
On 2025-10-14 10:19:32 -0000 (-0000), hamid.lotfi@gmail.com wrote:
When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password [...] password: ahmad [...]
While probably okay for testing purposes, this is not safe in general. See https://wiki.openstack.org/wiki/OSSN/OSSN-0074 for one reason, but there are also other ways metadata might end up exposed.
The better solution, and what basically everyone I know does, is to avoid password login and use SSH key authentication instead. Even the risks from instance metadata leaks notwithstanding, passwords can (and will) be remotely brute-forced if your sshd is listening on an Internet-reachable address. If someone manages to fish your SSH public key digest out of metadata on the other hand, there's not really anything they can do with that.
+100 the nova metadata api is not intened to sore password cert or any other sensitive info. that is explcity not an intened usecase for this api. we store metadata in plain text and auth to that endpoint is optional. most deployment will use a shared secerte between nova and neutron for some minimal auth but the metadata api is not a secret store. you should use barbican or vault if you need secret storage.
But I think there is actually a relatively safe way of having a password auth on login through os-server-password API in Nova: https://docs.openstack.org/api-ref/compute/#servers-password-servers-os-serv... Though, it would need a modification of all images, or supplying more metadata to them. 1. You'd need to have a script like this: https://paste.openstack.org/show/bn7fIrRf8Olkni9cI4QT/ 2. Add to cloud.cfg: https://paste.openstack.org/show/b1kcVmdbkWC2OUZL9yg3/ 3. In Horizon local_settings add "OPENSTACK_ENABLE_PASSWORD_RETRIEVE = True" What this flow will do: 1. A random password is being generated and set for user `clouduser` 2. A password is being encrypted with public part of SSH key, which you supplied for instance 3. Encrypted version of the password is sent back to the metadata 4. In horizon you can fetch the password from the metadata and decrypt it using your SSH private key I'd suggest to additionally modify the script/image to expire the password after the first login, as well as to prohibit password auth via SSH. But I can totally get why password auth might be valuable, especially in cases where instance get misconfigured and need to have a way to login via console. вт, 14 окт. 2025 г. в 16:43, Sean Mooney <smooney@redhat.com>:
On 14/10/2025 15:38, Jeremy Stanley wrote:
On 2025-10-14 10:19:32 -0000 (-0000), hamid.lotfi@gmail.com wrote:
When creating an instance in OpenStack, you can use the --user-data option to pass a cloud-init configuration file to the instance at boot time. This file allows you to automate initial setup tasks such as setting a user password [...] password: ahmad [...]
While probably okay for testing purposes, this is not safe in general. See https://wiki.openstack.org/wiki/OSSN/OSSN-0074 for one reason, but there are also other ways metadata might end up exposed.
The better solution, and what basically everyone I know does, is to avoid password login and use SSH key authentication instead. Even the risks from instance metadata leaks notwithstanding, passwords can (and will) be remotely brute-forced if your sshd is listening on an Internet-reachable address. If someone manages to fish your SSH public key digest out of metadata on the other hand, there's not really anything they can do with that.
+100
the nova metadata api is not intened to sore password cert or any other sensitive info.
that is explcity not an intened usecase for this api.
we store metadata in plain text and auth to that endpoint is optional.
most deployment will use a shared secerte between nova and neutron for some minimal auth but the metadata api is not a secret store. you should use barbican or vault if you need secret storage.
participants (5)
-
Ahmad Milad Pour
-
Dmitriy Rabotyagov
-
hamid.lotfi＠gmail.com
-
Jeremy Stanley
-
Sean Mooney