Recently I've started to use Secrets Manager to read credentials from Lambda, and I noticed that reading a secret from SM takes several seconds. Introducing VPC interface endpoint as described here: https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html#vpc-endpoint didn't help, I see the same response time.
In CloudTrail I see that created VPC endpoint is used to call Secrets Manager.
Did anyone have similar issue?
Related
I have a function app which is hosted in my GCP project with authentication turned on.
This app will be triggered from Jfrog container registry webhook based on events.
The issue I face here is to authenticate/authorize the HTTP request. I tried using "Authorization: bearer " header, which works good. But that token seems to expire after 60 minutes.
Q: Is there a permanent way(with no expiration) to authorize/authenticate cloud function HTTP requests ? Jfrog webhooks cannot programmatically create tokens since it's a simple HTTP POST trigger which can accept additional headers.
I am finding it hard to get a solution from GCP documentation. I do have the service account created with "roles/cloudfunctions.invoker" role.
Reference about Jfrog artifactory webhooks: https://www.jfrog.com/confluence/display/JFROG/Webhooks
It's for that reason I wrote that article. It's based on ESPv2 and Cloud Run, but API Gateway is the managed version of that technical stack. The principle and the OpenAPI spec is the same.
The solution downgrade the security level from a short lived token (1h) to long lived token (no limit). But you can use API Gateway to ensure the API Key check and query forward.
A much more simpler pattern is to remove the authentication check on Cloud Functions (and make it public) and to perform that API key (in fact a random string comparison) in your functions itself.
In both case, the API is publicly accessible (API Gateway, or Cloud Functions) and, in case of DDoS attack, nothing will protect your service (and your money). Set the correct Cloud Functions Max instance to prevent any bad surprise.
My current stack is like this:
User creates an account via AWS Cognito
A post confirmation lambda is triggered which then adds further user details to a database
My database uses the sub id generated by cognito as the userId so they are the same. I also copy the email address as the Username in my database. My intention is to use Cognito for Authentication and my own database for the functionality of my app.
However if the user wishes to update their email address I need to amend this in both cognito and my database. My first attempt made a call to cognito in my lambda using admin_update_user_attributes but soon realised it was blocked from making external calls to the internet, so i created a nat gateway which worked but it simply costs way too much!
My second idea was to go through cognito, having my front end make the call and then have cognito trigger a lambda to update my database but I don't think this is possible.
Is there a configuration or something I'm missing to be able to access AWS cognito via a lambda through the API gateway as they are both AWS services.
I dont want to make two seperate calls via my frontend as this creates a risk of one being completed but not the other.
Thanks
A NAT gateway will be needed if you have your Lambda function in a VPC as there are no Cognito VPC endpoints at this time.
List of currently supported AWS services with endpoints.
If you are using a DB like Dynamo, the Lambda function does not need to be in a VPC so you could achieve the usecase you mentioned above.
Another option could be to do the Cognito update asynchronously, so your Lambda could potentially use VPC endpoints to put an object in SQS and then have a Lambda poller (outside VPC) to poll the messages and update Cognito. Or achieve a similar usecase by making use of private API Gateways.
These are just potential ideas which I have not done myself.
I have an AWS API Gateway endpoint that uses lambda proxy integration to retrieve data from an AWS RDS instance.
I use a yaml file to re-deploy the api, Once the API is re-deployed, The endpoint, illustrated above, throws an "Internal Server Error" every time I re-deploy the api.
The error goes off if I uncheck and then check the lambda proxy integration option/tick-box on the endpoint. This manual step is cumbersome and extremely unintuitive and can raise serious production issues.
Anyone facing similar issue know how to solve it without the additional "unchecking and checking" (manual) step?
What change in YAML can solve this problem ?
Under your AWS::ApiGateway::Method resource, make your Integration.Type as AWS_PROXY
https://docs.aws.amazon.com/apigateway/api-reference/resource/integration/#type
I am working in IVR team. I write SOAP web services, write java client to access those web services and set data in the session variables of the CISCO API and IVR can then able to access that data. I am very good at this.
Currently, my manager plans to move from CISCO IVR to Amazon Connect. Amazon Connect has all infrastructure and IVR can be set up in 45 minutes.
My task is to access existing legacy SOAP web services(which has access to our databases) in AWS Lambda and give that data to IVR.
I went through all the documentation, but not able to figure out where to start. Could some one give me guidance on where to start.
Here's an article about calling SOAP services from a Lambda function, with a walkthrough of the process: https://blog.codecentric.de/en/2016/12/serverless-soap-legacy-api-integration-java-aws-lambda-aws-api-gateway/
It goes further than what you may need, adding API gateway on top of the Lambda function. You may not need that if you're just planning to call those Lambda functions from Connect.
There's also an article in Connect documentation on integrating with Lambda: http://docs.aws.amazon.com/connect/latest/adminguide/connect-lambda-functions.html
I am running a Kubernetes cluster hosted on GKE and would like to write an application (written in Go) that speaks to the Kubernetes API. My understanding is that I can either provide a client certificate, bearer token, or HTTP Basic Authentication in order to authenticate with the apiserver. I have already found the right spot to inject any of these into the Golang client library.
Unfortunately, the examples I ran across tend to reference to existing credentials stored in my personal kubeconfig file. This seems non-advisable from a security perspective and makes me believe that I should create a new client certificate / token / username-password pair in order to support easy revocation/removal of compromised accounts. However, I could not find a spot in the documentation actually describing how to go about this when running on managed Kubernetes in GKE. (There's this guide on creating new certificates explaining that the apiserver needs to get restarted with updated parameters eventually, something that to my understanding cannot be done in GKE.)
Are my security concerns for reusing my personal Kubernetes credentials in one (or potentially multiple) applications unjustified? If not, what's the right approach to generate a new set of credentials?
Thanks.
If your application is running inside the cluster, you can use Kubernetes Service Accounts to authenticate to the API server.
If this is outside of the cluster, things aren't as easy, and I suppose your concerns are justified. Right now, GKE does not allow additional custom identities beyond the one generated for your personal kubeconfig file.
Instead of using your credentials, you could grab a service account's token (inside a pod, read from /var/run/secrets/kubernetes.io/serviceaccount/token), and use that instead. It's a gross hack, and not a great general solution, but it might be slightly preferable to using your own personal credentials.