terraform-community-modules / tf_aws_bastion_s3_keys Goto Github PK

Something like:
-------AZ------------ PUB Subnet ------- A Record ----------------------
"ap-southeast-1a" => "10.0.0.0/24" => bastion.ap-southeast-1a.xyz.com
"ap-southeast-1b" => "10.0.1.0/24" => bastion.ap-southeast-1b.xyz.com

With an ASG spanning the region and min/max=1

Currently this module adds multiple keys to a single user. I don't think it would be too hard to create a user for each key. What do you think? It would be a lot more usable.

I would like to be good net citizen and use a IPv6 for the bastion

is there a way to have this, so that I can associate the IPv6 to the dynamically created bastion instance, in order to then use this IPv6 to create a AAAA record bastion.example.com ?

(I've read that elastic ip is not supported for ipv6)

The ASG should use a 'bastion' placement group

The current code does not work with Debian buster or Ubuntu 18.04 LTS or later. This is because these distributions use python3 as the default python version. The fix suggested at PR #62 solves this issue, but is not backwards compatible. Perhaps someone can suggest something better?

• aws_security_group.bastion: Error creating Security Group: InvalidGroup.Duplicate: The security group 'bastion.mydomain.com' already exists for VPC 'vpc-foo'

I've tried deleting it and reran but that doesn't help. I see it described in my state file as i'd expect after a run but it seems terraform is trying to add it even though it knows it's there...

Any ideas?

Like the title says, this has ben recently implemented in 3.22 : https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group#automatically-refresh-all-instances-after-the-group-is-updated

Currently the bastion security group will have at least 2 inbound rules: one ipv4 and one ipv6. There is no way to, for example, exclude the ipv6 inbound rule. In the case where there is no ipv6 address for the source defined for the ipv4 inbound rule, one can only workaround this by, for example, providing a ipv6 private address range (fc00::/7).
It seems to me this is a use case that should be addressed by either controlling creation of ipv6 inbound rule with an additional parameter, or changing the default behaviour of the allowed_ipv6_cidr parameter. The latter does not feel right, as it will not be consistent any more with allowed_ipv4_cidr parameter.

Hello,

After configuring the bastion host, I am unable to ssh to it.

Here is the config:

module "bastion" {
source = "github.com/terraform-community-modules/tf_aws_bastion_s3_keys"
ssh_user = "admin"
instance_type = "t2.micro"
ami = "${var.ami}"
region = "${var.aws_region}"
iam_instance_profile = "${module.iam.iam-instance-profile}"
s3_bucket_name = "${var.s3_bucket_name}"
#s3_bucket_uri = "${module.s3.bucket_domain_name}"
vpc_id = "${module.app_server.vpc_id}"
subnet_ids = ["${module.app_server.bastion_subnet1}", "${module.app_server.bastion_subnet2}"]
keys_update_frequency = "5,20,35,50 * * * *"
additional_user_data_script = "date"
}

I see that the bastion host gets created.

I also see the ssh keys..

aws s3 sync --delete $BUCKET_URI $PUB_KEYS_DIR
download: s3://my-s3-bastion-bucket-dev/admin.pub to ../../../../../../tmp/vv/admin.pub
download: s3://my-s3-bastion-bucket-dev/id_rsa.pub to ../../../../../../tmp/vv/id_rsa.pub

and ssh debug...

debug2: key: public_keys/admin (0x7fbf23d15010), explicit
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: public_keys/admin
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

The user script that runs has these,

#!/usr/bin/env bash

set -e

BUCKET_NAME=my-s3-bastion-bucket-dev
BUCKET_URI=
SSH_USER=admin
MARKER="# KEYS_BELOW_WILL_BE_UPDATED_BY_TERRAFORM"
KEYS_FILE=/home/$SSH_USER/.ssh/authorized_keys
TEMP_KEYS_FILE=$(mktemp /tmp/authorized_keys.XXXXXX)
PUB_KEYS_DIR=/home/$SSH_USER/pub_key_files/
PATH=/usr/local/bin:$PATH

Not sure what is going wrong. Appreciate any input.

• Shekar

According to the documentation:

After you run terraform apply you should be able to login to your bastion host like:

$ ssh ${module.bastion.ssh_user}@${module.bastion.instance_ip}

However module.bastion.instance_ip is not actually exported by the module. Furthermore it does not look like autoscaling groups have a way to list the ips of the machines involved.
hashicorp/terraform-provider-aws#511

Thus at the minimum the documentation should be updated.

The bucket exists but no ssh key exists in it (wasnt looking to use that part of the module).

from the logs:

/home/ubuntu/update_ssh_authorized_keys.sh: line 26: /home/ubuntu/pub_key_files//*: No such file or directory

ami: "us-west-1" = "ami-2d5c6d4d"
(official hvm:ebs-ssd 6.04 image)

I created a new bucket on s3 and add my public keys on this bucket.
But I'm getting a "Permission denied (publickey)".

My Module configuration

module "bastion" {
  source                = "github.com/terraform-community-modules/tf_aws_bastion_s3_keys"
  name                  = "foodlogiqBastion"
  instance_type         = "${var.instance_type}"
  ami                   = "${module.bastion_ami.ami_id}"
  region                = "${var.region}"
  iam_instance_profile  = "${aws_iam_instance_profile.s3_readonly.name}"
  s3_bucket_name        = "public-keys-bastion"
  vpc_id                = "${module.vpc.vpc_id}"
  subnet_ids            = ["${module.vpc.public_subnets}"]
  keys_update_frequency = "30 * * * *"
}

resource "aws_iam_instance_profile" "s3_readonly" {
  name  = "s3-readonly"
  roles = ["${aws_iam_role.s3_readonly.name}"]
}

resource "aws_iam_role" "s3_readonly" {
  name               = "s3-readonly-role"
  path               = "/"
  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF
}

resource "aws_iam_role_policy" "s3_readonly_policy" {
  name   = "s3-readonly-policy"
  role   = "${aws_iam_role.s3_readonly.id}"
  policy = <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1425916919000",
            "Effect": "Allow",
            "Action": [
                "s3:List*",
                "s3:Get*"
            ],
            "Resource": "*"
        }
    ]
}
EOF
}

I'm curious as to why this module moved away from just making an AWS Instance and instead using an autoscaling group. I'd like to create a bastion that I can use as a jump box during the provisioning of certain private instances in private subnets as well as to SSH into those boxes after provisioning. I should be able to do that with just an aws_instance no? Is this meant for some other usage? Why create an autoscaling group with only one instance?

Ubuntu 16.04 running on EC2.

aws binary lives in /usr/local/bin

$ which aws
/usr/local/bin/aws

script is running every 15 mins, but it is not syncing

$ crontab -l
5,20,35,50 * * * * /home/ubuntu/update_ssh_authorized_keys.sh

Logs reveal that aws command not found

$ cat /var/mail/ubuntu
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/home/ubuntu>
X-Cron-Env: <PATH=/usr/bin:/bin>  <<--- My path does not include /usr/local/bin
X-Cron-Env: <LOGNAME=ubuntu>
...
/home/ubuntu/update_ssh_authorized_keys.sh: line 23: aws: command not found
...

Probably this is an issue solved by properly setting up cron and PATH environment variable, however I have not been able to get this to work as advertised. My understanding is that since 12.04 cron should read in any variables set in /etc/environment. Not happening in my case.

$ cat /etc/environment 
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

Due to the commit: a42b62a

We are now getting:

./update_ssh_authorized_keys.sh: line 33: selinuxenabled: command not found

When applying changes to a new bastion host

Hello!

I tried using this module with Terraform 0.12 and I got errors due to the syntax change:

Error: Unsupported block type

  on .terraform/modules/bastion/main.tf line 6, in resource "aws_security_group" "bastion":
   6:   tags {

Blocks of type "tags" are not expected here. Did you mean to define argument
"tags"? If so, use the equals sign to assign it a value.


Error: Unsupported block type

  on .terraform/modules/bastion/main.tf line 51, in data "template_file" "user_data":
  51:   vars {

Blocks of type "vars" are not expected here. Did you mean to define argument
"vars"? If so, use the equals sign to assign it a value.

Apparently it's just a matter of adding the = sign ? (sorry, terraform noob here)