I'm working with the NIST CSF and more specifically subcategory PR.PT-3. Would an organization's use of containers help meet this control? Implicit in my question is the following question: do containers inherently meet or almost meet the principle of least functionality given their sole purpose is usually an application?
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 months ago.
Improve this question
I'm a student and I'm supposed to set up a usable cluster for the university in the next semester. The main requirement is that other students can easily work with it. The cluster consists of 20 Linux PCs and 20 Macs. Other students should be able to quickly get applications like Kubernetes, Hadoop, etc. running with little configuration. At best deploy application, determine the node number and done (exaggerated). What is the best way to do this. I've skimmed over tools like Ansible and Terraform, they sound like something im looking for, but don't know anything about them.
Thanks a lot in advance!
Such questions are generally discouraged since they are not really questions but rather design problems but I'll answer anyway just to give you some idea.
Keep in mind that an architecture with 40 machines is not something easy to achieve for a beginner, so you should have a lot of patience and dedication when working on the project.
You are looking for a design type which is generally referred to as Infrastructure as a Service - IaaS. This allows tenants (the users of the cloud) to be able to deploy their own application/clusters on top of an existing infrastructure that you will provide. For this, you will have to start with something like openstack, which is one of the ways in which you can achieve this and you will have to do a lot of work to learn how it works, deploy it, and add your 40 machines to it. You can get started here. [I'm really unsure if you can use Mac systems as part of a cloud - but I'm really curious to know if it is possible]
Once you have setup an openstack infrastructure, you will have to think about maintenance and management of your system. There, you will have to think about solutions like ansible and terraform that will allow you to provide easy to use templates to you students where they will be able to edit some text files to match their specifications, and then deploy them on top of your openstack infrastructure easily. This practice is known as Infrastructure as Code - IaC. This helps you maintain your infrastructure designs as simple text files in a VCS (Version Control System) like Git for easier maintenance/rollback/upgrade etc.
The overall flow will look like this:
Student => Creates Manifests => Applies them to an Openstack account => Manages/Uses/Interacts with the deployed application
You => deploy Openstack => manage student accounts (tenant projects) => Monitor it => Maintain it => make sure it is available => Provide templates for deploying the 'overclouds'
There is no easy and simple answer to this very generic and complicated problem, but it is possible, for sure. I hope this gets you started.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I'm wondering about the best practices for architecting my Kubernetes clusters.
For 1 environment (e.g. production), what organisation should I have in my clusters?
Examples: 1 cluster per technology stack, 1 cluster per exposure area (internet, private...), 1 cluster with everything ... ?
Thanks for your help
I'm not a Kubernetes expert, so I'll give you some generic guidance to help until someone who knows more weighs in.
By technology stack - no. That wouldn't provide any value I can think of.
By 'exposure' - yes. If one cluster is compromised the damage will hopefully be limited to that cluster only.
By solution - yes.
Solution vs Technology Stack
"Solution" is where you have a number of systems that exist to addresses a specific business problem or domain. This could be functional e.g. finance vs CRM vs HR.
Technology stacks in the literal sense is not likely to be relevant. True, it's not uncommon for different solutions & systems to be comprised of different technology (is that what you were meaning?) - but that's usually a by-product, not the primary driver.
Let's say you have two major solutions (e.g. the finance and CRM). It's likely that you will have situations that impacts one but shouldn't impact the other.
Planned functional changes: e.g. rolling out a major release. Object Orientated programmers and architects have had this nailed for years through designing systems that are cohesive but loosely-coupled (see: Difference Between Cohesion and Coupling), and through stuff like the Stable Dependencies Principle. Having both solutions dependent on the same cluster makes them coupled in that respect, which.
Planned infrastructure changes: e.g. patching, maintenance, resource reallocation, etc.
Unplanned changes: e.g. un-planned outage, security breaches.
Conclusion
Look at what will be running on the cluster(s), and what solutions they are part of, and consider separation along those lines.
The final answer might be a combination of both, some sort of balance between security concerns and solution (i.e. change) boundaries.
The best way would be is to have 1 kubernetes cluster and have the worker nodes in private subnets. You can choose to have the control plane in a public subnet with restricted access like your VPN cidr etc.
If you have multiple teams or application stacks, I'd suggest having different namespaces for each stack as this creates the logical separation of resources.
Also, check the resource limits and quotas that you can apply on kubernetes to prevent over consumption of the resources.
And, as you mentioned multiple application stacks, I am assuming you would have multiple services being exposed for each application or something similar. I would highly recommend using a ingress controller (nginx or anything) to work as single point of entry for each application. You can have more than 1 application listening to 1 load balancer.
Also, have prometheus or ELK monitoring in place as they are great with monitoring k8s components and metrics.
And, I would highly recommend using a tool kubecost and kubebench for enhancing your k8s cluster.
Kubecost is for cost analytics and reporting for k8s components and kubebench would audit your cluster against CIS standards and give you a report on what improvements are required and where.
Please note that the above recommendations are based on best practises and cost efficiency.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
First of all, a disclaimer - I know that this questions might be too "open-ended" for SO, but I honestly could not find a better place for it (and the K8s docs specifically recommend any questions be directed to SO).
My company has decided to switch the main production infrastructure to Kubernetes. However, there is some significant pushback from the developers, who would prefer not to run the CI/CD pipeline on the same cluster as the production workloads. They prefer to keep some dedicated VMs for that purpose, the main reason given that "we should not put all our eggs in one basket".
With me coming from the other side of devops (the "ops" side), I would prefer to have everything in one place, managed using the same set of tools. Unfortunately, I cannot find any documented best practices stating one way or another.
So my questions are:
Based on personal experience, would you recommend one type of deployment over another? Why?
Can anyone point me to a link making the argument one way or another? Any recommendations that we should follow in such a case?
Unfortunately, I cannot find any documented best practices stating one way or another.
This is all depends on how strong separation you want. In Kubernetes you can separate environments by using a separate namespace, but for professional company environments, you typically want stronger separation. If you use a cloud provider, it is common to separate with a different account for "production", aslo with different access rights.
developers, who would prefer not to run the CI/CD pipeline on the same cluster as the production workloads.
If this is for a professional organization, I agree with them. You want to use completely separated VMs, network and load balancer. If you use a cloud provider, it is also good to use a different cloud account and vpc (virtual private cloud - network).
Recommendation
With me coming from the other side of devops (the "ops" side), I would prefer to have everything in one place, managed using the same set of tools.
I agree with both you and your developers. Use a dedicated cluster for production and a different cluster for development. Do all changes in the production cluster via CI/CD pipelines. Restrict access (at least, write access) to the production environment.
With that setup, you only have two clusters that are in active use, not more - but also strong separation for the production environment.
References
See Best practices for enterprise organizations for a good document on best practices for organizations.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
First of all, I spent some time thinking whether this question belongs to SO, so if you think it is more appropriate for some other Stack Exchange site, please feel free to recommend or migrate.
I am writing a REST application which will be able to register new users and allow the existing users to interact with each other (you can imagine a forum or a minimalistic social network, for example).
At the moment, I have a simple app setup with database schema, spring-JPA and spring-data-rest exposing all the repositories.
However, all users are now able to access all the resources from the server. I would like a user to see only his own entities: for example by going to /api/user/messages.
I am also going to use some security in the application, probably OAuth2, so I need it to be compatible.
I have read some articles and SO questions concerning this topic and decided that multi-tenancy might be a solution to my problem. Usually though, these articles work with separate databases for each client and smaller number of clients in total so I am curious whether it is actually meant to be used for a huge number of users in the system. I expect all the users to share the database with their records and use the same schema.
Is there some tutorial for this topic concerning spring boot and shared database-schema? Or is there some better approach how to solve this problem? I would be glad for any tips!
EDIT: As pointed out in the comments, using multi-tenancy might be an overkill for this task, since I only need to separate the users on entity level. I would be glad for any hint how to do that in Spring boot and JPA since I have found no tutorials concerning this topic.
There aren't many explanations on how to achieve what you've described even though it would seem to be a common problem. Hopefully the Spring team will address this very common use case. The following is what I've seen as two possible solutions, the second of which is what I use.
Complex Solution:
Spring Security ACL
Simple Solution:
#Query Method Security Expressions
Example:
#Query("select m from Message m where m.user like ?#{hasRole('ADMIN') ? '%' : authentication.name}")
#Query methods are typically used to define more complex queries than can't easily be written in the method-name query creation that is a standard mechanism of Spring Data.
You can add Security logic within a #Query method that can return different results based on who the User is.
The above example will return all Messages if the User has a Role of ADMIN, but if not it will return only their own Messages. This has the added benefit of Query optimization. You could select all the records and then programmatically filter out those that the User doesn't have access to, but for large queries this becomes a bottleneck. This will adjust the query at runtime based on who is requesting the data. I've found it to be the best way to achieve the desired behavior without implementing a full ACL.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm tasked with investigating for our firm a full-stack solution where we'll be using a NoSQL database backend. It'll most likely be fed from a data warehouse and/or operational data store of some type in near-realtime (hopefully :). It will be used mainly by our mobile and web applications via REST.
A few requirements/assumptions:
It will be read-only (in the near term) and consumed by clients in REST format
It has to be scalable
Fast response time
Enterprise support - or if lacking actual support, something industry proven if open-source (basically management wants to hold
someone accountable if something in the stack fails)
Minimal client data transformations - i.e: data should be stored in as close to ready-to-use format as possible
Service API Management of some sort will most likely be needed (eg: 3scale)
Services will be used internally, but solution shouldn't prevent us from exposing them externally as a longterm goal
Micro-services are preferable (provided sufficient API management is in place)
We have in-house expertise in Java and Grails for our mobile/portal solutions
Some of the options I was tossing around were:
CouchDB: inherently returns REST - no need for translation layer - as
long as clients speak REST, we're all good
MongoDB: need a REST layer in between client and DB - haven't found a widely used one based on my investigation (the ones on Mongo's site all seem in their infancy - i.e: RestHeart)
Some questions I have:
Do I need an appserver? Or any layer in between the client and DB
for performance/caching reasons? I was thinking a reverse-proxy like
nginx would be a good idea for this?
Why not use CouchDB in this solution if it supports REST out of the box?
I'm struggling with deciding between which NoSQL DB to use, whether or not I need a REST translation layer, appserver, etc. I've read the pros and cons of each and mostly they say go Mongo - but for what I'm trying to do the lack of a mature REST layer is concerning.
I'm just looking for some ideas, tips, lessons learned that anyone out there would be willing to share.
Thanks!
The problem with exposing the database directly to the client is that most databases do not support permission control which is as fine-grained as you want it to be. You often can not allow a client to view and edit its own data while also forbidding it from viewing and editing any data of other users or even worse from the server itself. At least not when you still want a sane database schema.
You will also often find yourself in the situation that you have a document with several fields of which only some are supposed to be under the control of the user and others are not. I can, for example, edit the content of this answer, but I can not edit the time it was posted, the name it was posted under or its voting score. So far I have never seen a database system which can handle permission for individual fields (when anyone has: feel free to post in the comments).
You might think about trying to handle this on the client and just don't offer any user interface for editing said fields. But that will only work in a trusted environment. When you have untrusted users, they could create a clone of your client-sided application which does expose this functionality. There is no way for you to tell the difference between the genuine client and a clone, especially not when you don't have a smart application server (and even then it is practically impossible).
For that reason it is almost always required to have an application server between clients and database which handles authentication and permission management of the clients and only forwards those requests to the persistence layer which are permitted.
I totally agree with the answer from #Philipp. In the case of using CouchDB you will minimum want to use a proxy server in front to enable SSL.
Almost all of your requirements can be fulfilled by CouchDB. Especially the upcoming v2 will give you the "datacenter-needs".
But it's simply very complex to answer what should be the right tool for you purpose. If you get some business model requirements on top like lets say: throttling - then you will definitely need an application server middleware like http://mcavage.me/node-restify/
Maybe it's a good idea to spend some money to professionals like
http://www.neighbourhood.ie/couchdb-support/ ? (I'm not involved)