I'm trying to enable instance termination protection using terraform. But did not see any arguments for openstack like what I found for AWS 'disable_api_termination'.
I think you need a different mechanism to manage that. Terraform doesn't have option to disable termination like it is implemented for AWS. Those options are tailored after the provider APIs. I'm guessing that OpenStack just doesn't have something similar to this behavior.
To prevent some confusion I want to mention that the Terraform's lifecycle documented here won't be of much good in this regard:
https://www.terraform.io/docs/configuration/resources.html#prevent_destroy
It will disallow you to destroy it using 'terraform destroy' and the likes but won't do much in terms of protection coming from the OpenStack provider itself.
I would rather think about solving this problem in the architectural layer. Think about how you call the OpenStack API and how you manage your services. Around those steps you can probably place an additional layer or step that will manage the lifecycle and keep mistakes down to the minimum. Your process is what could protect you better than any tool.
Related
I'm trying to figure out if there is any way to programmatically check if provided credentials have read and write access to different Kafka topics using the Confluent Kafka lib for .NET.
What I want to do is basically a smoke test upon system startup,
to verify that the given credentials are correct.
e.g. when deploying to various environments with different settings.
Setting up an entire consumer or producer and then actually reading or writing data seems hacky and expensive.
I thought that maybe there could be something in e.g. the AdminClient that allows verifying this, but I don't see anything that hints in that direction.
yes there is AdminClient implementation, please check out the following github repository example for .NET
https://github.com/confluentinc/confluent-kafka-dotnet/blob/master/examples/AdminClient/Program.cs
I was surfing on internet for solutions and tools related to the API Layer and I find a company (maybe a startup) that is developing an ecosystem that allow to "virtualize the API Layer" (at the moment only in .net Core). It seems they allow to don't code the Api layer, don't write documentation of endpoints, don't writeE2E test (automatically inferred), change behaviour of endpoints at runtime and reuse the entire stack in another project. Do you think is it really possible something like this and useful in the world of API development? thanks
If I understand the question, your wondering about setting up an API layer with just the endpoints, but the endpoints have empty logic in them, right?
If so, then yes its possible to do this with a variety of tools. One tool I use is Postman, which allows you to setup a "skeleton" API you can call for design/testing purposes.
It allows standing up a mock server that hosts your skeleton API, in which any consumer can hook into.
Implement ABAC Access Control for the Openstack in C# to apply it in real enviroment.
/etc/keystone.conf and XACML policy write ...
Yes, ABAC can be applied in an OpenStack cloud environment. Unfortunately, since we don't have much information about what you are trying to achieve, I can only speak in generalities.
C# is a supported programming language for SDKs for XACML implementations, such as the company I work for, Axiomatics.
OpenStack can be used with certain API gateways that would allow fine grain access control/ ABAC. While I don't have much OpenStack experience, I suggest reading about Trio2o and IBM® OpenStack based on my searches. Any API Gateway with sufficient features will do the track though.
In other words, what part of Google Cloud Endpoints is not in the SDK?
I've seen several people saying that simply running their application elsewhere doesn't work. For exaple, see: https://groups.google.com/forum/#!searchin/appscale_community/endpoints/appscale_community/BFagV00RUcU/taaAoV5mxNEJ
What part of Google Cloud Endpoints is not in the SDK? Are there any initiatives going to try to implement that?
Endpoints has two components. The first is the SDK, and the second is the API proxy. In theory, both could work on other platforms, but the reality is that you would need to really understand the finer details of the interaction between the two to execute it. You could also in theory try to use the dev server servlets to run on other platforms. I make no guarantees about the robustness of either solution.
I am just unsure whether Spring has any mechanism preventing users/malicious bots from spamming for example registration request hundred times on my web app.
Does spring offer this kind of protection under the hood and if does not which direction I am to look? Some magical property in Spring Security?
Also does AWS provide any protection against this kind of brute attack when my application is deployed there?
The short answer to both your questions is no. There is no built-in mechanisms in either Spring or Amazon Web services to prevent this.
You will likely have to provide your own implementation to prevent excessive access to your API.
There are a couple of useful resources that can help:
Jeff Atwood's piece on throttling failed log-in attempts should give you a good starting point on how to implement a good strategy for this.
Spring Security's Authorization architecture is really well designed and you can plug in your own implementations fairly easily. It is well documented too.
There is the official Amazon Web Services documentation for using Security Groups, which again should help you ensure you're running on AWS with least permissions in terms of network access
Finally you could look at a service like Fail2Ban for monitoring log files and blocking malicious requests.
So in short there isn't really a simple ready-to-roll solution, but using the above resources should get you on the road to running something that ensures you're using the best practices possible to prevent malicious attempts to access your system.