We continue with the essay on comparison of Kubernetes with platform as a service framework. PaaS may be called out as being restrictive to applications, dictating choice of application frameworks, restricting supported language runtimes and distinguishing apps from services. Kubernetes, on the other hand, aims to support an extremely diverse variety of workloads. As long as the application has been compiled to run in a container, it will work with Kubernetes.  Kubernetes evolved as an industry effort from the native Linux containers support of the operating system.  It can be considered as a step towards a truly container centric development environment. Containers decouple applications from infrastructure which separates dev from ops.
Containers made PaaS possible. Containers help compile the code for isolation. PaaS enables applications and containers to run independently. PaaS containers were not open source. They were just proprietary to PaaS. This changed the model towards development centric container frameworks where applications could now be written with their own     .
. Docker and Kubernetes fueled this move towards custom containers.Many people consider PaaS platform to be fixed and Container framework to be flexible. This is actually a shifting boundary between dev ops and developers
Many people consider PaaS platform to be fixed and Container framework to be flexible. This is actually a shifting boundary between dev ops and developers.

Platform-as-a-service was formed as an abstraction over cloud service providers. Container as a service was formed for the convenience of cloud workloads. Applications written in container frameworks can be moved around from cloud to cloud. For example, a Kubernetes application can be run in different clouds.

Containers made it possible for apps to run anywhere without any virtualization layer or middleware. Container frameworks only increased the coverage to span different systems. Container images also became open source. This made it easier for developers to move from PaaS to container frameworks. It is expected that nearly seventy percent of cloud workloads will run on containers.
In such case what is the future of PaaS?
Containers still need to be managed, deployed and monitored. This is where PaaS is helpful.
One of the improvements we could see going forward is containers dedicated for these purposes in a side-car model of deployment so that apps can focus on their logic while having aa set of sidecars automatically bringing the benefits of PaaS to container framework. Cert-managers and logging sidecars are an example of this.

We continue with the essay on comparison of Kubernetes with platform as a service framework. PaaS may be called out as being restrictive to applications, dictating choice of application frameworks, restricting supported language runtimes and distinguishing apps from services. Kubernetes, on the other hand, aims to support an extremely diverse variety of workloads. As long as the application has been compiled to run in a container, it will work with Kubernetes.  Kubernetes evolved as an industry effort from the native Linux containers support of the operating system.  It can be considered as a step towards a truly container centric development environment. Containers decouple applications from infrastructure which separates dev from ops.
Containers made PaaS possible. Containers help compile the code for isolation. PaaS enables applications and containers to run independently. PaaS containers were not open source. They were just proprietary to PaaS. This changed the model towards development centric container frameworks where applications could now be written with their own containers. Docker and Kubernetes fueled this move towards custom containers.Many people consider PaaS platform to be fixed and Container framework to be flexible. This is actually a shifting boundary between dev ops and developers

We continue with the essay on comparison of Kubernetes with platform as a service framework. PaaS may be called out as being restrictive to applications, dictating choice of application frameworks, restricting supported language runtimes and distinguishing apps from services. Kubernetes, on the other hand, aims to support an extremely diverse variety of workloads. As long as the application has been compiled to run in a container, it will work with Kubernetes. PaaS provides databases, message bus, cluster storage systems but those can run on Kubernetes. There is also no click to deploy service marketplace. Kubernetes does not build user code or deploy it. However it facilitates CI workflows to run on it.
We also have integration with Open-stack for linux containers. The plugin allows the hosts to be compute nodes while the container takes on the workloads from the user.
The IaaS offerings from public cloud storage services include disks and files where as the PaaS offerings from public cloud storage services include objects, tables and queues. The storage offerings are built on a unified distributed storage system with guarantees for durability, encryption at Rest, strongly consistent replication, fault tolerance and auto load balancing.  The IaaS is made up of storage arrays, virtual machines and networking. The PaaS is made up of existing frameworks, web and mobile, microservices and serverless compute.
PaaS  provides Application Gateway which can manage backend with rich diagnostics including access and performance logs, VM scale set support and custom health probes.
The Web Application Firewall security protects applications from web based intrusions and is built using ModSecurity and CoreRule set. It is highly available and fully managed.

Native Containers are small and fast. They have two characteristics. First the containers are isolated from each other and from the host in that they even have their own file system. which makes it portable across cloud and os distributions. Second the immutable container images can be created at build/release time rather than the deployment time of the application since each application doesn't need to be composed with the rest of the application stack nor tied to the production infrastructure environment. Kubernetes extends this idea of app+container all the way where the host can be nodes of a cluster. Kubernetes evolved as an industry effort from the native Linux containers support of the operating system.  It can be considered as a step towards a truly container centric development environment. Containers decouple applications from infrastructure which separates dev from ops. Containers demonstrate

We continue with the essay on comparison of Kubernetes with platform as a service framework. Kubernetes requires applications to conform to its model. Most of the applications can be leaner on a container framework than on a PaaS platform because they can focus on business logic while assuming additional functionalities to be provisioned via optional plug-ins. Containers are cheaper and faster to spin up and these are sometimes necessary considerations for auto-scaling and load balancing.
Writing APIs is a breeze if we have the framework already. We can just publish, manage, secure and analyze our APIs in minutes. We secure the API with Active Directory, single sign-on and OAuth and generate client-proxies or APIs in the language of our choice. Similarly enterprise API can be mashed up and integrated with API management and Logic Apps.  Both PaaS and container framework provide the ability to write these API but deployers prefer one over the other when their deployments have to span clouds.
Both applications and services can take benefits of CloudFoundry and PaaS. They are not restricted to the same physical machine that they were once deployed on. With these software, the applications and services can be rolled from one host to another seamlessly without any loss of functionality. They don't require any updates either to code or configuration when they are rolled between hosts.
API software usually exposes an http/https endpoint and port for connectivity. While it may involve authentication, encryption and use of api-keys, all of these are done over basic authentication scheme or OAuth, they are  contained to api implementations and external service consolidators such as a gateway.  A user interface on the other hand may have to integrate with an identity provider and authentication mechanism such as SAML or OAuth external and probably central to an organization and not necessarily within the control of the applications and services framework. Fortunately these are facilitated with a route from the PaaS. The application merely has to handle the redirects from the said authentication mechanisms and the redirects are to specific name:port that can be ported between PaaS hosts as routes. The external ip address of the host and port can be retrieved in code as CF_INSTANCE_ADDR and CF_INSTANCE_PORT
PaaS may be called out as being restrictive to applications, dictating choice of application frameworks, restricting supported language runtimes and distinguishing apps from services. Kubernetes, on the other hand, aims to support an extremely diverse variety of workloads. As long as the application has been compiled to run in a container, it will work with Kubernetes. PaaS provides databases, message bus, cluster storage systems but those can run on Kubernetes. There is also no click to deploy service marketplace. Kubernetes does not build user code or deploy it. However it facilitates CI workflows to run on it.
We also have integration with Open-stack for linux containers. The plugin allows the hosts to be compute nodes while the container takes on the workloads from the user.

An essay on comparison of Kubernetes with platform as a service:
Kubernetes is a container framework that enables migration of applications across hosts and provides all abstractions that they need. An application can also run on platform as a service. Virtual machines provide operating system level application isolation support with the help of say Linux containers but  Kubernetes takes it to the next level with the separation of hosts in the form of pods. Container infrastructure layering allows even more scale because it virtualizes the operating system.
The platform-as-a-service model has a dev-ops centric model for application hosting. It enables development and debugging using API, IDE and CI/CD interface. It supports different application types with dedicated application stacks. These application stacks may even be configured to bring out their best from an operations perspective or they may be bundled with other products that improve their overall appeal. PaaS is facilitated with the help of hypervisors which requires hardware support. It is able to launch virtual machines to support isolation of applications and this brings deeper virtualization than container framework.  Separation of hosts as virtual machines enables technology specific stacks to be provisioned. Together with the availability of a wide variety of products that are installable on virtual machines and the layering of applications on specific operating systems such as the LAMP stack, PaaS provides significant capabilities in improving the operations of a hosted application.
On the other hand, Kubernetes provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
Kubernetes requires applications to conform to its model. Most of the applications can be leaner on a container framework than on a PaaS platform because they can focus on business logic while assuming additional functionalities to be provisioned via optional plug-ins. Containers are cheaper and faster to spin up and these are sometimes necessary considerations for auto-scaling and load balancing.
Writng APIs is a breeze if we have the framework already. We can just publish, manage, secure and analyze our APIs in minutes. We secure the API with Active Directory, single sign-on and OAuth and generate client-proxies or APIs in the language of our choice. Similarly enterprise API can be mashed up and integrated with API management and Logic Apps.  Both PaaS and container framework provide the ability to write these API but deployers prefer one over the other when their deployments have to span clouds.

We were discussing the STRIDE model of threat modeling for keycloak deployments on Kubernetes.
 Service broker listens on port 9090 over http. Since this is internal, it has no TLS requirements. When the token passes the trust boundary, we rely on the kubectl interface to secure the communication with the API Server. As long as clients are communicating with kubectl or the API Server, this technique works well. In general, if the server and the clients communicate via TLS and they have verified the certificate chain, then there is little chance of token falling in wrong hands. The URL logging or https proxy are still vulnerabilities but the man in the middle attack is less of an issue if the client and the server exchange session id and keep track of each other's session id. As an API implementation, session Id's are largely site or application based and not the APIs concern but it’s good to validate based on session id if such is available.
Sessions are unique to the application. Even the client uses refresh tokens or re-authorizations to keep the session alive. At the API level, if the sessions were kept track of, it would not be tied to the OAuth revokes and re-authorizations, hence relying on session id alone is not preferable. At the same time, using session id as an additional parameter to confirm along with each authorization helps tighten security. It is safe to assume the same session prevalence until the next authorization or an explicit revoke.  By tying the checks exclusively to the token, we keep this streamlined to the protocol.
In the absence of session, we can use refresh tokens after token expiry. Since the refresh token is a protocol (RFC) intrinsic technique, it is already safe to use to prolong the period of access beyond token expiry time. Repeatedly acquiring a refresh token is the same as keeping a session alive. The above threat mitigation works regardless of the actual implementation of a notion of session.
Applications/clients could potentially redirect to each other for the authorization of the same user, either directly or via the Keycloak service broker. This enables the user to sign in far lesser than before. If the user is signed in to a few sites, he can use the existing signed in status to gain access to other sites. This is not just a mere convenience to the user, it enables same user to float between sites and enables applications to integrate and share user profile information for a richer user experience. In our deployment, the only user interface application is the nautilus-ui/Keycloak and we do not have any cross-application usages. All internal components maintain their own service instance (clients) and service bindings (roles) and the token used with one client is not used with another client. It is merely renewed specific to that client.
Recommendation: we add a configuration to Keycloak-service-broker that checks the request parameter for the issuing host and verify with the host in the redirect.

I'm on vacation between July 2 - July 17