User Management
Nauthera stores user accounts in PostgreSQL. The operator exposes an admin API for user lifecycle management, protected by Kubernetes RBAC. In v1, users are provisioned by administrators — self-service registration is planned for a future release.
Admin API
The admin API is served on the operator's internal service port (default: 8443) and is accessible only from within the cluster. All endpoints require a valid Kubernetes ServiceAccount token with the appropriate RBAC permissions.
Create a User
kubectl exec -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user create \
--email alice@example.com \
--name "Alice Smith" \
--groups engineering,platform \
--set-passwordThe --set-password flag prompts for a password interactively. Alternatively, use --password-stdin for scripted provisioning:
echo "SecureP@ssw0rd!" | kubectl exec -i -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user create \
--email alice@example.com \
--name "Alice Smith" \
--password-stdinOr use the HTTP admin API directly:
# Port-forward the admin API
kubectl port-forward -n nauthera-system svc/nauthera-operator-admin 8443:8443 &
# Create a user
curl -X POST https://localhost:8443/admin/v1/users \
-H "Authorization: Bearer $(kubectl create token nauthera-admin -n nauthera-system)" \
-H "Content-Type: application/json" \
-d '{
"email": "alice@example.com",
"name": "Alice Smith",
"password": "SecureP@ssw0rd!",
"groups": ["engineering", "platform"],
"attributes": {
"department": "Platform Engineering"
}
}'List Users
kubectl exec -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user list# Via HTTP
curl https://localhost:8443/admin/v1/users \
-H "Authorization: Bearer $(kubectl create token nauthera-admin -n nauthera-system)"Get a User
kubectl exec -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user get --email alice@example.comUpdate a User
kubectl exec -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user update \
--email alice@example.com \
--groups engineering,platform,security \
--set-attribute department="Security Engineering"Delete a User
kubectl exec -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user delete --email alice@example.comReset a User's Password
echo "NewSecureP@ss!" | kubectl exec -i -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user reset-password \
--email alice@example.com \
--password-stdinPassword Policy
Password requirements are configured via Helm values:
# values.yaml
operator:
passwordPolicy:
minLength: 12
requireUppercase: true
requireLowercase: true
requireDigit: true
requireSpecial: true
maxAge: 90d # Force password change after 90 daysAll passwords are hashed with bcrypt (configurable cost factor, default: 12).
Account Security
Brute-Force Protection
The operator automatically locks accounts after repeated failed login attempts:
| Setting | Default | Helm Value |
|---|---|---|
| Max failed attempts | 5 | operator.security.maxFailedAttempts |
| Lockout window | 15 minutes | operator.security.lockoutWindow |
| Lockout duration | 30 minutes | operator.security.lockoutDuration |
Locked accounts unlock automatically after the coolout period. Administrators can unlock an account immediately:
kubectl exec -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user unlock --email alice@example.comAccount Status
Each user has a status field that controls whether they can authenticate:
| Status | Description |
|---|---|
active | Normal operation — user can log in |
locked | Temporarily locked due to failed attempts — auto-unlocks |
disabled | Administratively disabled — must be re-enabled by an admin |
# Disable a user
kubectl exec -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user disable --email alice@example.com
# Re-enable a user
kubectl exec -n nauthera-system deploy/nauthera-operator -- \
nauthera-admin user enable --email alice@example.comPassword Reset
In v1, password resets are performed by an administrator using the admin API (see Reset a User's Password above). There is no self-service "forgot password" flow in the current release.
Planned: Self-service password reset via email-based token flow is planned for a future release. This will require SMTP configuration in the Helm values.
For organisations that need self-service password reset before this feature ships, consider fronting Nauthera with an external workflow (e.g., a small internal app that validates the user's identity and calls the admin API to reset the password).
User Attributes
Users have a set of standard fields and an extensible attributes map for custom data:
| Field | Type | Description |
|---|---|---|
id | UUID | Auto-generated unique identifier |
email | string | Unique email address (used as login identifier) |
name | string | Display name |
groups | []string | Group memberships |
attributes | map[string]string | Custom key-value attributes |
status | string | active, locked, or disabled |
createdAt | timestamp | Account creation time |
updatedAt | timestamp | Last modification time |
Custom attributes can be mapped to JWT claims via claimMappings in an AuthPolicy:
spec:
claimMappings:
- claim: department
fromUserAttribute: department
- claim: "https://myapp.example.com/roles"
fromUserAttribute: appRolesRBAC for Admin API
Access to the admin API is controlled by Kubernetes RBAC. The Helm chart creates a nauthera-admin ClusterRole with the necessary permissions. Bind it to the ServiceAccounts or users that should manage user accounts:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: platform-team-nauthera-admin
subjects:
- kind: Group
name: platform-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: nauthera-admin
apiGroup: rbac.authorization.k8s.ioRelated Resources
- Login Experience — How the login page and consent screen work.
- AuthPolicy — Claim mappings and token policies.
- Architecture — Security features and high availability.