## Issue There has been several issues related to the lack of tests validating that team member can access to their Vault and provision secrets. See https://gitlab.com/sylva-projects/sylva-elements/helm-charts/workload-team-defs/-/work_items/34 for instance Without doing E2E tests, it is required that the CI tests validate - The correct deployment of Vault and related policies - The correct deployment of team users and the related Vault / Keycloak object A proposal is - to add users in addition to teams - to tests Vault and Keycloak objects - to provision a secret (if possible through API) in a team Vault impersonnating a team user Tasks - Where team user should be defined ? It can be in https://gitlab.com/sylva-projects/sylva-elements/ci-tooling/sample-workload-teams-repo even if the target would be a dedicated (and similar) unit synchronizing team users. It can be in usual CI deployment values too. - Which objects are to be tested - How to provision a secret while impersonating a team user ## Technical details ### Passing team user to the CI values In the [CI values](https://gitlab.com/sylva-projects/sylva-elements/ci-tooling/ci-deployment-values/-/blob/main/1.6/all-ci-deployments.yml?ref_type=heads) one can add user and groups related to teams. For instance ```yaml keycloak: user_management: users: jeanne: enabled: true groups: devs: {} memberships: devs: jeanne: true ``` One has also to link the user to the teams by adding the following information ```yaml workload_team_defs: teams: teama: vault_write_group: devs ``` ### Objects to test Given a team called `teama`, one can see the following objects in the vault namespace - `jwtoidcauthenginerole.redhatcop.redhat.io/swct-teama` - `kubernetesauthenginerole.redhatcop.redhat.io/swct-teama` - `policy.redhatcop.redhat.io/swct-teama-read` - `policy.redhatcop.redhat.io/swct-teama-write` - `secretenginemount.redhatcop.redhat.io/swct-teama` Given a user called `jeanne `in the `devs `keycloak group associated to the `teama `team, one can see the following objects in the keycloak namespace - `secret/user-initial-password-jeanne` - `user.user.keycloak.m.crossplane.io/jeanne` - Several` providerconfigusage.keycloak.m.crossplane.io` of which the status include the following columns: ```bash NAME AGE CONFIG-NAME RESOURCE-KIND RESOURCE-NAME providerconfigusage.keycloak.m.crossplane.io/526d5fc5-423f-41e7-8295-f4fa6d35d6fb 4d keycloak-provider-config Group devs providerconfigusage.keycloak.m.crossplane.io/c2bdc70e-49d2-4db2-918c-25a6180f18e3 4d keycloak-provider-config User jeanne ``` ### Provisioning a secret #### Without OIDC To provision a secret, there is the [RandomSecret](https://github.com/redhat-cop/vault-config-operator/blob/main/docs/secret-management.md#randomsecret) CRD. In addition to team policies, we need to enable usage of a secret policy. A example which is working and ensure that a role with team RW policies works is the following one (which is not exactly the OIDC workflow) ```yaml --- apiVersion: v1 kind: ServiceAccount metadata: name: swct-teama-test-ci namespace: swct-teama --- apiVersion: redhatcop.redhat.io/v1alpha1 kind: Policy metadata: name: swct-teama-test-ci namespace: vault spec: connection: tLSConfig: tlsSecret: name: vault-ca address: https://vault.vault.svc.cluster.local:8200 authentication: path: kubernetes role: policy-manager-swct serviceAccount: name: vault name: swct-teama-test-ci policy: |- path "/sys/policies/password/+/generate" { capabilities = ["read"] } path "swct-teama/data/*" { capabilities = ["read"] } --- apiVersion: redhatcop.redhat.io/v1alpha1 kind: KubernetesAuthEngineRole metadata: name: swct-teama-test-ci namespace: vault spec: aliasNameSource: serviceaccount_uid authentication: path: kubernetes role: kubernetes-auth-manager serviceAccount: name: vault connection: address: https://vault.vault.svc.cluster.local:8200 tLSConfig: tlsSecret: name: vault-ca path: kubernetes policies: - swct-teama-read - swct-teama-write - swct-teama-test-ci targetNamespaces: targetNamespaces: - swct-teama targetServiceAccounts: - swct-teama-test-ci tokenExplicitMaxTTL: 0 tokenMaxTTL: 0 tokenNoDefaultPolicy: false tokenNumUses: 0 tokenPeriod: 0 tokenTTL: 0 tokenType: default --- apiVersion: redhatcop.redhat.io/v1alpha1 kind: RandomSecret metadata: name: swct-teama-test-ci namespace: swct-teama spec: connection: address: https://vault.vault.svc.cluster.local:8200 tLSConfig: tlsSecret: name: sylva-ca.crt authentication: path: kubernetes role: swct-teama-test-ci serviceAccount: name: swct-teama-test-ci path: swct-teama/data/bob name: swct-teama-test-ci secretKey: password secretFormat: passwordPolicyName: sylva-password-policy isKVSecretsEngineV2: true kvSecretRetainPolicy: Retain ``` It only tests the team policies and the presence of the team secret engine. It does not validate the customer usage relying on OIDC. #### With OIDC