This is an initial draft of the STRIDE model of threat mitigation in authentication performed on Kubernetes clusters.
STRIDE stands for
Spoofing Identity – is the threat when a user can impersonate another user
Tampering with data- is the threat when a user can access Kubernetes resources or modify the contents of security artifacts.
Repudiation – is the threat when a user can perform an illegal action that the Kubernetes cannot deter
Information Disclosure – is the threat when say a guest user can access resources as if the guest was the owner.
Denial of service – is the threat when say a crucial component in the operations of the Kubernetes is overwhelmed by requests so that others experience outage
Elevation of privilege – is the threat when the user has gained access to the components within the trust boundary and the system is therefore compromised.
Usually we begin the process of evaluating against these factors with a control and data flow diagram.
A control flow diagram may look something like this:

Now we apply how the different threats can arise in this diagram by partitioning it between that which is within trust boundary and that which is outside.
When a user1 can behave like user2, that is considered spoofing. Possible defense might involve issuing tokens specific to users.
Tampering is when the user has successfully modified the token to her advantage.
Repudiation is when the user can hijack a valid token that the system cannot refure.
Denial of Service is when the user can tank the Identity provider (IDP) or the API server.
Elevation of privilege is when the user has compromised the IDP or the API server.

There are a few other troubleshooting mechanisms which we can call supportability measures. I’m listing them here.
Monitoring and Alerts – System events are of particular interest to administrators and users. A way to register monitors and their policies will help to have an overarching and comprehensive view of the operations of the product. Different kinds of sensors may be written for this purpose and packaged with the product.
Counters- performance counters for various operations of the product will be very helpful for diagnosis on what takes a lot of time. When the elapsed time and processing time are measured separately, they help tremendously in finding bottlenecks or long running tasks.
Dynamic views – If the operational data is persisted then the current window of activity can be viewed with built-in queries. After all the storage product stores streams and it can take all activity data as append-only data.
User Interface – There are pages that can help remote monitoring of products and troubleshooting via viewing their logs or setting up back channels of communication with the hosts of the application. Such interface will be very helpful for remote troubleshooting on customer deployments.
The APIs for collecting metrics from the system will prove very helpful to other applications who don’t need to involve other means of access and roll these operation monitoring workflows into theirs. API invocation decouple technology stacks and help with independent monitoring. Since API are published over the web, they are usable across networks.
Virtually all API can be packaged into an SDK for developer convenience. These will tremendously improve the possibilities for application development and open up the boundaries for custom usages. Such expanded possibilities means the product will endear itself to developers and their organizations.

Transparency in user query execution:
Streaming queries are a new breed. Most applications like Flink require the query logic to be packaged in a module prior to execution. Although a user interface is provided, much of the execution and its errors are latent. Consequently, the user has very limited tools for progress, debugging and troubleshooting in general
For example, when the Flink application is standalone and a query has been provided, the user may receive no output for a long while. When the data set is large, the delay might be confusing to the user on whether it comes from the processing time over the data set or whether the logic was incorrectly written. The native web interface for the Apache Flink provides some support in this regard. It gives the ability to watch for watermarks which can indicate whether there is any progress made. If there are no watermarks then it is likely that the event time windows never elapsed.
Similarly, if the logic requires extract-transform-load of data, there is an increased likelihood of resource consumption and overall performance impact. This might manifest itself by way of myriad symptoms such as error messages and failed executions.
The error messages themselves usually suffer from two problems. One they are not descriptive enough for the user to take immediately resolving actions. And second they don’t generally differentiate between user error and operational error. For example, “an insufficient number of network buffers” does not immediately mean parallelism must be reduced. Another example is when a NotSerializableException does not indicate if the user’s query logic must be changed or if the data is just not good.
The absence of a progress bar on the UI and the requirement that the user follow Flink conventions only makes it more difficult to troubleshoot. User has syntax from Flink such as savepoints to interpret progress.  Users can create, own or delete savepoints which represents the execution state of a streaming job. These savepoints point to actual files on the storage. If the access the savepoints becomes restricted or unavailable in some circumstance, the troubleshooting is impaired. Contrast this with Checkpointing which the Flink creates and deletes without user intervention. While checkpoints are focused on recovery, much more lightweight than savepoints, and bound to the job lifetime, they can become equally efficient diagnostic mechanisms

Earlier archives and tar balls of executables from different languages were made available to the user to run an application. However, this approach involved more user interaction than images. Images are also convenient for sharing on registries across organizations.
However, this new format of packaging has posed new challenges for verification and validation as opposed to the executables that often had both binaries and symbols where the symbols could become helpful in interpreting the executables. Moreover, code analysis tools used to work very well with introspection of executables. Rigorous annotations in the code as well as analyzers of these static annotations tremendously improved the sanctity of some of the executables as the end product of all the application development.  With the availability of images, it was harder to tell if there was anything injected or otherwise contaminating the image
Therefore the only option left for organizations is to control the process with which images proliferate. Strict control of process helps and access control of end product helps ease the validity of the images. However peer to peer exchange of images is also just as important for the general usages as the images from corporations. Therefore there is a certain class differentiation made available in the registry as public and private as well as internal images and external facing images.
When the verification and validation of images are described as standard routines regardless of the origin of images, they can be encapsulated in a collection where each routine corresponds to a certain security policy. These include policy definitions that are standard as well as those that are custom to specific entities, departments or time-periods. The evaluation of a routine for a policy is however an automatable task and can be made available as a software product or development library depending on the spectrum between full-service and do-it-yourself approach.
Much of the validation and verification is therefore external to the binaries and images and the technology to perform these can also be saved as custom images.
One of the advantages of integration with build pipeline is that the verification and validation are triggered more often. This enables continuous integrations where every build can be considered to be vetted.
Scanning the end-results of the build for the security vulnerabilities is also another benefit of doing this at build time. Now the fixes can not only be monitored on a build to build basis, but also the vulnerability defects will be flagged before the binaries reach the consumers.

An embedded Keycloak application extends the class KeycloakApplication. (Names of classes from the Keycloak source used here are italicized for better reading) It can keep the KeycloakServerProperties with defaults.  This embedded Keycloak application registers a set of users to begin with. For each user, it creates a KeycloakSession It persists the user and the session in a corresponding Keycloak user json file and defines an ExportImportConfig with this temporary file. An ExportImportManager  is then instantiated with the session and used to run an import.
An embedded Keycloak application will do two things on instantiation. First – it will create a master realm admin user and Second it will import the Keycloak existing configuration file.
The creation of the master realm admin user is the same concept that every Keycloak application does. That’s why it just uses the existing ApplianceBootstrap class to create a master realm user in a transaction scope for which it uses the session’s transaction manager. The admin username and password is obtained from the KeycloakServerProperties which we had initialized with defaults in the beginning
The second step merely finds the configuration file to import the users. If the embedded application has registered users with configuration file, it is imported otherwise the default keycloak application file is imported.
The Keycloak embedded application needs to be hosted on an embedded web server. Jetty or tomcat could serve this purpose. A suitable servlet stack will be added to the bootstrap and its corresponding reactive stack will give access to connectors, server resources and the server itself. The Keycloak server properties is used to configure the application The Keycloak session destroyer listener is used to add a listener and the Keycloak session servlet filter is used to add a filter. Essentially, we instantiate a container with this servlet and this brings a lot of utilities as opposed to working natively with an http handler and the container exposes a way to treat it as an http handler.
A path handler will route the requests to this servlet. Together the http handler and the path handler are registered to create an instance of the jetty or the tomcat server. At this point the Keycloak web application has been started.
Now with this embedded web application, we can take the following steps. We can register a Keycloak client in the master realm and request an access token. The access token will be used to list the clients with the secure endpoint and a successful response should indicate that the token was used.
Optionally a role can be defined in the master realm and the embedded application can be used to validate the role. This is optional because it involves registering a user and mapping the role to the user.

• 
  

Address Book:
Most address books are proprietary in nature or at least tied to a software stack. Active Directory for instance does not let you access the address book without tightly integrating it with their network, enabling access only with their protocol and query language and requiring their own access routines.
Contact Books from Phone Applications to membership directories are proliferating on the other hand and often taking up space and consuming resources on the other hand while remaining local and often out of date. 
Somewhere between these two extreme examples of address books, we see the need for universally accessible cloud storage for a directory representing the address book and its natural querying over the World Wide Web from any device anywhere.
Since the address book is primarily an unstructured data on the wire, there is very little need to see it as one requiring the onus of a structured storage at least for the majority of the use cases. Besides these access requirements, object storage brings out the best in storage engineering to keep the data durable and available in the cloud.
An object store offers better features and cost management than most competitors such as relational databases, document data stores and private web services. The existence of data library product in the market on a variety of stacks and not just the Address Book software providers indicate that this is a lucrative and a commercially viable offering. MongoDB for instance competes well in this market. From database servers to an appliance, the data library product is viewed as a web accessible storage but it provided with form of constraints to its access. Object storage not only facilitates this web access but also provides no restraints on its access making it the most flexible platform for dynamic queries and analysis. It does not treat the physical data stores as a mere content while providing storage engineering best practice on all the data.
At the same time, a document stores provides all aspects of data storage for storing and querying an address book. It is not a traditional address book but it addresses most of the requirements. A traditional address book has been bound to a database for long and we have argued that it does not need to be so for non-transactional read and write.  In json, these appear as nested fields and are pre-joined into objects.  The frequently accessed objects can be in the cache as well.  A search engine provides search over this catalog. Since the address book entries are independent just like in a document or catalog, we can refer its access to be similar to that for a catalog. Therefore, functional data access is provided by the Catalog API. The API and the engine separately cover all operations on the catalog. The API can then be used by downstream units. A search engine allow shell like search operators which can be built on Lucene/Solr Architecture. A Lucene index keeps track of terms and their occurrence locations but the index needs to be rebuilt each time the catalog changes. The Catalog API can retrieve results directly from the catalog or via the search engine. In both cases, the customer only issues a single query. 
In a sense, this is very similar to how we want the object storage to store the catalog and make it web-accessible. The data is available for retrieval and iteration directly out of the store while hierarchy and dimensions may be maintained by a web service over the Object Storage.

We now review the integration testing of embedded Keycloak. This is facilitated with the help of a Keycloak Spring security adapter. The adapter is installed by declaring a dependency on the Maven POM or Gradle build using the artifact Id of keycloak-spring-security-adapter. The adapter does not get included in the web.xml. Instead a keycloak.json is provided.
Since we are using Spring security, Keycloak conforms with a convenient base class KeycloakWebSecurityConfigurerAdapter with which we can instantiate the security context configuration.  This class provides methods to configure HTTPSecurity, register the Keycloak authentication provider as the global authentication provider and the session authentication strategy. A NullAuthenticatedSessionStrategy used for bearer-only applications is sufficient for integration testing.
This Keycloak adapter also supports multi-tenancy. This refers to using the same application to secure multiple Keycloak realms. Each realm is supported with the help of an instance that implements the KeycloakConfigResolver interface. Typically, a resolver requires to lookup a Keycloak.json specific to a realm and the resolver is mentioned in the web.xml file of the Spring application.
All Spring applications have a naming convention. This includes Security Roles. Keycloak security roles must conform using the ROLE_ prefix. Since bearer tokens can be passed between clients, Keycloak provides an extension of Spring’s RestTemplate which can be invoked by Spring SecurityConfig
Note that Keycloak as a standalone instance requires the user interface for registering users and clients and requesting access before bearer tokens can be issued. It is only in the embedded form, that we avoid using this configuration Therefore, embedded is not really a hack on the Keycloak product but one sufficiently modified for testing purposes.