A Kubernetes operator that manages Warpgate bastion host resources declaratively through Custom Resource Definitions. Define your Warpgate roles, users, targets, credentials, and access tickets as Kubernetes manifests and let the operator handle the REST API calls, drift reconciliation, and lifecycle management.
- Deploy and manage Warpgate instances directly on Kubernetes with the
WarpgateInstanceCRD - 10 CRDs covering all Warpgate resource types -- instances, connections, roles, users, targets, bindings, credentials, and tickets
- Multi-instance support via
WarpgateConnectionCRDs pointing to different Warpgate instances - Continuous drift reconciliation that enforces desired state every 5 minutes
- Secret references for sensitive fields -- no inline tokens or passwords in CRD specs
- Finalizer-based cleanup that removes Warpgate resources when CRs are deleted
- Auto-generated passwords for users, stored in Kubernetes Secrets
- Auto-created Secrets for ticket values
- Admission webhooks that validate and default CRD specs at create/update time, catching misconfigurations before they reach the controller
helm repo add warpgate-operator https://thereisnotime.github.io/warpgate-operator
helm repo update
helm install warpgate-operator warpgate-operator/warpgate-operator \
--namespace warpgate-operator-system --create-namespacekubectl apply -f https://github.com/thereisnotime/warpgate-operator/releases/latest/download/install.yamlCreate a Secret with your Warpgate API token (recommended), then define a connection, a role, and a user:
apiVersion: v1
kind: Secret
metadata:
name: warpgate-auth
stringData:
token: YOUR_WARPGATE_API_TOKENapiVersion: warpgate.warpgate.warp.tech/v1alpha1
kind: WarpgateConnection
metadata:
name: my-warpgate
spec:
host: https://warpgate.example.com
authSecretRef:
name: warpgate-authNote: Username/password authentication is also supported as a fallback for Warpgate instances that don't have OTP/2FA enabled. See the WarpgateConnection docs for details on both auth modes.
apiVersion: warpgate.warpgate.warp.tech/v1alpha1
kind: WarpgateRole
metadata:
name: developers
spec:
connectionRef: my-warpgate
name: developers
---
apiVersion: warpgate.warpgate.warp.tech/v1alpha1
kind: WarpgateUser
metadata:
name: john-doe
spec:
connectionRef: my-warpgate
username: john.doeSee the CRD reference for full field details and more examples.
All resources belong to the API group warpgate.warpgate.warp.tech/v1alpha1.
| Kind | Description | Docs |
|---|---|---|
WarpgateInstance |
Deploy and manage a Warpgate instance on Kubernetes | docs/crds/warpgate-instance.md |
WarpgateConnection |
Connection to a Warpgate instance | docs/crds/warpgate-connection.md |
WarpgateRole |
Role definition | docs/crds/warpgate-role.md |
WarpgateUser |
User account with credential policy and auto-generated password | docs/crds/warpgate-user.md |
WarpgateTarget |
Target host (SSH, HTTP, MySQL, PostgreSQL) | docs/crds/warpgate-target.md |
WarpgateUserRole |
User-to-role binding | docs/crds/warpgate-user-role.md |
WarpgateTargetRole |
Target-to-role binding | docs/crds/warpgate-target-role.md |
WarpgatePasswordCredential |
Password credential for a user | docs/crds/warpgate-password-credential.md |
WarpgatePublicKeyCredential |
SSH public key credential for a user | docs/crds/warpgate-public-key-credential.md |
WarpgateTicket |
One-time access ticket (auto-creates Secret) | docs/crds/warpgate-ticket.md |
flowchart TD
A[User creates Resource CR\nRole / User / Target / etc.] --> B{CR spec includes\nconnectionRef}
B --> C[Operator looks up\nWarpgateConnection CR]
C --> D[Read host URL +\ncredentials from connection]
D --> E[Fetch credentials from\nKubernetes Secret]
E --> F[Call Warpgate REST API\nCreate / Update / Delete]
F --> G[Write status back to CR]
H[User deletes Resource CR] --> I[Finalizer intercepts deletion]
I --> J[Operator deletes resource\nin Warpgate via REST API]
J --> K[Remove finalizer\nCR is garbage-collected]
erDiagram
WarpgateInstance ||--o| WarpgateConnection : "auto-creates"
WarpgateConnection ||--o{ WarpgateRole : "referenced by"
WarpgateConnection ||--o{ WarpgateUser : "referenced by"
WarpgateConnection ||--o{ WarpgateTarget : "referenced by"
WarpgateConnection ||--o{ WarpgateUserRole : "referenced by"
WarpgateConnection ||--o{ WarpgateTargetRole : "referenced by"
WarpgateConnection ||--o{ WarpgatePasswordCredential : "referenced by"
WarpgateConnection ||--o{ WarpgatePublicKeyCredential : "referenced by"
WarpgateConnection ||--o{ WarpgateTicket : "referenced by"
WarpgateUser ||--o{ WarpgateUserRole : "bound via"
WarpgateRole ||--o{ WarpgateUserRole : "bound via"
WarpgateTarget ||--o{ WarpgateTargetRole : "bound via"
WarpgateRole ||--o{ WarpgateTargetRole : "bound via"
WarpgateUser ||--o{ WarpgatePasswordCredential : "has"
WarpgateUser ||--o{ WarpgatePublicKeyCredential : "has"
WarpgateUser ||--o{ WarpgateTicket : "issued to"
WarpgateTarget ||--o{ WarpgateTicket : "grants access to"
Every resource CR references a WarpgateConnection by name (same namespace) via connectionRef. The operator
resolves the connection, reads the auth credentials from the referenced Kubernetes Secret, and talks to the Warpgate
REST API. Roles are bound to users and targets through dedicated binding CRDs, while credentials and tickets
hang off users directly. A WarpgateInstance can optionally deploy Warpgate itself and auto-create the
WarpgateConnection CR, giving you a fully self-contained setup.
Webhook validation for CRD specs(done)- Kubernetes target type support
- SSO credential management
- Helm chart published to artifact hub
- Prometheus metrics and alerts
- Multi-architecture container images
- Comprehensive E2E test suite
See CONTRIBUTING.md for development setup, coding guidelines, and how to submit changes.
Apache License 2.0. See LICENSE for the full text.