#terraform-aws-modules (2019-11)

i gues i found the issue , below policy requires one more trustee application-autoscaling.amazonaws.com

data "aws_iam_policy_document" "assume_role_ec2" {
  count = var.enabled ? 1 : 0

  statement {
    effect = "Allow"

    principals {
      type        = "Service"
      identifiers = ["elasticmapreduce.amazonaws.com","application-autoscaling.amazonaws.com"]
    }

    actions = ["sts:AssumeRole"]
  }
}

good for a PR ?

thanks @navdeep, we’ll review it

This is not a github.com/terraform-aws-module (which this channel is for)

Sorry, I misread

Better to just use #terraform which is a catch all for everything else

sure

Ya, it’s confusing. :-)

I can ssh to bastion already

RDS security group allows incoming 5432 port (postgres)

but psql connection from bastion on that port times out

RDS security group allows incoming 5432 port (postgres)

via network CIDR ACLs or security group id of the bastion?

and the route table for the vpc has routes for both public and private subnets?

No, I didn’t explicitly create a routing table for vpc

Did I understand you correctly, that by adding routes to the VPC routing table for public and private subnets I’ll make it possible to connect from EC2 instance in public subnet to the RDS in private?

yep, you got it

RDS security group allows incoming 5432 port (postgres) via RDS security group (I didn’t explicitly add ACLs and as far as I can see - they allow everything)

Thank you Erik, I’ll look into the routing table for the VPC

hrmm…

actually, I might have misspoke. it’s been a while since I looked at this module.

looks like it creates both public/private subnets at the same time.

yes

ok, so looksl ike we create a public route table, and a private route table

and we don’t permit routing out of the box between them

Aha

I guess there’s not much profit by keeping them seperate if we at routes to both

yeah, what I actually want is for private nets not to be accessed from the internet but only from pubnets

maybe even from specific EC2 ip

I think what we did was use an ELB/TCP in public

(bastion)

and then deploy bastion in private

ELB was pointed at bastion

I c

Thanks, than my plan is to move bastion from pub to priv net, add elb and point it to the bastion

I’ve just found something else:

Session Manager is a managed service that provides you with one-click secure access to your instances without the need to open inbound ports and manage bastion hosts. You have centralized access control over who can access your instances and full auditing capabilities to ensure compliance with corporate policies.

today i learned: https://semver.org/#spec-item-4

do you guys plan on releasing any 1.0.0 modules? or is that too much effort to maintain for you guys?

With even terraform itself being pre-1.0 there is some debate as to if it is even possible ;)

But it’s largely because they way all this fits together it’s really hard to solve the calculus of when to release 1.0. It’s a judgement call at best. I think it should be somewhat automatic. If we don’t need to change the interface for a module in 12 months, then cut 1.0 or something

Open to discussion

i think a variable will also be needed to allow the user to pass in any ingress and egress rules they need

This resource treats its inline rules as absolute; only the rules defined inline are created, and any additions/removals external to this resource will result in diff shown. For these reasons, this resource is incompatible with the aws_security_group_rule resource.

you mean to the default SG?

correct

maybe better to expose the default SG ID as output

so the user could do whatever they want with it

i don’t think that’ll work based on the docs… where it’s saying the inline rule is treated as the source of truth and aws_default_security_group is incompatible with aws_security_group_rule

at least that’s how i interpret what they’re trying to say

so yes, I agree. What was done in https://github.com/cloudposse/terraform-aws-vpc/blob/master/main.tf#L22 is not usable w/o inline rules since you can’t use external rules with default SG

and default SG is created in a VPC

so for that to be usable, we need to provide variables to specify ingress and egress inline rules

we did not catch that (visually and in CI/CD tests) b/c we actually don’t use the default SG in VPCs (always create SGs specific to resources)

that makes sense… ideally we wouldn’t be either but unfortunately we are

On the other hand, that was created specifically for CIS probably to completely restrict the default SG

So adding the inline rules back prob defeats the purpose

enabled flag might be better

oh yeah i agree with that

So TF will not touch the default SG at all if not needed for CIS

with the enabled flag the user can manage the default SG outside of the module and do as they wish

@Saichovsky see https://sweetops.slack.com/archives/CB6GHNLG0/p1573144102121000?thread_ts=1573113838.112200&cid=CB6GHNLG0

no we did not have one

but easy to implement using the rds-cluster module

should be exactly the same except a few new resources https://www.terraform.io/docs/providers/aws/r/redshift_cluster.html

We recently implemented EMR