mirror of
https://github.com/wahyd4/passkey-auth.git
synced 2026-08-09 04:15:55 +10:00
Clean up readmes
This commit is contained in:
-129
@@ -1,129 +0,0 @@
|
||||
# Contributing to Passkey Auth
|
||||
|
||||
Thank you for your interest in contributing to Passkey Auth! This document provides guidelines for contributing to the project.
|
||||
|
||||
## 🚀 Getting Started
|
||||
|
||||
1. Fork the repository
|
||||
2. Clone your fork: `git clone https://github.com/yourusername/passkey-auth.git`
|
||||
3. Create a feature branch: `git checkout -b feature/your-feature-name`
|
||||
4. Make your changes
|
||||
5. Test your changes
|
||||
6. Commit and push to your fork
|
||||
7. Create a Pull Request
|
||||
|
||||
## 🛠️ Development Setup
|
||||
|
||||
### Prerequisites
|
||||
- Go 1.21 or later
|
||||
- Docker (for containerized testing)
|
||||
- Make (optional, for build scripts)
|
||||
|
||||
### Local Development
|
||||
```bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/yourusername/passkey-auth.git
|
||||
cd passkey-auth
|
||||
|
||||
# Install dependencies
|
||||
go mod download
|
||||
|
||||
# Run the application
|
||||
go run .
|
||||
|
||||
# Run tests
|
||||
go test ./...
|
||||
```
|
||||
|
||||
### Docker Development
|
||||
```bash
|
||||
# Build Docker image
|
||||
./scripts/build.sh
|
||||
|
||||
# Run with Docker
|
||||
docker run -p 8080:8080 passkey-auth
|
||||
```
|
||||
|
||||
## 📋 Guidelines
|
||||
|
||||
### Code Style
|
||||
- Follow standard Go formatting (`gofmt`)
|
||||
- Use meaningful variable and function names
|
||||
- Add comments for exported functions and complex logic
|
||||
- Keep functions focused and small
|
||||
|
||||
### Commit Messages
|
||||
- Use clear, descriptive commit messages
|
||||
- Start with a verb in present tense ("Add", "Fix", "Update")
|
||||
- Include context for why the change was made
|
||||
|
||||
Example:
|
||||
```
|
||||
Add email allowlist support for user registration
|
||||
|
||||
- Allows administrators to restrict registration to specific email domains
|
||||
- Configurable via config.yaml or environment variables
|
||||
- Backwards compatible (empty list allows all emails)
|
||||
```
|
||||
|
||||
### Testing
|
||||
- Write tests for new features
|
||||
- Ensure existing tests pass
|
||||
- Test both success and error cases
|
||||
- Include integration tests for new endpoints
|
||||
|
||||
### Documentation
|
||||
- Update README.md for new features
|
||||
- Add inline code comments
|
||||
- Update API documentation if endpoints change
|
||||
- Include examples in documentation
|
||||
|
||||
## 🐛 Bug Reports
|
||||
|
||||
When reporting bugs, please include:
|
||||
- Go version
|
||||
- Operating system
|
||||
- Steps to reproduce
|
||||
- Expected vs actual behavior
|
||||
- Relevant logs or error messages
|
||||
|
||||
## 💡 Feature Requests
|
||||
|
||||
When requesting features:
|
||||
- Describe the use case
|
||||
- Explain why it would be valuable
|
||||
- Consider backwards compatibility
|
||||
- Provide examples if possible
|
||||
|
||||
## 🔐 Security
|
||||
|
||||
For security vulnerabilities:
|
||||
- Do not open public issues
|
||||
- Contact maintainers directly
|
||||
- Provide detailed reproduction steps
|
||||
- Allow time for fixes before disclosure
|
||||
|
||||
## 📜 Code of Conduct
|
||||
|
||||
- Be respectful and inclusive
|
||||
- Welcome newcomers and help them learn
|
||||
- Focus on constructive feedback
|
||||
- Respect different viewpoints and experiences
|
||||
|
||||
## 🏷️ Release Process
|
||||
|
||||
1. Update version in relevant files
|
||||
2. Update CHANGELOG.md
|
||||
3. Create release PR
|
||||
4. Tag release after merge
|
||||
5. Build and publish Docker images
|
||||
6. Create GitHub release with notes
|
||||
|
||||
## 📞 Getting Help
|
||||
|
||||
- Check existing issues and documentation first
|
||||
- Open an issue for bugs or feature requests
|
||||
- Join discussions in existing issues
|
||||
- Ask questions in issues (we're happy to help!)
|
||||
|
||||
Thank you for contributing! 🎉
|
||||
@@ -1,313 +0,0 @@
|
||||
# Hosting Passkey Auth Helm Chart on GitHub
|
||||
|
||||
This guide explains how to host your Helm chart on GitHub Pages and make it available via a public Helm repository.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- GitHub repository with your Helm chart
|
||||
- GitHub Actions enabled
|
||||
- GitHub Pages enabled
|
||||
|
||||
## Setup Steps
|
||||
|
||||
### 1. Repository Structure
|
||||
|
||||
Ensure your repository has this structure:
|
||||
```
|
||||
passkey-auth/
|
||||
├── .github/
|
||||
│ ├── workflows/
|
||||
│ │ └── helm-release.yml
|
||||
│ └── cr.yaml
|
||||
├── helm/
|
||||
│ └── passkey-auth/
|
||||
│ ├── Chart.yaml
|
||||
│ ├── values.yaml
|
||||
│ ├── README.md
|
||||
│ ├── templates/
|
||||
│ └── examples/
|
||||
└── README.md
|
||||
```
|
||||
|
||||
### 2. Enable GitHub Pages
|
||||
|
||||
1. Go to your GitHub repository
|
||||
2. Navigate to **Settings** > **Pages**
|
||||
3. Under **Source**, select **GitHub Actions**
|
||||
4. Save the configuration
|
||||
|
||||
### 3. Configure Repository Settings
|
||||
|
||||
1. **Enable GitHub Actions**:
|
||||
- Go to **Settings** > **Actions** > **General**
|
||||
- Enable "Allow all actions and reusable workflows"
|
||||
|
||||
2. **Set up GitHub Pages permissions**:
|
||||
- Go to **Settings** > **Actions** > **General**
|
||||
- Under "Workflow permissions", select "Read and write permissions"
|
||||
- Check "Allow GitHub Actions to create and approve pull requests"
|
||||
|
||||
### 4. Update Chart Configuration
|
||||
|
||||
Edit `.github/cr.yaml` to match your repository:
|
||||
|
||||
```yaml
|
||||
owner: YOUR_GITHUB_USERNAME # Change this
|
||||
git-repo: passkey-auth # Change if different
|
||||
charts-repo: https://YOUR_GITHUB_USERNAME.github.io/passkey-auth
|
||||
target-branch: gh-pages
|
||||
package-path: .cr-release-packages
|
||||
index-path: .cr-index
|
||||
skip-existing: true
|
||||
```
|
||||
|
||||
### 5. Create Your First Release
|
||||
|
||||
1. **Tag your first release**:
|
||||
```bash
|
||||
git tag v0.1.0
|
||||
git push origin v0.1.0
|
||||
```
|
||||
|
||||
2. **Or push changes to trigger workflow**:
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Add Helm chart"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
The GitHub Action will automatically:
|
||||
- Lint and test your chart
|
||||
- Package the chart
|
||||
- Create a GitHub release
|
||||
- Update the Helm repository index
|
||||
- Deploy to GitHub Pages
|
||||
|
||||
### 6. Verify the Setup
|
||||
|
||||
1. **Check GitHub Actions**:
|
||||
- Go to **Actions** tab in your repository
|
||||
- Verify the "Release Helm Chart" workflow completes successfully
|
||||
|
||||
2. **Check GitHub Pages**:
|
||||
- Go to **Settings** > **Pages**
|
||||
- You should see "Your site is published at https://username.github.io/passkey-auth"
|
||||
|
||||
3. **Test the Helm repository**:
|
||||
```bash
|
||||
helm repo add passkey-auth https://YOUR_USERNAME.github.io/passkey-auth
|
||||
helm repo update
|
||||
helm search repo passkey-auth
|
||||
```
|
||||
|
||||
## Using Your Hosted Chart
|
||||
|
||||
### Add the Repository
|
||||
|
||||
```bash
|
||||
helm repo add passkey-auth https://YOUR_USERNAME.github.io/passkey-auth
|
||||
helm repo update
|
||||
```
|
||||
|
||||
### Install the Chart
|
||||
|
||||
```bash
|
||||
# Basic installation
|
||||
helm install my-passkey-auth passkey-auth/passkey-auth
|
||||
|
||||
# With custom values
|
||||
helm install my-passkey-auth passkey-auth/passkey-auth \
|
||||
--set config.webauthn.rpId=auth.example.com \
|
||||
--set secrets.sessionSecret="your-secure-secret"
|
||||
|
||||
# With values file
|
||||
helm install my-passkey-auth passkey-auth/passkey-auth \
|
||||
-f values-production.yaml
|
||||
```
|
||||
|
||||
### Search Available Versions
|
||||
|
||||
```bash
|
||||
helm search repo passkey-auth --versions
|
||||
```
|
||||
|
||||
## Maintenance and Updates
|
||||
|
||||
### Releasing New Versions
|
||||
|
||||
1. **Update Chart.yaml**:
|
||||
```yaml
|
||||
version: 0.2.0 # Increment version
|
||||
appVersion: "v1.1.0" # Update app version if needed
|
||||
```
|
||||
|
||||
2. **Commit and push**:
|
||||
```bash
|
||||
git add helm/passkey-auth/Chart.yaml
|
||||
git commit -m "Bump chart version to 0.2.0"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
3. **The workflow will automatically**:
|
||||
- Package the new version
|
||||
- Create a GitHub release
|
||||
- Update the Helm repository
|
||||
|
||||
### Testing Charts Locally
|
||||
|
||||
```bash
|
||||
# Lint the chart
|
||||
helm lint helm/passkey-auth/
|
||||
|
||||
# Template the chart (dry run)
|
||||
helm template my-passkey-auth helm/passkey-auth/ \
|
||||
--set config.webauthn.rpId=test.local
|
||||
|
||||
# Install locally for testing
|
||||
helm install test-release helm/passkey-auth/ \
|
||||
--dry-run --debug
|
||||
```
|
||||
|
||||
## Advanced Configuration
|
||||
|
||||
### Custom Domain for Helm Repository
|
||||
|
||||
If you want to use a custom domain instead of `username.github.io`:
|
||||
|
||||
1. **Set up custom domain in GitHub Pages**:
|
||||
- Go to **Settings** > **Pages**
|
||||
- Add your custom domain (e.g., `charts.example.com`)
|
||||
|
||||
2. **Update `.github/cr.yaml`**:
|
||||
```yaml
|
||||
charts-repo: https://charts.example.com
|
||||
```
|
||||
|
||||
3. **Configure DNS**:
|
||||
- Add CNAME record pointing to `username.github.io`
|
||||
|
||||
### Multiple Charts in One Repository
|
||||
|
||||
If you have multiple charts:
|
||||
|
||||
```
|
||||
helm/
|
||||
├── passkey-auth/
|
||||
│ ├── Chart.yaml
|
||||
│ └── ...
|
||||
├── another-chart/
|
||||
│ ├── Chart.yaml
|
||||
│ └── ...
|
||||
```
|
||||
|
||||
The workflow will automatically detect and release all charts.
|
||||
|
||||
### Private Repositories
|
||||
|
||||
For private repositories, users will need:
|
||||
|
||||
1. **GitHub Personal Access Token**:
|
||||
```bash
|
||||
helm repo add passkey-auth https://username:TOKEN@username.github.io/passkey-auth
|
||||
```
|
||||
|
||||
2. **Or configure helm with auth**:
|
||||
```bash
|
||||
helm repo add passkey-auth https://username.github.io/passkey-auth \
|
||||
--username YOUR_USERNAME \
|
||||
--password YOUR_TOKEN
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
1. **GitHub Actions Fails**:
|
||||
- Check workflow permissions in repository settings
|
||||
- Verify GitHub Pages is enabled
|
||||
- Check if there are syntax errors in the chart
|
||||
|
||||
2. **Chart Not Found**:
|
||||
- Verify the repository URL is correct
|
||||
- Check if GitHub Pages deployment completed
|
||||
- Ensure chart name matches directory name
|
||||
|
||||
3. **Permission Denied**:
|
||||
- Verify GitHub Actions has write permissions
|
||||
- Check if GitHub Pages is enabled for the repository
|
||||
|
||||
### Debug Commands
|
||||
|
||||
```bash
|
||||
# Check repository status
|
||||
helm repo list
|
||||
|
||||
# Update repositories
|
||||
helm repo update
|
||||
|
||||
# Debug template rendering
|
||||
helm template my-release helm/passkey-auth/ --debug
|
||||
|
||||
# Validate chart
|
||||
helm lint helm/passkey-auth/
|
||||
|
||||
# Check chart dependencies
|
||||
helm dependency list helm/passkey-auth/
|
||||
```
|
||||
|
||||
## Security Considerations
|
||||
|
||||
### Repository Security
|
||||
|
||||
1. **Secrets Management**:
|
||||
- Never commit sensitive values to the repository
|
||||
- Use GitHub Secrets for sensitive configuration
|
||||
- Document security requirements in README
|
||||
|
||||
2. **Chart Signing** (Optional):
|
||||
```bash
|
||||
# Generate GPG key for chart signing
|
||||
gpg --gen-key
|
||||
|
||||
# Export public key
|
||||
gpg --armor --export your-email@example.com > public.key
|
||||
|
||||
# Add to chart-releaser config
|
||||
echo "sign: true" >> .github/cr.yaml
|
||||
```
|
||||
|
||||
3. **Dependency Security**:
|
||||
- Regularly update chart dependencies
|
||||
- Use dependency vulnerability scanning
|
||||
- Pin specific versions in production
|
||||
|
||||
### Best Practices
|
||||
|
||||
1. **Version Management**:
|
||||
- Follow semantic versioning
|
||||
- Update `appVersion` when application changes
|
||||
- Update `version` when chart changes
|
||||
|
||||
2. **Documentation**:
|
||||
- Keep README.md updated
|
||||
- Document breaking changes
|
||||
- Provide migration guides
|
||||
|
||||
3. **Testing**:
|
||||
- Test charts before releasing
|
||||
- Use CI/CD for automated testing
|
||||
- Validate on different Kubernetes versions
|
||||
|
||||
## Example Repository
|
||||
|
||||
You can see a complete example at: `https://github.com/YOUR_USERNAME/passkey-auth`
|
||||
|
||||
The hosted Helm repository will be available at: `https://YOUR_USERNAME.github.io/passkey-auth`
|
||||
|
||||
## Support
|
||||
|
||||
If you encounter issues:
|
||||
1. Check the GitHub Actions logs
|
||||
2. Verify chart syntax with `helm lint`
|
||||
3. Review GitHub Pages deployment status
|
||||
4. Open an issue in the repository for help
|
||||
@@ -1,122 +0,0 @@
|
||||
# 📋 Implementation Summary
|
||||
|
||||
## What We've Built
|
||||
|
||||
✅ **Complete Passkey Authentication System** with email-based access control
|
||||
✅ **SQLite Database** for persistent user storage
|
||||
✅ **Email Allowlist System** for controlling who can register
|
||||
✅ **Kubernetes Integration** with nginx ingress auth backend
|
||||
✅ **Modern Web UI** for user registration and management
|
||||
✅ **Production-Ready Deployment** with Docker and Kubernetes manifests
|
||||
|
||||
## Key Features Implemented
|
||||
|
||||
### 🔐 Email-Based Authentication
|
||||
- Users are identified by email addresses (not usernames)
|
||||
- Configurable email allowlist for access control
|
||||
- Environment variable support for email configuration
|
||||
|
||||
### 📧 Email Access Control Options
|
||||
|
||||
1. **Open Mode**: Empty allowlist allows any email
|
||||
2. **Restricted Mode**: Only allowlisted emails can register
|
||||
3. **Combined Security**: Allowlist + manual approval
|
||||
|
||||
### 🗄️ Database Architecture (SQLite)
|
||||
```sql
|
||||
-- Users table
|
||||
CREATE TABLE users (
|
||||
id INTEGER PRIMARY KEY,
|
||||
email TEXT UNIQUE NOT NULL, -- Email as primary identifier
|
||||
display_name TEXT NOT NULL,
|
||||
approved BOOLEAN DEFAULT FALSE,
|
||||
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
|
||||
-- Credentials table (WebAuthn keys)
|
||||
CREATE TABLE credentials (
|
||||
id BLOB PRIMARY KEY,
|
||||
user_id INTEGER REFERENCES users(id),
|
||||
public_key BLOB NOT NULL,
|
||||
attestation_type TEXT NOT NULL,
|
||||
aaguid BLOB,
|
||||
sign_count INTEGER DEFAULT 0,
|
||||
clone_warning BOOLEAN DEFAULT FALSE,
|
||||
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
```
|
||||
|
||||
### ⚙️ Configuration Options
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
session_secret: "your-secret-key"
|
||||
require_approval: true # Admin approval required
|
||||
allowed_emails: # Email allowlist
|
||||
- "admin@company.com"
|
||||
- "engineering@company.com"
|
||||
```
|
||||
|
||||
Or via environment variables:
|
||||
```bash
|
||||
export ALLOWED_EMAILS="admin@company.com,user1@company.com,user2@company.com"
|
||||
export SESSION_SECRET="your-secure-session-secret"
|
||||
```
|
||||
|
||||
## Files Created/Modified
|
||||
|
||||
### Core Application
|
||||
- `main.go` - Application entry point
|
||||
- `internal/config/` - Configuration management with email allowlist
|
||||
- `internal/database/` - SQLite database layer with email-based users
|
||||
- `internal/auth/` - WebAuthn implementation
|
||||
- `internal/handlers/` - HTTP handlers with email validation
|
||||
|
||||
### Web Interface
|
||||
- `web/index.html` - Admin UI updated for email addresses
|
||||
|
||||
### Deployment
|
||||
- `Dockerfile` - Container build
|
||||
- `k8s/` - Kubernetes manifests
|
||||
- `docker-compose.yml` - Local development
|
||||
- `scripts/` - Build and deployment scripts
|
||||
|
||||
### Documentation
|
||||
- `README.md` - Complete usage guide
|
||||
- `PRODUCTION.md` - Production deployment guide
|
||||
- `config.example.yaml` - Example configuration
|
||||
|
||||
## How It Works
|
||||
|
||||
1. **Email Validation**: When a user tries to register, the system checks if their email is in the allowlist (if configured)
|
||||
2. **Database Storage**: User data is stored in SQLite with email as the unique identifier
|
||||
3. **WebAuthn Integration**: Passkey credentials are linked to the user record
|
||||
4. **Session Management**: Authentication sessions use email-based identification
|
||||
5. **Nginx Integration**: Auth headers include user email for downstream applications
|
||||
|
||||
## Quick Start
|
||||
|
||||
```bash
|
||||
# 1. Configure email allowlist
|
||||
vim config.yaml # Add your allowed emails
|
||||
|
||||
# 2. Start the service
|
||||
./scripts/dev.sh
|
||||
|
||||
# 3. Register users at http://localhost:8080
|
||||
# Only emails in the allowlist can register
|
||||
|
||||
# 4. Deploy to Kubernetes
|
||||
./scripts/build.sh
|
||||
./scripts/deploy.sh
|
||||
```
|
||||
|
||||
## Security Benefits
|
||||
|
||||
- **No passwords stored** - Only WebAuthn public keys
|
||||
- **Email-based access control** - Restrict registration to specific domains/emails
|
||||
- **Phishing resistant** - WebAuthn is tied to the domain
|
||||
- **MFA built-in** - Passkeys require user presence and verification
|
||||
- **Session security** - Secure cookie-based sessions
|
||||
|
||||
This implementation provides a complete, production-ready passkey authentication system with fine-grained email-based access control, perfect for enterprise environments where you need to restrict access to specific users.
|
||||
-287
@@ -1,287 +0,0 @@
|
||||
# Production Deployment Guide
|
||||
|
||||
This guide covers deploying Passkey Auth in a production Kubernetes environment.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Kubernetes cluster with nginx ingress controller
|
||||
- Domain name with SSL certificate
|
||||
- kubectl access to the cluster
|
||||
- Docker registry access (optional, for custom builds)
|
||||
|
||||
## Step 1: Prepare Configuration
|
||||
|
||||
1. **Generate Session Secret**:
|
||||
```bash
|
||||
openssl rand -base64 32
|
||||
```
|
||||
|
||||
2. **Update Kubernetes Configuration**:
|
||||
|
||||
Edit `k8s/deployment.yaml` and update the ConfigMap:
|
||||
|
||||
```yaml
|
||||
data:
|
||||
config.yaml: |
|
||||
server:
|
||||
port: "8080"
|
||||
host: "0.0.0.0"
|
||||
|
||||
webauthn:
|
||||
rp_display_name: "Your Company Auth"
|
||||
rp_id: "auth.yourcompany.com" # Your auth domain
|
||||
rp_origins:
|
||||
- "https://auth.yourcompany.com" # Your auth URL
|
||||
- "https://app.yourcompany.com" # Your app URLs
|
||||
|
||||
database:
|
||||
path: "/data/passkey-auth.db"
|
||||
|
||||
cors:
|
||||
allowed_origins:
|
||||
- "https://auth.yourcompany.com"
|
||||
- "https://app.yourcompany.com"
|
||||
|
||||
auth:
|
||||
session_secret: "YOUR_GENERATED_SECRET_HERE"
|
||||
require_approval: true
|
||||
```
|
||||
|
||||
## Step 2: Deploy to Kubernetes
|
||||
|
||||
1. **Create Namespace**:
|
||||
```bash
|
||||
kubectl apply -f k8s/namespace.yaml
|
||||
```
|
||||
|
||||
2. **Deploy Application**:
|
||||
```bash
|
||||
kubectl apply -f k8s/deployment.yaml
|
||||
```
|
||||
|
||||
3. **Verify Deployment**:
|
||||
```bash
|
||||
kubectl get pods -n passkey-auth
|
||||
kubectl logs -f deployment/passkey-auth -n passkey-auth
|
||||
```
|
||||
|
||||
## Step 3: Configure SSL/TLS
|
||||
|
||||
Create an ingress with SSL termination:
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: passkey-auth-ingress
|
||||
namespace: passkey-auth
|
||||
annotations:
|
||||
cert-manager.io/cluster-issuer: "letsencrypt-prod" # If using cert-manager
|
||||
nginx.ingress.kubernetes.io/ssl-redirect: "true"
|
||||
spec:
|
||||
tls:
|
||||
- hosts:
|
||||
- auth.yourcompany.com
|
||||
secretName: passkey-auth-tls
|
||||
rules:
|
||||
- host: auth.yourcompany.com
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: passkey-auth-service
|
||||
port:
|
||||
number: 80
|
||||
```
|
||||
|
||||
## Step 4: Configure Your Application Ingress
|
||||
|
||||
Update your application's ingress to use passkey auth:
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: your-app-ingress
|
||||
annotations:
|
||||
# Auth configuration
|
||||
nginx.ingress.kubernetes.io/auth-url: "http://passkey-auth-service.passkey-auth.svc.cluster.local/auth"
|
||||
nginx.ingress.kubernetes.io/auth-signin: "https://auth.yourcompany.com"
|
||||
nginx.ingress.kubernetes.io/auth-response-headers: "X-Auth-User,X-Auth-User-ID"
|
||||
|
||||
# SSL configuration
|
||||
cert-manager.io/cluster-issuer: "letsencrypt-prod"
|
||||
nginx.ingress.kubernetes.io/ssl-redirect: "true"
|
||||
spec:
|
||||
tls:
|
||||
- hosts:
|
||||
- app.yourcompany.com
|
||||
secretName: your-app-tls
|
||||
rules:
|
||||
- host: app.yourcompany.com
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: your-app-service
|
||||
port:
|
||||
number: 80
|
||||
```
|
||||
|
||||
## Step 5: Set Up Monitoring (Optional)
|
||||
|
||||
### Health Checks
|
||||
|
||||
The service includes health checks at `/health`. Configure monitoring:
|
||||
|
||||
```yaml
|
||||
# Add to your monitoring stack
|
||||
- job_name: 'passkey-auth'
|
||||
static_configs:
|
||||
- targets: ['passkey-auth-service.passkey-auth.svc.cluster.local:80']
|
||||
metrics_path: '/health'
|
||||
```
|
||||
|
||||
### Log Aggregation
|
||||
|
||||
Configure log forwarding to your logging system:
|
||||
|
||||
```bash
|
||||
kubectl logs -f deployment/passkey-auth -n passkey-auth | your-log-forwarder
|
||||
```
|
||||
|
||||
## Step 6: Backup Strategy
|
||||
|
||||
### Database Backup
|
||||
|
||||
Set up regular backups of the SQLite database:
|
||||
|
||||
```bash
|
||||
# Create a backup cronjob
|
||||
apiVersion: batch/v1
|
||||
kind: CronJob
|
||||
metadata:
|
||||
name: passkey-auth-backup
|
||||
namespace: passkey-auth
|
||||
spec:
|
||||
schedule: "0 2 * * *" # Daily at 2 AM
|
||||
jobTemplate:
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: backup
|
||||
image: alpine
|
||||
command:
|
||||
- /bin/sh
|
||||
- -c
|
||||
- |
|
||||
cp /data/passkey-auth.db /backup/passkey-auth-$(date +%Y%m%d).db
|
||||
# Upload to your backup storage
|
||||
volumeMounts:
|
||||
- name: data
|
||||
mountPath: /data
|
||||
- name: backup
|
||||
mountPath: /backup
|
||||
restartPolicy: OnFailure
|
||||
volumes:
|
||||
- name: data
|
||||
persistentVolumeClaim:
|
||||
claimName: passkey-auth-storage
|
||||
- name: backup
|
||||
# Configure your backup storage volume
|
||||
```
|
||||
|
||||
## Security Checklist
|
||||
|
||||
- [ ] HTTPS enforced for all endpoints
|
||||
- [ ] Session secret is randomly generated and secure
|
||||
- [ ] CORS origins are specifically configured (not "*")
|
||||
- [ ] WebAuthn RP ID matches your domain exactly
|
||||
- [ ] Network policies restrict pod-to-pod communication
|
||||
- [ ] Regular security updates applied
|
||||
- [ ] Database backups are encrypted and tested
|
||||
- [ ] Access logs are monitored
|
||||
- [ ] Kubernetes RBAC is properly configured
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Production Issues
|
||||
|
||||
1. **WebAuthn Registration Fails**:
|
||||
- Verify RP ID matches domain exactly
|
||||
- Ensure HTTPS is properly configured
|
||||
- Check browser developer console for errors
|
||||
|
||||
2. **Auth Backend Returns 502**:
|
||||
- Verify service is running: `kubectl get pods -n passkey-auth`
|
||||
- Check service connectivity: `kubectl get svc -n passkey-auth`
|
||||
- Review nginx ingress logs
|
||||
|
||||
3. **Session Issues**:
|
||||
- Verify session secret is consistent across restarts
|
||||
- Check cookie domain settings
|
||||
- Ensure persistent storage is working
|
||||
|
||||
### Debug Commands
|
||||
|
||||
```bash
|
||||
# Check service status
|
||||
kubectl get all -n passkey-auth
|
||||
|
||||
# View logs
|
||||
kubectl logs -f deployment/passkey-auth -n passkey-auth
|
||||
|
||||
# Test auth endpoint
|
||||
kubectl exec -it deployment/passkey-auth -n passkey-auth -- wget -O- http://localhost:8080/health
|
||||
|
||||
# Check ingress
|
||||
kubectl describe ingress -n passkey-auth
|
||||
|
||||
# Port forward for testing
|
||||
kubectl port-forward svc/passkey-auth-service 8080:80 -n passkey-auth
|
||||
```
|
||||
|
||||
## Scaling Considerations
|
||||
|
||||
### High Availability
|
||||
|
||||
For high availability, consider:
|
||||
|
||||
1. **Multiple Replicas**: Increase replica count in deployment
|
||||
2. **Session Storage**: Use Redis for shared session storage
|
||||
3. **Database**: Consider PostgreSQL for better concurrent access
|
||||
4. **Load Balancing**: Ensure proper session affinity
|
||||
|
||||
### Performance Tuning
|
||||
|
||||
1. **Resource Limits**: Adjust based on usage patterns
|
||||
2. **Database Optimization**: Regular VACUUM for SQLite
|
||||
3. **Caching**: Add caching layer for frequently accessed data
|
||||
|
||||
## Updates and Maintenance
|
||||
|
||||
### Rolling Updates
|
||||
|
||||
```bash
|
||||
# Update the image
|
||||
kubectl set image deployment/passkey-auth passkey-auth=passkey-auth:v1.1.0 -n passkey-auth
|
||||
|
||||
# Monitor rollout
|
||||
kubectl rollout status deployment/passkey-auth -n passkey-auth
|
||||
|
||||
# Rollback if needed
|
||||
kubectl rollout undo deployment/passkey-auth -n passkey-auth
|
||||
```
|
||||
|
||||
### Database Migrations
|
||||
|
||||
For schema changes, implement migration scripts and run them during maintenance windows.
|
||||
|
||||
---
|
||||
|
||||
This production guide ensures a secure, reliable deployment of Passkey Auth in your Kubernetes environment.
|
||||
@@ -27,18 +27,8 @@ A WebAuthn-based passkey authentication provider that integrates ingress control
|
||||
helm repo add passkey-auth https://wahyd4.github.io/passkey-auth
|
||||
helm repo update
|
||||
|
||||
# Install with your configuration
|
||||
helm install my-passkey-auth passkey-auth/passkey-auth \
|
||||
--set config.webauthn.rpId=auth.example.com \
|
||||
--set config.webauthn.rpOrigins="{https://auth.example.com}" \
|
||||
--set config.cors.allowedOrigins="{https://*.example.com}" \
|
||||
--set config.auth.cookieDomain=".example.com" \
|
||||
--set config.auth.allowedEmails="{admin@example.com}" \
|
||||
--set ingress.hosts[0].host=auth.example.com \
|
||||
--set secrets.sessionSecret="your-secure-random-secret-key"
|
||||
|
||||
# Or use a values file
|
||||
helm install my-passkey-auth passkey-auth/passkey-auth -f values-production.yaml
|
||||
# Install with your values
|
||||
helm upgrade --install my-passkey-auth -n home-apps -f my-values.yaml passkey-auth/passkey-auth
|
||||
```
|
||||
|
||||
See the [Helm Chart README](helm/passkey-auth/README.md) for detailed configuration options.
|
||||
|
||||
@@ -11,10 +11,7 @@ This chart deploys a secure, passwordless authentication service using WebAuthn/
|
||||
```bash
|
||||
helm repo add passkey-auth https://wahyd4.github.io/passkey-auth
|
||||
helm repo update
|
||||
helm install my-passkey-auth passkey-auth/passkey-auth \
|
||||
--set config.webauthn.rpId=auth.example.com \
|
||||
--set config.webauthn.rpOrigins="{https://auth.example.com}" \
|
||||
--set secrets.sessionSecret="your-very-long-random-secret-key-here"
|
||||
helm upgrade --install my-passkey-auth -n home-apps -f my-values.yaml passkey-auth/passkey-auth
|
||||
```
|
||||
|
||||
## Prerequisites
|
||||
@@ -140,76 +137,6 @@ secrets:
|
||||
existingSecret: "external-passkey-secrets" # Reference external secret
|
||||
```
|
||||
|
||||
### Image Pull Secrets
|
||||
|
||||
The chart uses the public GitHub Container Registry by default, but you may need to configure image pull secrets for:
|
||||
|
||||
- **Private container registries**
|
||||
- **GitHub Container Registry with authentication** (for private repositories or rate limiting)
|
||||
- **Other private registry providers**
|
||||
|
||||
#### Creating Image Pull Secrets
|
||||
|
||||
**For GitHub Container Registry:**
|
||||
|
||||
```bash
|
||||
# Create a GitHub Personal Access Token with 'read:packages' permission
|
||||
# Then create the secret:
|
||||
kubectl create secret docker-registry github-registry-secret \
|
||||
--docker-server=ghcr.io \
|
||||
--docker-username=your-github-username \
|
||||
--docker-password=your-github-token \
|
||||
--docker-email=your-email@example.com
|
||||
```
|
||||
|
||||
**For Docker Hub:**
|
||||
|
||||
```bash
|
||||
kubectl create secret docker-registry dockerhub-secret \
|
||||
--docker-server=docker.io \
|
||||
--docker-username=your-dockerhub-username \
|
||||
--docker-password=your-dockerhub-password \
|
||||
--docker-email=your-email@example.com
|
||||
```
|
||||
|
||||
**For private registry:**
|
||||
|
||||
```bash
|
||||
kubectl create secret docker-registry private-registry-secret \
|
||||
--docker-server=your-registry.example.com \
|
||||
--docker-username=your-username \
|
||||
--docker-password=your-password \
|
||||
--docker-email=your-email@example.com
|
||||
```
|
||||
|
||||
#### Configuring Image Pull Secrets in values.yaml
|
||||
|
||||
**Single image pull secret:**
|
||||
|
||||
```yaml
|
||||
imagePullSecrets:
|
||||
- name: github-registry-secret
|
||||
```
|
||||
|
||||
**Multiple image pull secrets:**
|
||||
|
||||
```yaml
|
||||
imagePullSecrets:
|
||||
- name: github-registry-secret
|
||||
- name: private-registry-secret
|
||||
```
|
||||
|
||||
**Complete example for private GitHub repository:**
|
||||
|
||||
```yaml
|
||||
image:
|
||||
repository: ghcr.io/your-org/passkey-auth
|
||||
tag: "v1.0.0"
|
||||
pullPolicy: IfNotPresent
|
||||
|
||||
imagePullSecrets:
|
||||
- name: github-registry-secret
|
||||
```
|
||||
|
||||
## Parameters
|
||||
|
||||
|
||||
Reference in New Issue
Block a user