Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Namespaced Service Accounts #336

Open
kcighon opened this issue Aug 21, 2023 · 1 comment · Fixed by saltosystems/vault-secrets-operator#1
Open

Namespaced Service Accounts #336

kcighon opened this issue Aug 21, 2023 · 1 comment · Fixed by saltosystems/vault-secrets-operator#1
Labels
enhancement New feature or request

Comments

@kcighon
Copy link

kcighon commented Aug 21, 2023 •
edited
Loading

Off the back of #291 and #274, should the service account defined in VaultAuth also support namespaces? This will support global default Auth and Connections

If a VaultStaticSecret is located in a namespace which differs to the VaultAuth, the VaultStaticSecret will try to use the service account defined in the VaultAuth from within the VaultStaticSecret namespace.

Observed error in VaultStaticSecret:

Warning VaultClientConfigError 7m5s (x18 over 18m) VaultStaticSecret Failed to get Vault auth login: ServiceAccount "my-vso-sa" not found

Possible solution - as with #291, allow for namespaced values for VaultAuth's spec.kubernetes.serviceAccount. e.g.
spec.kubernetes.serviceAccount: vault-secret-operator-system/my-vso-sa
@kcighon kcighon added the enhancement New feature or request label Aug 21, 2023
@inigohu inigohu mentioned this issue Oct 27, 2023
Merged
oninugarte pushed a commit to saltosystems/vault-secrets-operator that referenced this issue Oct 27, 2023
@inigohu @oninugarte
internal/credentials: make kubernetes auth service account namespaced
f9ee0e9 
This commit adds the ability to specify a namespace for the service account used to authenticate to Vault.
This is useful when you want to use a service account in a different namespace than the one the secret (vaultStaticSecret, vaultDynamicSecret) is located.
This change is backwards compatible, so if no namespace is specified, the service account will be looked up in the same namespace as the secret.

Example: Here the service account that will be used to authenticate to Vault is the service account `default` that it is in the namespace "vault-secrets-operator-system".
```yaml
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: app
spec:
  vaultConnectionRef: vault-connection
  allowedNamespaces:
    - "*"
  method: kubernetes
  mount: demo-auth-mount
  kubernetes:
    role: role1
    serviceAccount: vault-secrets-operator-system/default
```

Closes hashicorp#336
inigohu added a commit to inigohu/vault-secrets-operator that referenced this issue Oct 27, 2023
@inigohu
internal/credentials: make kubernetes auth service account namespaced
45f95af 
This commit adds the ability to specify a namespace for the service account used to authenticate to Vault. This is useful when you want to use a service account in a different namespace than the one the secret (vaultStaticSecret, vaultDynamicSecret) is located.
This change is backwards compatible, so if no namespace is specified, the service account will be looked up in the same namespace as the secret.

Example: Here the service account that will be used to authenticate to Vault is the service account `default` that it is in the namespace "vault-secrets-operator-system".
```yaml
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: app
spec:
  vaultConnectionRef: vault-connection
  allowedNamespaces:
    - "*"
  method: kubernetes
  mount: demo-auth-mount
  kubernetes:
    role: role1
    serviceAccount: vault-secrets-operator-system/default
```

Closes hashicorp#336
@inigohu inigohu mentioned this issue Oct 27, 2023
Closed
oninugarte pushed a commit to saltosystems/vault-secrets-operator that referenced this issue Jan 4, 2024
@inigohu @oninugarte
internal/credentials: make kubernetes auth service account namespaced
bcf6bd2 
This commit adds the ability to specify a namespace for the service account used to authenticate to Vault.
This is useful when you want to use a service account in a different namespace than the one the secret (vaultStaticSecret, vaultDynamicSecret) is located.
This change is backwards compatible, so if no namespace is specified, the service account will be looked up in the same namespace as the secret.

Example: Here the service account that will be used to authenticate to Vault is the service account `default` that it is in the namespace "vault-secrets-operator-system".
```yaml
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: app
spec:
  vaultConnectionRef: vault-connection
  allowedNamespaces:
    - "*"
  method: kubernetes
  mount: demo-auth-mount
  kubernetes:
    role: role1
    serviceAccount: vault-secrets-operator-system/default
```

Closes hashicorp#336
oninugarte pushed a commit to saltosystems/vault-secrets-operator that referenced this issue Jan 4, 2024
@inigohu @oninugarte
internal/credentials: make kubernetes auth service account namespaced
ba5cff3 
This commit adds the ability to specify a namespace for the service account used to authenticate to Vault.
This is useful when you want to use a service account in a different namespace than the one the secret (vaultStaticSecret, vaultDynamicSecret) is located.
This change is backwards compatible, so if no namespace is specified, the service account will be looked up in the same namespace as the secret.

Example: Here the service account that will be used to authenticate to Vault is the service account `default` that it is in the namespace "vault-secrets-operator-system".
```yaml
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: app
spec:
  vaultConnectionRef: vault-connection
  allowedNamespaces:
    - "*"
  method: kubernetes
  mount: demo-auth-mount
  kubernetes:
    role: role1
    serviceAccount: vault-secrets-operator-system/default
```

Closes hashicorp#336
glerchundi added a commit to saltosystems/vault-secrets-operator that referenced this issue Jan 4, 2024
@glerchundi
internal/credentials: make kubernetes auth service account namespaced
7ba3571 
This commit adds the ability to specify a namespace for the service
account used to authenticate to Vault. This is useful when you want to
use a service account in a different namespace than the one the secret
(vaultStaticSecret, vaultDynamicSecret) is located. This change is
backwards compatible, so if no namespace is specified, the service
account will be looked up in the same namespace as the secret.

Example: Here the service account that will be used to authenticate to
Vault is the service account `default` that it is in the namespace
"vault-secrets-operator-system".

```yaml
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: app
spec:
  vaultConnectionRef: vault-connection
  allowedNamespaces:
    - "*"
  method: kubernetes
  mount: demo-auth-mount
  kubernetes:
    role: role1
    serviceAccount: vault-secrets-operator-system/default
```

Closes hashicorp#336
glerchundi added a commit to saltosystems/vault-secrets-operator that referenced this issue Jan 26, 2024
@glerchundi
internal/credentials: make kubernetes auth service account namespaced
4d60b15 
This commit adds the ability to specify a namespace for the service
account used to authenticate to Vault. This is useful when you want to
use a service account in a different namespace than the one the secret
(vaultStaticSecret, vaultDynamicSecret) is located. This change is
backwards compatible, so if no namespace is specified, the service
account will be looked up in the same namespace as the secret.

Example: Here the service account that will be used to authenticate to
Vault is the service account `default` that it is in the namespace
"vault-secrets-operator-system".

```yaml
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: app
spec:
  vaultConnectionRef: vault-connection
  allowedNamespaces:
    - "*"
  method: kubernetes
  mount: demo-auth-mount
  kubernetes:
    role: role1
    serviceAccount: vault-secrets-operator-system/default
```

Closes hashicorp#336
glerchundi added a commit to saltosystems/vault-secrets-operator that referenced this issue Jan 29, 2024
@glerchundi
internal/credentials: make kubernetes auth service account namespaced
91cf2c5 
This commit adds the ability to specify a namespace for the service
account used to authenticate to Vault. This is useful when you want to
use a service account in a different namespace than the one the secret
(vaultStaticSecret, vaultDynamicSecret) is located. This change is
backwards compatible, so if no namespace is specified, the service
account will be looked up in the same namespace as the secret.

Example: Here the service account that will be used to authenticate to
Vault is the service account `default` that it is in the namespace
"vault-secrets-operator-system".

```yaml
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: app
spec:
  vaultConnectionRef: vault-connection
  allowedNamespaces:
    - "*"
  method: kubernetes
  mount: demo-auth-mount
  kubernetes:
    role: role1
    serviceAccount: vault-secrets-operator-system/default
```

Closes hashicorp#336
@TJM
Copy link

TJM commented Apr 11, 2024

I am seeing this problem as well. Apparently when you fall back to the default VaultAuth in the "operators" namespace, it still attempts to find the service account in the local secrets namespace. I would think that it would use the service account that is in the same namespace as the VaultAuth, or as mentioned here, allow for a namespace prefix so that you can specify which one to use. ServiceAccounts do not have the concept of allowedNamespaces, so that might be tricky to support securely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
2 participants
@TJM @kcighon