WSO2 Carbon supports the following methods for sharing resources among tenants:
Private Jet mode
Separation at hardware level
Separation at JVM level
Native multitenancy
So how can we configure these resources among tenant?
AFAIK you cannot share data between Tenants in carbon platform. Tenants are considered as Isolated entities and there is no sharing of data.
Related
Dear AWS and Cloud Gurus,
I am tasked with the design of a new AWS account structure that is to serve as a development and runtime environment for multiple development teams. The goal here is that multiple individual teams can work on different projects, each in their own AWS account but make use of some shared services and inherit certain elements from a top-level account.
An example for a shared service inherited from the top-level account would be billing. An example for a shared service on the same hierarchy would be authentication and authorisation services.
The projects the different teams work on are all accessible in the end through a unified platform / portal. The user logs onto that portal and can then execute different functions or even start complete applications which are actually developed by the different teams in their respective account.
Now my question is this: What would be a best practise approach on this? Should all teams work in a shared repository, or should each have their own code repository in their own account? Shall the deployment be done into a central account or should the teams deploy within their own account and the app is called from the portal from this account then?
I will try to picture this:
As you can see, there are essentially 5 different AWS Accounts:
The root/masdter Account holds the billing information and also allows for central administration of quotas
Then there are 4 AWS Accounts each with it's own Code Repository and independent access points. 3 of these hold different applications (developed as SPAs) while the forth provides a central navigation page (aka Dashboard) and also provides SSO to the other applications.
Is this setup feasible, given there are different, independent application development teams involved but the applications they provide are in the very end used from a central platform for the end user? How would you go about this?
With the kindest regards,
Chris
I want to share a DB(PostgreSQL) service across the spaces in same cf Org.
I came across two options
User-Provided Service Instances (https://docs.cloudfoundry.org/devguide/services/user-provided.html)
Sharing Service Instance(https://docs-cloudfoundry-staging.cfapps.io/devguide/services/sharing-instances.html)
The shared service instances say, it improves the security, auditing, and provides a more intuitive user experience.
Can anyone throw some more detailed light on the advantages and disadvantages of both?
User provided services can do more than be used to share services, sharing services across org/spaces is just one use case for user provided services.
If you're looking to share services & your service broker supports it, you should use that option over user provided services.
User provided services are good for cases where the broker doesn't support sharing services or where you want to do something totally different like create a service where no broker exists.
Hope that helps!
In the SPIFFE specification it is stated that
Since a workload in its early stages may have no prior knowledge of
its identity or whom it should trust, it is very difficult to secure
access to the endpoint. As a result, the SPIFFE Workload Endpoint
SHOULD be exposed through a local endpoint, and implementers SHOULD
NOT expose the same endpoint instance to more than one host.
Can you please explain on what is meant by this and how Istio implements this?
Actually, Istio mesh services adopt SPIFFE standard policies through Istio Security mechanisms using the same identity document SVID. Istio Citadel is the key component for secure provisioning various identities and provides credential management.
It is feasible in the near future to use Node agent within Istio mesh in order to discover relevant services via Envoy secret discovery service (SDS) API and this approach is very similar to SPIRE design.
The key concepts of SPIRE design, described in the official documentation, you can find below:
SPIRE consists of two components, an agent and a server.
The server provides a central registry of SPIFFE IDs, and the
attestation policies that describe which workloads are entitled to
assume those identities. Attestation policies describe the properties
that the workload must exhibit in order to be assigned an identity,
and are typically described as a mix of process attributes (such as a
Linux UID) and infrastructure attributes (such as running in a VM that
has a particular EC2 label).
The agent runs on any machine (or, more formally, any kernel) and
exposes the local workload API to any process that needs to retrieve a
SPIFFE ID, key, or trust bundle. On *nix systems, the Workload API is
exposed locally through a Unix Domain Socket. By verifying the
attributes of a calling workload, the workload API avoids requiring
the workload to supply a secret to authenticate.
SPIRE promises to become the main contributor for workload authentication mechanisms, however so far it's on developing stage with desired future implementation on production deployments.
In the multi-tenanted environment (create and work with tenants), Registry Database is required to share the information in this database between the Gateway and Key Manager components.
So in the above line Which information need to be shared and where it need to be shared?
There is no special DB configurations for Multi-tenancy, Tenant related information will be stored in same DBs. And when you are clustering APIM you need to share databases among the nodes irrespective of tenant usage. You can refer this guide for clustering.
What is basically says is you need to do step 8.c and 11 in Installing and configuring the databases section in API Manager clustering guide for gateway and keymanager nodes as well.
I have a number of different SOA services that use different approaches for storing configuration data for the service. For example the configuration data is stored in database tables, property files, and jndi.
I would like to standardize my approach to storing configuration data. Is the carbon registry an acceptable place to store all the configuration data for my services?
Can I just store this data directly in the carbon registry, or should I be looking to just use the WSO2 Governance Registry for this data?
What does WSO2 Governance Registy give me that is not provided by directly using the carbon registry?
" Is the carbon registry an acceptable place to store all the
configuration data for my services?"
The best practice would be,
Store the Resource Metadata in Registry and run-time data in a database.
Is the carbon registry an acceptable place to store all the
configuration data for my services?"
Yes, you can store the configurations in the registry. Generally, configurations will be stored in the config space, and the resources which are having governance aspect will go to governance registry space
"What does WSO2 Governance Registry give me that is not provided by
directly using the carbon registry?
Store, manage and search any kind of enterprise asset, including services, APIs, policies, projects or applications. You can extend the predefined asset metadata or create your own
Navigate through assets using taxonomies
Access and manage assets via a REST API, supporting the integration with enterprise initiative such as DevOps
Describe relationships between assets such as dependencies, usage or associations and perform impact analysis
Attach custom life cycle to assets and engage custom actions when an asset transitions from one state to the next
Secure the access to assets via a fine-grained permission model
Leverage social tools such as ratings and comments to enable better communication between asset providers and consumers
Notify users of any asset changes via email or a notification system of your choice
Integrate with mediation engines such as WSO2 Enterprise Service Bus or others via UDDI and REST for dynamic discovery of services and APIs endpoints
There are plenty of advantages of using G-Reg, To see the full list please find this post or offcial G-Reg page.