4.2.5. Secure Administrative Access
First Principle: Administrative access to compute resources is the highest-risk access pattern — a compromised admin session gives an attacker everything. Eliminating SSH keys and bastion hosts in favor of auditable, just-in-time access dramatically reduces this attack surface.
Systems Manager Session Manager:
- Browser-based or CLI shell access to EC2 instances without inbound SSH ports
- All sessions logged to CloudTrail and optionally to S3/CloudWatch for complete audit trail
- IAM-based access control: who can start sessions, on which instances
- No SSH keys, no bastion hosts, no open security group ports
- Works through the SSM Agent (already installed on most Amazon Linux/Windows AMIs)
EC2 Instance Connect:
- Push a temporary SSH public key to the instance metadata for a single connection
- Key expires after 60 seconds — no persistent SSH keys
- Requires the Instance Connect agent (pre-installed on recent AMIs)
- IAM controls who can push keys to which instances
Comparison:
| Feature | Session Manager | EC2 Instance Connect |
|---|---|---|
| Protocol | Custom (SSM channel) | SSH |
| Ports required | None (outbound HTTPS only) | Port 22 (inbound) |
| Audit logging | CloudTrail + S3/CloudWatch | CloudTrail only |
| Key management | No keys | Temporary keys (60s) |
| VPC connectivity | VPC endpoint or internet | Direct or VPC endpoint |
⚠️ Exam Trap: Session Manager requires NO inbound security group rules. If a question asks about secure admin access without opening SSH ports, Session Manager is the answer.
Scenario: An auditor asks how admin access is controlled for EC2 instances. You demonstrate: no SSH keys in use, no port 22 open, all sessions via Session Manager with IAM policies limiting access to specific instance tags, and all session activity logged to an immutable S3 bucket.
Reflection Question: Why does eliminating SSH keys and bastion hosts improve security even if the bastion was well-hardened?
