Operations grimoire/Eglide/Vault - Revision history

Dereckson at 20:30, 26 October 2024

2024-10-26T20:30:57Z

← Older revision		Revision as of 20:30, 26 October 2024
Line 90:		Line 90:

	That could simply by the symptom Vault uses the self-signed certificate in /etc/vault.d. Delete that directory by running againt Salt states (<code>sudo salt-call --local roles/shellserver/vault/config<code>).		That could simply by the symptom Vault uses the self-signed certificate in /etc/vault.d. Delete that directory by running againt Salt states (<code>sudo salt-call --local roles/shellserver/vault/config<code>).

			[[Category:Eglide]]
			[[Category:Vault]]

2023-05-29T17:53:09Z

Secrets K/V store

← Older revision		Revision as of 17:53, 29 May 2023
Line 44:		Line 44:
	* kv/user/ contains secrets by user accounts, for general purpose and unsalted services		* kv/user/ contains secrets by user accounts, for general purpose and unsalted services

	For example, Odderon services live in ~~secrets~~/service/odderon		For example, Odderon services live in kv/service/odderon

	Basic operations are:		Basic operations are:

2023-05-29T16:50:10Z

DRP :: Reconfigure Salt: salt-call --local uses minion config, not master one

← Older revision		Revision as of 16:50, 29 May 2023
Line 74:		Line 74:
	vault write -f auth/approle/role/salt-node/secret-id		vault write -f auth/approle/role/salt-node/secret-id

	The role_id and secret_id values belong to /etc/salt/~~master~~.d/vault.conf		The role_id and secret_id values belong to /etc/salt/minion.d/vault.conf

	Tip: you can test connection with <code>sudo _tests/config/salt-primary/vault.py</code> if you replace /usr/local/etc by /etc in it. You should then get the following content:		Tip: you can test connection with <code>sudo _tests/config/salt-primary/vault.py</code> if you replace /usr/local/etc by /etc in it. You should then get the following content:

2023-05-29T16:45:27Z

DRP :: Reconfigure Salt

← Older revision		Revision as of 16:45, 29 May 2023
Line 58:		Line 58:
	== Troubleshoot ==		== Troubleshoot ==
	=== DRP :: Reconfigure Salt ===		=== DRP :: Reconfigure Salt ===
			Prepare a policy for Salt:

			vault policy write salt-node /srv/salt/roles/shellserver/vault/files/salt.hcl

	Salt needs an approle auth method.		Salt needs an approle auth method.

	vault auth enable approle		vault auth enable approle
	vault write auth/approle/role/salt-node secret_id_ttl=10m \		vault write auth/approle/role/salt-node secret_id_ttl=10m \
			token_policies="jenkins" \
	token_num_uses=10 \		token_num_uses=10 \
	token_ttl=20m \		token_ttl=20m \
Line 70:		Line 75:

	The role_id and secret_id values belong to /etc/salt/master.d/vault.conf		The role_id and secret_id values belong to /etc/salt/master.d/vault.conf

			Tip: you can test connection with <code>sudo _tests/config/salt-primary/vault.py</code> if you replace /usr/local/etc by /etc in it. You should then get the following content:

			Can connect to Vault:
			metadata: {'role_name': 'salt-node'}
			policies: ['default', 'salt-node']
			token_policies: ['default', 'salt-node']
			token_type: service

	=== Certificates ===		=== Certificates ===

2023-05-29T15:48:56Z

@@ Line 57: / Line 57: @@
 == Troubleshoot ==
 === Certificates ===
 Certificate MUST has a 127.0.0.1 IP SAN:

2023-05-29T15:03:12Z

Troubleshoot

← Older revision		Revision as of 15:03, 29 May 2023
Line 62:		Line 62:
	Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": tls: failed to verify certificate: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs		Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": tls: failed to verify certificate: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs

	That could simply by the symptom Vault uses the self-signed certificate in /etc/vault.d		That could simply by the symptom Vault uses the self-signed certificate in /etc/vault.d. Delete that directory by running againt Salt states (<code>sudo salt-call --local roles/shellserver/vault/config<code>).

2023-05-29T15:02:11Z

← Older revision		Revision as of 15:02, 29 May 2023
Line 35:		Line 35:

	You can then restart Vault with <code>systemctl restart vault</code>.		You can then restart Vault with <code>systemctl restart vault</code>.

			== Secrets K/V store ==
			On Eglide, key value secrets are store in kv2 engine mounted under default path <code>kv/</code>

			Secrets can be organised by service or user account:

			* kv/service/ contains secrets sorted by services deployed through Salt or automated
			* kv/user/ contains secrets by user accounts, for general purpose and unsalted services

			For example, Odderon services live in secrets/service/odderon

			Basic operations are:

			* Store a secret: <code>vault kv put kv/service/acme/nickserv password=$(openssl rand -base64 18)</code>
			* Read a secret: <code>vault kv get kv/service/acme/nickserv</code>

			Secrets can be read:
			* for kv/user/<account>/* by a token issued for that user, on request
			* for kv/service/* by Salt to deploy services, by default
			* for kv/service/<service>/* to a specific service with Vault support through AppRole authentication, on request

	== Troubleshoot ==		== Troubleshoot ==

2023-05-29T10:44:45Z

Configuration

← Older revision		Revision as of 10:44, 29 May 2023
Line 10:		Line 10:
	Also, the package populates a systemd service to read /etc/vault.d/vault.hcl so it also needs to be replaced by our one, or by overrides.		Also, the package populates a systemd service to read /etc/vault.d/vault.hcl so it also needs to be replaced by our one, or by overrides.

	In any case, run <code>salt-call --local roles/shellserver/vault/config</code> to restore a correct configuration state.		In any case, run <code>salt-call --local state.apply roles/shellserver/vault/config</code> to restore a correct configuration state.

	== Certificates ==		== Certificates ==

2023-05-29T10:41:45Z

← Older revision		Revision as of 10:41, 29 May 2023
Line 7:		Line 7:

	The package generate auto-signing keys and a out-of-the-box configuration in /etc/vault.d that needs to be removed by our unit, if the package is reinstalled, there is a risk those files are respawned again.		The package generate auto-signing keys and a out-of-the-box configuration in /etc/vault.d that needs to be removed by our unit, if the package is reinstalled, there is a risk those files are respawned again.

			Also, the package populates a systemd service to read /etc/vault.d/vault.hcl so it also needs to be replaced by our one, or by overrides.

			In any case, run <code>salt-call --local roles/shellserver/vault/config</code> to restore a correct configuration state.

	== Certificates ==		== Certificates ==

2023-05-29T10:38:50Z

← Older revision		Revision as of 10:38, 29 May 2023
Line 31:		Line 31:

	You can then restart Vault with <code>systemctl restart vault</code>.		You can then restart Vault with <code>systemctl restart vault</code>.

			== Troubleshoot ==
			=== Certificates ===
			Certificate MUST has a 127.0.0.1 IP SAN:

			Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": tls: failed to verify certificate: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs

			That could simply by the symptom Vault uses the self-signed certificate in /etc/vault.d