Dev zone/Vault - Revision history

Dereckson at 23:52, 23 October 2025

2025-10-23T23:52:19Z

2025-09-14T22:13:46Z

@@ Line 87: / Line 87: @@
      return secret["data"]["data"]
 </syntaxhighlight>
 == Best practices ==
-=== Where to store credentials ===
+=== What secret path to choose for new credentials ===
 Are you setting a credential only for your app as human? Store it to apps/your-app/somepath.
@@ Line 95: / Line 106: @@
 To avoid to manage two paths with the same credential and facilitate rotation, it's encouraged to reuse credentials from a database directly from an ops/secrets/dbserver/ path.
 == Troubleshoot ==

2025-09-14T22:12:09Z

Query Vault from Jenkins

← Older revision		Revision as of 22:12, 14 September 2025
Line 99:		Line 99:
	If your CI job needs a credential stored in Vault, we've several possibilities:		If your CI job needs a credential stored in Vault, we've several possibilities:

	- get a token from Vault through JWT, an activity to explore as part of {{T\|2126}}		- get a token from Vault through JWT, an activity to explore as part of {{T\|2126}}
	- store a AppRole role-id/secret-id in Jenkins		- store a AppRole role-id/secret-id in Jenkins
	- store a AppRole role-id/secret-id on the server where the test deployment occurs		- store a AppRole role-id/secret-id on the server where the test deployment occurs
	- store directly the secret		- store directly the secret
	- refrain to use anything with credentials in CI		- refrain to use anything with credentials in CI

	From the possibilities, the first is the more promising and ~~will~~ be explored.		From the possibilities, the first is the more promising and should be explored in priority.

	== Troubleshoot ==		== Troubleshoot ==

2025-09-14T22:11:51Z

← Older revision		Revision as of 22:11, 14 September 2025
Line 95:		Line 95:

	To avoid to manage two paths with the same credential and facilitate rotation, it's encouraged to reuse credentials from a database directly from an ops/secrets/dbserver/ path.		To avoid to manage two paths with the same credential and facilitate rotation, it's encouraged to reuse credentials from a database directly from an ops/secrets/dbserver/ path.

			=== Query Vault from Jenkins ===
			If your CI job needs a credential stored in Vault, we've several possibilities:

			- get a token from Vault through JWT, an activity to explore as part of {{T\|2126}}
			- store a AppRole role-id/secret-id in Jenkins
			- store a AppRole role-id/secret-id on the server where the test deployment occurs
			- store directly the secret
			- refrain to use anything with credentials in CI

			From the possibilities, the first is the more promising and will be explored.

	== Troubleshoot ==		== Troubleshoot ==

2025-09-14T21:31:34Z

TLS - invalid path for certificate

← Older revision		Revision as of 21:31, 14 September 2025
Line 165:		Line 165:
	If you don't have it installed on your system, you can fetch it on operations repository: {{Ops file\|roles/core/certificates/files/nasqueron-vault-ca.crt}}		If you don't have it installed on your system, you can fetch it on operations repository: {{Ops file\|roles/core/certificates/files/nasqueron-vault-ca.crt}}

	Open a ~~ticket~~ on DevCentral if you need the certificate to be provisioned in that directory on a Nasqueron server.		Open a task on DevCentral if you need the certificate to be provisioned in that directory on a Nasqueron server. If needed, probably best to put it in /usr/local/share/certs/ everywhere and for the Linux servers, to symlink it to the relevant distribution path.

	[[Category:Knowledge base]]		[[Category:Knowledge base]]
	[[Category:Vault]]		[[Category:Vault]]

2025-09-14T21:30:31Z

TLS - invalid path for certificate

← Older revision		Revision as of 21:30, 14 September 2025
Line 150:		Line 150:

	=== TLS - invalid path for certificate ===		=== TLS - invalid path for certificate ===
	Examples here target FreeBSD servers. If you run the code elsewhere you can encounter this:		Examples here with hvac target deployment on our FreeBSD servers. If you run the code elsewhere, on your local machine for example, you can encounter this:

	OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /usr/local/share/certs/nasqueron-vault-ca.crt		OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /usr/local/share/certs/nasqueron-vault-ca.crt
Line 165:		Line 165:
	If you don't have it installed on your system, you can fetch it on operations repository: {{Ops file\|roles/core/certificates/files/nasqueron-vault-ca.crt}}		If you don't have it installed on your system, you can fetch it on operations repository: {{Ops file\|roles/core/certificates/files/nasqueron-vault-ca.crt}}

			Open a ticket on DevCentral if you need the certificate to be provisioned in that directory on a Nasqueron server.

	[[Category:Knowledge base]]		[[Category:Knowledge base]]
	[[Category:Vault]]		[[Category:Vault]]

2025-09-14T21:28:56Z

TLS - invalid path for certificate

← Older revision		Revision as of 21:28, 14 September 2025
Line 159:		Line 159:

	<syntaxhighlight lang="shell">		<syntaxhighlight lang="shell">
	$ mkdir -p /usr/local/share/certs		$ mkdir -p /usr/local/share/certs
	$ cp /etc/pki/ca-trust/source/anchors/nasqueron-vault-ca.crt /usr/local/share/certs/		$ cp /etc/pki/ca-trust/source/anchors/nasqueron-vault-ca.crt /usr/local/share/certs/
	</syntaxhighlight>		</syntaxhighlight>

2025-09-14T21:28:43Z

TLS - invalid path for certificate

← Older revision		Revision as of 21:28, 14 September 2025
Line 155:		Line 155:

	With Python code, it's a bad idea to remove the verify line, as in some distributions, it uses a bundle instead of the system certificates. Probably best to copy the certificate there too on your machine.		With Python code, it's a bad idea to remove the verify line, as in some distributions, it uses a bundle instead of the system certificates. Probably best to copy the certificate there too on your machine.

			For example for Fedora, as root:

			<syntaxhighlight lang="shell">
			$ mkdir -p /usr/local/share/certs
			$ cp /etc/pki/ca-trust/source/anchors/nasqueron-vault-ca.crt /usr/local/share/certs/
			</syntaxhighlight>

			If you don't have it installed on your system, you can fetch it on operations repository: {{Ops file\|roles/core/certificates/files/nasqueron-vault-ca.crt}}


	[[Category:Knowledge base]]		[[Category:Knowledge base]]
	[[Category:Vault]]		[[Category:Vault]]

2025-09-14T21:26:32Z

Troubleshoot

← Older revision		Revision as of 21:26, 14 September 2025
Line 148:		Line 148:

	You can set VAULT_ADDR at the default value <code>https://127.0.0.1:8200</code> if you use the tunnel on port 8200, the certificate is valid for both 127.0.0.1 and 172.27.27.7.		You can set VAULT_ADDR at the default value <code>https://127.0.0.1:8200</code> if you use the tunnel on port 8200, the certificate is valid for both 127.0.0.1 and 172.27.27.7.

			=== TLS - invalid path for certificate ===
			Examples here target FreeBSD servers. If you run the code elsewhere you can encounter this:

			OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /usr/local/share/certs/nasqueron-vault-ca.crt

			With Python code, it's a bad idea to remove the verify line, as in some distributions, it uses a bundle instead of the system certificates. Probably best to copy the certificate there too on your machine.


	[[Category:Knowledge base]]		[[Category:Knowledge base]]
	[[Category:Vault]]		[[Category:Vault]]

2025-09-14T21:12:28Z

Troubleshoot

@@ Line 132: / Line 132: @@
 Example of code above for hvac solve that issue.
 [[Category:Knowledge base]]
 [[Category:Vault]]