-
Notifications
You must be signed in to change notification settings - Fork 1
Security Model
Erik Meinders edited this page Sep 9, 2025
·
1 revision
cloudX-proxy implements a unique dual-layer security architecture that combines AWS's robust authentication mechanisms with SSH's connection handling capabilities.
┌─────────────┐ ┌──────────────┐ ┌─────────────────┐ ┌─────────────┐
│ VSCode │ │ cloudX-proxy │ │ AWS Systems │ │ EC2 Instance│
│ Client │◄──►│ Proxy │◄──►│ Manager │◄──►│ (Target) │
└─────────────┘ └──────────────┘ └─────────────────┘ └─────────────┘
│ │ │ │
SSH Layer Orchestration Primary Security SSH Daemon
(Secondary) Layer Boundary (Primary) (Endpoint)
The primary security boundary is enforced through AWS Systems Manager (SSM) and EC2 Instance Connect, providing enterprise-grade security controls.
Authentication:
- Only authenticated AWS users with valid credentials can establish connections
- Multi-factor authentication supported through AWS IAM
- Integration with AWS SSO, SAML, and corporate identity providers
- Session-based temporary credentials supported
Authorization:
- Fine-grained IAM permissions control access to specific instances
- ABAC (Attribute-Based Access Control) using EC2 instance tags
- Resource-level permissions prevent lateral movement
- CloudTrail integration for complete audit trails
Required IAM Permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:DescribeInstanceInformation"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:document/AWS-StartSSHSession"
],
"Condition": {
"StringEquals": {
"ssm:resourceTag/cloudxuser": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:StartInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2-instance-connect:SendSSHPublicKey"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/cloudxuser": "${aws:username}"
}
}
}
]
}EC2 Instance Connect:
- SSH public keys are injected temporarily (60-second window)
- No permanent key storage on instances
- Each connection gets fresh key authorization
- Keys automatically expire after session establishment
Process Flow:
- cloudX-proxy reads local SSH public key
- Calls EC2 Instance Connect API to push key to instance
- Key is authorized for specified user (default:
ec2-user) - Key authorization expires after 60 seconds
- SSH connection must complete within this window
No Inbound Ports Required:
- Instances don't need SSH ports (22) exposed to internet
- No security group inbound rules needed for SSH
- All connections established through AWS SSM tunneling
- Perfect for private subnet instances
Encrypted Transit:
- All traffic encrypted with TLS 1.2+ between client and AWS
- AWS Systems Manager handles end-to-end encryption
- No man-in-the-middle vulnerabilities on network path
- Certificate validation against AWS certificate authorities
Connection Path Security:
Client → AWS API (HTTPS/TLS) → SSM Service → VPC Endpoint → Instance
CloudTrail Integration:
- All connection attempts logged with full context
- SSH key pushes tracked with user identity and timestamp
- Session start/stop events with duration tracking
- Failed access attempts logged for security monitoring
Compliance Benefits:
- SOC 2 Type II compliance through AWS SSM
- GDPR compliance for data access controls
- HIPAA compliance for healthcare workloads
- FedRAMP compliance for government workloads
SSH serves as the connection handler and provides additional security features, but is not the primary security mechanism.
Temporary Key Usage:
- SSH keys used only for session establishment through SSM tunnel
- Keys don't provide direct network access to instances
- Same key can be safely used across multiple instances
- Key compromise doesn't grant direct instance access
Key Management:
- Local SSH key pairs managed by cloudX-proxy or 1Password
- Private keys never transmitted over network
- Public key distribution handled by EC2 Instance Connect
- Automatic key rotation possible without instance reconfiguration
Connection Handling:
- SSH handles terminal sessions, file transfers, and port forwarding
- Connection multiplexing for efficiency (ControlMaster)
- Keep-alive mechanisms prevent connection drops
- Graceful session termination
Security Features:
- Host key verification (though less critical in this architecture)
- User authentication through key pairs
- Session encryption between SSH client and server
- Compression and performance optimization
The architecture implements zero trust principles:
- Every connection requires fresh AWS authentication
- Instance access verified through IAM permissions each time
- SSH keys validated dynamically per session
- No persistent authentication credentials on instances
- Users only access instances with matching tags (
cloudxuser) - Minimal IAM permissions required for functionality
- Time-limited SSH key authorization windows
- Session-based access without permanent credentials
- SSH key compromise doesn't grant direct network access
- AWS credential compromise limited by IAM policies
- Instance compromise doesn't affect other instances
- Complete audit trail enables incident response
Network-Level Attacks:
- ✅ Direct SSH brute force attacks (no exposed SSH ports)
- ✅ Man-in-the-middle attacks (TLS encryption to AWS)
- ✅ Network sniffing (encrypted AWS API communication)
- ✅ Lateral movement (instance-specific IAM controls)
Credential-Based Attacks:
- ✅ SSH key theft (keys don't provide direct access)
- ✅ AWS credential abuse (limited by IAM policies)
- ✅ Session hijacking (temporary key authorization)
- ✅ Privilege escalation (ABAC tag-based access control)
Operational Security:
- ✅ Accidental exposure (no permanent SSH access)
- ✅ Configuration drift (consistent IAM-based access)
- ✅ Audit compliance (complete CloudTrail logging)
- ✅ Key management complexity (automated key distribution)
Residual Risks:
- AWS root account compromise (affects entire AWS environment)
- Instance-level compromise after successful connection
- Client-side malware on developer machines
- Social engineering targeting AWS credentials
Mitigation Strategies:
- Enable AWS root account MFA and monitoring
- Implement instance-level security hardening
- Use endpoint protection on developer machines
- Implement AWS credential security best practices
Client ──[Internet/VPN]──► Instance:22 (exposed port)
Risks:
- SSH port exposed to network attacks
- Permanent SSH keys stored on instances
- Network path vulnerabilities
- Complex firewall rule management
Client ──[AWS API/TLS]──► SSM ──[VPC Internal]──► Instance (no exposed ports)
Benefits:
- No exposed SSH ports
- Dynamic key authorization
- AWS-managed encryption
- Centralized access control
- Use dedicated IAM users for cloudX-proxy (not shared accounts)
- Implement IAM policies with condition-based access control
- Enable CloudTrail in all regions for complete audit coverage
- Regularly rotate AWS access keys
- Use 1Password or similar secure storage for SSH keys
- Regularly rotate SSH key pairs
- Use unique SSH keys per environment (dev/staging/prod)
- Monitor SSH key usage through CloudTrail events
- Deploy instances in private subnets when possible
- Use VPC endpoints for SSM communication
- Implement least-privilege security groups
- Monitor VPC Flow Logs for unusual traffic patterns
- Set up CloudWatch alarms for unusual SSM session activity
- Monitor CloudTrail for failed EC2 Instance Connect attempts
- Implement alerting for off-hours access patterns
- Regular access reviews through CloudTrail analysis
For implementation details, see AWS Permissions and 1Password Integration.