Today we continue with the discussion on tools and methodology to come up with threat models and reduce risk. Ee referred to the STRIDE model. It 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.
We begin applying the STRIDE assessment using a data flow diagram. For keycloak on Kubernetes we have:
• 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.
We begin applying the STRIDE assessment using a data flow diagram. For keycloak on Kubernetes we have:
 |
| Keycloak on Kubernetes data flow diagram |
The Service catalog returns the details of the resource as a K8s secret. If the application persists the K8s secret on a mounted volume, care must be taken to mark the volumes as readOnly.
Similarly, while Keycloak configuration is internal, it should be prevented from reconfiguration after the deployment.
The 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 implementatioon, 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.
#pagerank
def pagerank (u, constant):
sum = constant
For node-v in adjacencies (u):
sum += Pagerank_for_node_v (node-v) / number_of_links (node-v)
return sum
Similarly, while Keycloak configuration is internal, it should be prevented from reconfiguration after the deployment.
The 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 implementatioon, 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.
#pagerank
def pagerank (u, constant):
sum = constant
For node-v in adjacencies (u):
sum += Pagerank_for_node_v (node-v) / number_of_links (node-v)
return sum
No comments:
Post a Comment