Difference between revisions of "StarlingX/Containers/Applications/app-vault"
(→Testing) |
(→Configure using CLI and REST API) |
||
| Line 41: | Line 41: | ||
=== Configure using CLI and REST API === | === Configure using CLI and REST API === | ||
| + | Refer to the following documents for examples of configuring the vault using CLI and REST API: | ||
| + | * [https://docs.starlingx.io/security/kubernetes/configure-vault-using-the-cli.html Configure Vault Using the Vault CLI] | ||
| + | * [https://docs.starlingx.io/security/kubernetes/configure-vault.html Configure Vault Using the Vault REST API] | ||
| + | |||
| + | Follow each configuration with sanity of the workflows in Vault Aware and Unaware test section. | ||
=== Vault Aware and Unaware === | === Vault Aware and Unaware === | ||
Revision as of 19:27, 29 August 2024
Contents
Application: vault-armada-app
Source
Building
- From the Debian Build environment:
VAULT_PKGS="python3-k8sapp-vault,vault-helm,vault-manager-helm,stx-vault-helm" build-pkgs -c -p $VAULT
The packages contain:
- python3-k8sapp-vault - sysinv integrations; helm and lifecycle
- vault-helm - the build of upstream vault helm chart
- vault-manager-helm - the build of Starlingx vault-manager helm chart
- stx-vault-helm - the Starlingx application; metadata, fluxcd yaml
The final package stx-vault-helm contains the output of the others. The stx-vault-helm package is installed on the ISO. The installed application tarball is '/usr/local/share/applications/helm/vault-*.tgz'
Testing
Vault sanity should typically include:
- application lifecycle: upload, apply, remove, abort, delete, update, and helm overrides
- Vault with replicas=1 (AIO-SX) and replicas=3 (AIO-DX + worker or standard controller)
- Configure vault with CLI and REST API
- Workflow for applications that are Vault aware (REST API) and unaware (vault injector)
- Pod recovery
- Vault backup and restore
- Vault-manager features including: rekey, PVC conversion (upgrade)
- Download images from private registry; network isolation test
Application Lifecycle
Refer to Application Commands and Helm Overrides Typically changes for the following should be accompanied with testing for the application lifecycle:
- Sysinv integrations, package python3-k8sapp-vault
- New and updated helm charts or chart overrides (values.yaml)
And also at the end of each release cycle the sanity for application lifecycle should be asserted.
Vault with replicas 1 and 3
When the vault app is applied on AIO-SX, the vault server statefulset is configured automatically with replicas=1. When there are three or more controller and worker nodes provisioned in the cluster then the vault server statefulset will be configured automatically with replicas=3.
Sanity for replicas=3 should include vault HA - observation that a standby vault server becomes active when the active server is restarted gracefully.
Refer also to "Pod Recovery" section.
Configure using CLI and REST API
Refer to the following documents for examples of configuring the vault using CLI and REST API:
Follow each configuration with sanity of the workflows in Vault Aware and Unaware test section.
