Have you gotten AWS Managed Prometheus connected to a Spinnaker Kayenta deployment? - amazon-web-services

I'd like to use Spinnaker's Kayenta application to provide canary deployment analysis using AWS Managed Prometheus as its source for metrics data.
The open source Spinnaker's Kayenta application looks like it only supports basic and bearer token authentication. It looks like it does not support signing a request using AWS SigV4, which is the authentication mechanism used by AWS Managed Prometheus.
Has anyone else thought through this? Do you have suggestions on how to put these together? One option would be to add the feature to Kayenta, which will take time; another might be to put a signing proxy in place (there's a signing proxy from AWSLabs that could be adapted...
Love to hear your thoughts on what might be doable.

Related

Enable mTLS over Imap in AWS Workmail

I have searched the World wide web and the official AWS documentation for a solution to implement the mTLS over Imap connection in AWS Workmail.
Unfortunately, without any luck, I did not find any information. I have spoken with tech support over at AWS, and they did not give me the relevant information.
It seems like they do not support this feature on Workmail, the only place where they do support it is on AWS API Gateway.
I'm really out of options; I'm not very familiar with the AWS environment and would like to know if someone has done this configuration in the past and how it can be done. It does look like a simple thing that many other email servers do support (such as Microsoft Exchange)

Using amplify to integrate app into existing AWS database

I'm developing an Android app that needs to work with an existing Amazon Web Service RDS database as well as an S3 bucket server also on AWS. My issue is that I'm struggling to find much in the way on guidance on the best approach to do so.
Currently the best thing I've found is Amazon's Amplify, the alternatives so far being SQLiteOpenHelper (seemingly unideal given that it looks to work almost exclusively with local databases, but an interesting caching option) and using Apache, which seems bad as it is extremely manual and largely deprecated.
Am I correct in then concluding Amplify is the best direction to take, or am I missing something big (it feels this way), in which case advice on how better to research this task would be immensely appreciated.
Amplify allows you to connect your app with any kind of datasource using AppSync, which is a GraphQL service managed, via resolvers that connects to anything that you want.
AppSync provides a GraphQL API including features like request and response mapping, authentication, cache and other useful things. Here you can have an overview about how it works https://aws.amazon.com/blogs/mobile/appsync-microservices/.
About how to use S3, Amplify can help with it, using amplify/cli is easy to add that resource, just running amplify add storage, as explained here https://docs.amplify.aws/lib/storage/getting-started/q/platform/android/.

How can I enable the API in AWS Managed Workflows for Apache Airflow?

I'm testing the waters for running Apache Airflow on AWS through the Managed Workflows for Apache Airflow (MWAA). The version of Airflow that AWS have deployed and are managing for me is 1.10.12.
When I try to access the v1 REST API at /api/experimental/test I get back status code 403 Forbidden.
Is it possible to enable the experimental API in MWAA? How?
I think MWAA provide a REST endpoint to use the CLI
https://$WEB_SERVER_HOSTNAME/aws_mwaa/cli
It's quite confusing because you fisrt need to create a cli-token using the awscli to then hit the endpoint using that token. You will need a policy to allow your awscli to request that token.
Lastly there isn't support for all the commands, just a bunch.
Anyway it's all explained on the user guide
https://docs.aws.amazon.com/mwaa/latest/userguide/amazon-mwaa-user-guide.pdf
By default, api.auth_backend configuration option is set to airflow.api.auth.backend.deny_all in MWAA environments. You need to override it to one of the authentication methods mentioned in the documentation as shown in the figure bellow:
Note: it is highly discouraged to use airflow.api.auth.backend.default as it'll
leave your environment publicly accessible.
[2021/07/29] Edit:
Based on this comment, AWS blocked access to the REST API.

AppSync and thoughts on being locked in AWS

I have been thinking about building a backend with graphQL.
The aim is to make the life of the backend team easier and iterate quicker rather then have to build REST endpoints or wss actions for each dataset retreivale.
GraphQL seems to be one of solution. We are very familliar with the Lambda environement and therefore in our research we found AppSync. I looks like a perfect solution, however I have some concerened around being locked in AWS and by designing the whole architecture around AppSync.
The beauty of serverless is that with the Serverless Framework, we could redeploy all functions to another cloud provider (Azure Functions) or even dockerize the functions for a deployment onprem.
I am concerned that with AppSync there is really no alternative in either other cloud providers or to easly do this onprem. Does anybody have any experience with this? Would it be more worth it to do the work to deploy an appolo server in lambda and build the connectors/listeners to the data sources our selfs with something like this: https://github.com/michalkvasnicak/aws-lambda-graphql/tree/aws-lambda-graphql%400.13.0#design-michalkvasnicak ?
IMHO, it comes down to how exactly the client of the GraphQL endpoint will secure data. One strategy is to secure an app with Amazon identity services like IAM and Cognito. Amplify's strength is secure integration with IAM, Cognito, API Gateway, DynamoDB, S3, and AppSync. A secure GraphQL endpoint on AppSync, for example. The data hosted in each AWS cloud service can be secured with Amplify and there are many other strategies too.
The serverless framework is a break through for serverless developer operations. The framework is beautiful. I don't disagree with your concern that Amplify generated cloudformation is not portable. Cloudformation is different DevSecOps culture than the Serverless framework. Amplify's generated DevSecOps code simply lands in Cloudformation culture.
I'm awfully new to GraphQL on the cloud, FWIW. I don't have experience with Apollo on Lambda. I cried, it looked difficult to automate the security though a seasoned pro may know. I certainly hope you get to a point where you never have to throw a single line of code away. I'm not even close, yet.
An easy entry point to the AWS eco system is to use AWS Amplify.
It has documentation guidance on security, GraphQL API, etc.

What parts of the AWS should I use for a web portal?

I am currently working on a web portal for a foundation. Applicants for a grant will receive access data in advance independently of this portal. New applications will then be created and processed in the portal itself. Once an application is complete, it is sent off. Later the application will be approved or rejected.
There are a number of technical specifications on which I have no influence. The frontend should be implemented using Html+Javascript. The backend should use the Amazon Web Services (AWS). If there is a need to program something for the backend - then C# should be used.
I know how to implement the classic client-server solution. At the moment, however, AWS offers me an unmanageable set of services. And here I'm hoping for suggestions as to which of the services I should take a closer look at. Ideally, no complete 'server solution' should run on a virtual server. Instead, Lambda functions are mentioned again and again. So would Amazon RDS and AWS Lambda be a sensible and sufficient combination? Did I miss something?
Thank you very much for your suggestions.
One solution would be to use AWS S3 to server HTML, CSS, JS, Images and other static content. You could use AWS Lambda via AWS API Gateway to serve as a backend. AWS Lambda would then connect to AWS RDS or AWS DynamoDB if you would prefer a NoSQL solution.
Image taken from AWS Github repo
You can get a more detailed description of how to set this up at
https://github.com/aws-samples/aws-serverless-workshops/tree/master/WebApplication/