#aws (2022-10)

yes, output is not there, at this moment thinking about just using the cli to perform the task

every subordinate is another 400/mo

Thanks, needed a sanity check on that

the least expensive w/ security is a root ca to sign a subordinate cert and then ram share the single subordinate cert.

that would be 800/mo without getting additional granularity.

i found this out the hard way…

you can also see this using infracost

Yes looks like that’s the route, just one subordinate per region with a ram share

Oh you mean have the root CA in PCA as well, but you still need a subordinate in each region right?

yep you still need a subordinate per region

min best practices is to have 1 root and 1 shared sub per region

if you get more creative, it will cost you

I suppose using one root CA for all regions, in your primary region, raises DR problems? and having the root outside of PCA is its own security challenge

PCA is

If you have something else managing the root outside AWS PCA, I suppose you wouldn’t need to worry about that part

Companies love extorting for security features (see SSO as well)

I don’t yet have a root so it’s still hypothetical where we’d put it

I’ve also heard of hashicorp vault being used fairly often as CA solution. Not sure it ends up any cheaper

letsencrypt.com

you probably could cobble something together, but AWS GuardDuty is the AWS recommended way to solve that

Guardduty does not look at historical data. I want to look at the historical data.

reasons cloud trail sucks for 1000 alex…

best way to track the logins is via your directory providor and logs there in, be AD, or other cloud directory service

and a good log parser… splunk/elk/grey log/etc…

you can use cloudwatch logs insights for this using a query like the one below against the cloudtrail log group:

fields @timestamp, @message
| filter eventName = "ConsoleLogin"
| filter errorMessage = "Failed authentication"
| sort @timestamp desc
| limit 20

I ran into this ages ago. I think it is because the state thinks your resource exists. You can get around it by renaming it to something else.

i already destroyed de entire infrastructure and when i run the pipeline it still trying to create 2 pipelines, i renamed it twice

im going to refactor the variables later, as you can see im not calling the module with for-each or count

looking at the graph, is trying to create something about bitbucket… (i just want to use github v2 )

well, the solution then: if you wanna use github v2 you just need to put codestar_connection_arn normally but suppressing github oauth token, if you put both the module tries to create 2 pipelines

S3?

S3 latency is too high

Can you talk more to the requirements? e.g. How often does the file change? What’s the need for speed?

If you have your heart set on efs, fwiw we usually set efs as the default storage after creating new eks clusters

https://docs.aws.amazon.com/eks/latest/userguide/efs-csi.html

but i do not want to take away from Sono’s question. Understanding the problem is more important here

there’s also https://aws.amazon.com/about-aws/whats-new/2022/09/amazon-file-cache-generally-available/

#office-hours

That works. Or a ram share, and route53 resolver rules can be pretty flexible. Depends what you need

@RB

The way we’ve done it is the way you’ve described in your above 2 bullets. We’ve done it using a couple terraform components.

We haven’t explored doing the RAM share and r53 resolver rules but that should work too.

thanks

Nothing really, definitely nothing specific to RDS. What problems are you having?

I want to optimize the PostGres performance, so looking for inputs on what are the parameters that people usually start tuning the values of, eg: wal_buffers, work_mem, maintenance_work_mem and so on

Our workload is write and read intensive. We have a replica setup but at times there is a huge replica_lag

hi, have you seen these two? https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server + https://github.com/jfcoz/postgresqltuner

Thanks @Zoltan K, this looks promising!

Yes EC2 instance availability

and their status page shows nothing… where can we get correct status reports ?

This particular notification was sent to the root account email. Not sure if it was on the AWS Status Page or not.

thanks

I did not find any email in my account, but will check it .

You need to mention which service you are asking for help about. I guess this is RDS?

You can configure MySQL settings with a parameter group.

Not letting as in, is any particular error shown?

Thank you all, I solve it. I configure the wrong parameter group this is way when I increased the value I still had this error

Do you know how the cluster was provisioned?

you can try checking for an oidc provider

Determine whether an IAM OIDC provider with your cluster’s ID is already in your account.

aws iam list-open-id-connect-providers | grep $oidc_id

If output is returned from the previous command, then you already have a provider for your cluster and you can skip the next step. If no output is returned, then you must create an IAM OIDC provider for your cluster.

eksctl utils associate-iam-oidc-provider --cluster my-cluster --approve

Thanks @Alanis Swanepoel - I’ll be able to obtain this information tomorrow morning.

When you say must - must to achieve/allow what?

the oidc provider provisions a role in you can use to access the cluster

@Alanis Swanepoel I can see there is no OIDC provider configured

Am I right in thinking that I only need to use an OIDC provider for IRSA (IAM Roles for Service Accounts)? (having looked at AWS docs)

The only immediate requirement is allowing a couple IAM roles to be mapped to a cluster role in aws-auth, so I’m thinking OIDC isn’t immediately required

A “must” always alarms me somewhat when I don’t (yet) see it needed (more from the perspective of worrying that I am missing something)

let me clarify the Must

in order to associate an OIDC priver with your cluster, one MUST exist

you cant associate a non existant provider with the cluster

those steps are to check if an oidc provider has been (1) provisioned in your aws account, and (2) mapped to your cluster

https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html

I wasn’t specifically looking to associate an OIDC provider, though - that’s what you suggested

My current understanding is that I’ll need an OIDC provider once I need to start using IRSA, but for the purposes of allowing another role access to the cluster in the aws-auth configmap, I’ll be fine without

Assuming that’s correct, and that the cluster creator’s IAM user can be safely deleted after adding a different role to the aws-auth configmap, I think I’m good. Thanks!

gotcha - i may have misunderstood your question then - i interpreted it as i have an eks cluster, and i want to give others in my org access to it through an iam role, without messing with config map

If memory serves, EBS doesnt supprt ReadWriteMany, you need to use EFS to get that working

Correct you need an EFS volume

Update: I was using the wrong syntax.

You need to do something like this:

terraform
data "aws_iam_policy_document" "overrides" {
  statement {
    sid    = "S3GetObjectForCloudFront"

    effect = "Allow"
    principals {
      type        = "AWS"
      identifiers = [
        "$${cloudfront_origin_access_identity_iam_arn}"
      ]
    }
    actions   = ["s3:GetObject"]
    resources = ["arn:aws:s3:::$${bucket_name}$${origin_path}*"]
  }

  statement {
    sid    = "S3ListBucketForCloudFront"

    effect = "Allow"
    principals {
      type        = "AWS"
      identifiers = [
        "$${cloudfront_origin_access_identity_iam_arn}"
      ]
    }
    actions   = ["s3:ListBucket"]
    resources = ["arn:aws:s3:::$${bucket_name}"]
  }
}

module "cdn" {
  source  = "cloudposse/cloudfront-s3-cdn/aws"
  version = "0.83.0"
  name    = "Policy Overrides Example"

  origin_bucket                      = "foobar"
  origin_path                        = "/bazqux"
  override_origin_bucket_policy      = true
  additional_bucket_policy           = data.aws_iam_policy_document.overrides.json
}

Resources

• Data Source: aws_iam_policy_document

heh. it probably is evaluating only the identity policy. but sts assume-role is actually performing the action, and that also requires that the trust-policy on the role allow the action… and if you are passing the source-identity, then you need to allow sts:SetSourceIdentity in the role trust policy

Right on the money. Well done @loren!

I feel like the UI should shout this clearer (or at all)!

yeah, the interaction between an identity policy and a resource policy (and SCP and KMS policy and VPC Endpoint policy) can get pretty confounding to troubleshoot