0
votes

My build pipeline presently creates an AMI via packer+chef in a VPC (lets call it vpc-alpha) and grants permissions to that AMI to other Accounts/VPCs in my AWS topology (lets call this vpc-beta).

The build includes:

  • a firewall cookbook with explicit rules configured to allow tcp port 22 ACCEPT
  • Security group open for inbound traffic from internal network for the application's port and SSH (tcp 22)
  • both VPCs have routing tables setup for 0.0.0.0/0 for internet gateway
  • There are no differences between the IAM roles being used when my CI builds AMIs into either VPC
  • There are no differences between how subnets/SGs/AZs are managed in my Cloudformating templating between VPCs

Configurations I have attempted:

  1. When the AMI is built into vpc-alpha, EC2s created from this AMI in vpc-alpha are SSH-able. (PASS)
  2. Similarly, when the AMI is built into vpc-beta directly, EC2s created from this AMI into vpc-beta are SSH-able. (PASS)
  3. However, when vpc-beta goes to (successfully) create an EC2 from the AMI built into vpc-alpha, although the EC2 spins up, I am not able to SSH into the machine. (FAIL)

Are there perhaps IAM based limitations or references to vpc-alpha's networking configurations baked into the AMI that I am not seeing that might prohibit vpc-beta from running vpc-alpha's AMI successfully?

I am working with my (2) configuration as a workaround, but my curiosity on this is getting the better of me.

1
Are you using SSH keypairs or passwords? What is the SSH error? What does the EC2 logfiles indicate?John Hanley
I build LDAP into the AMI via chef, though (1) and (2) succeed with this same LDAP cookbook. I have spawned oneoff EC2s off the image using my current machine's pem which only appears to fail on (3). SSH Error is cryptically ssh: connect to host RE.DA.CT.ED port 22: Operation timed out EC2 logfiles mostly only indicate this, which doesn't make much sense given successful LDAP when an AMI is built into vpc-beta: nslcd[768]: [b0dc51] <group/member="root"> failed to bind to LDAP server ldap://RE.DA.CT.ED/: Can't contact LDAP server: Transport endpoint is not connected kian
I am digging further into my dependency cookbooks as I'm now more feeling it must lie somewhere in that realm rather than the VPC networking configuration which appears appropriate.kian

1 Answers

1
votes

This was caused by a block in one of my underlying dependency cookbooks not being run by packer+chef when there exists 2 VPC references.

Not running the block undesirably maintained the VPC nameservers in my /etc/resolv.conf, rather than injecting an expected internal network nameserver config required to SSH using LDAP from inside my internal network.

TLDR: User issue with a cookbook, not an actual AWS issue.