Azure AKS Audit logs view - audit

i follow this instructions in order to get AKS audit logs.
https://learn.microsoft.com/en-us/azure/aks/view-master-logs
i cant find some basic fields such as stage,level,username..
how can i see the "k8s audit" with the full log?

Here is an example query to get started. It expands the log_s field and removes some of the noise to try and give just logs for when a user has modified a resource in Kubernetes. The requestURI and requestObject fields will give you the most info about what the user was doing.
AzureDiagnostics
| where Category == "kube-audit"
| extend log_j=parse_json(log_s)
| extend requestURI=log_j.requestURI
| extend verb=log_j.verb
| extend username=log_j.user.username
| extend requestObject = parse_json(log_j.requestObject)
| where verb !in ("get", "list", "watch", "")
| where username !in ("aksService", "masterclient", "nodeclient")
| where username !startswith "system:serviceaccount:kube-system"
| where requestURI startswith "/api/"
| where requestURI !startswith "/api/v1/nodes/"
| where requestURI !startswith "/api/v1/namespaces/kube-system/"
| where requestURI !startswith "/api/v1/namespaces/ingress-basic/"

Related

How do I identify and delete the expired FCM token on server?

I'm considering a scenario where a user installs the app on multiple devices say mobile and desktop; and generates two different tokens.
My current plan is to store both the tokens for the user in database. However, I'm not sure how do I handle the scenario when the token is expired and a new token is generated?
For example, this could be the simple db structure -
id | user_id | token
-------------------------
1 | 1 | asdlgkj090sdf8q (desktop)
2 | 1 | zlkroqiuoiquoio (mobile)
3 | 2 | mnnjnjnjnjojuhq
4 | 2 | 498slkdsflksjfl
If the token for mobile gets updated; I've no way of knowing which row to update.
How do I handle such scenario?
If you want to remove the old token after a new one was generated, I can think of two ways of doing this:
Option 1: Introduce a client id
You could give each client a unique ID that you use to identify it. When you send the new push token to the server, you need to make sure that you also pass the client ID to the server. Your database structure would then look something like that:
id | user_id | client_id | token
------------------------------------------------------
1 | 1 | tthdh | asdlgkj090sdf8q (desktop)
2 | 1 | di4dq | zlkroqiuoiquoio (mobile)
3 | 2 | 5efgd | mnnjnjnjnjojuhq
4 | 2 | 56eff | 498slkdsflksjfl
In your update script (on the server) you will check if a push token exists for the given client id and then either replace the old one or insert a new row.
Option 2: Remember the old token
The second option would be to store the current token on the client, and if it is updated you send both the old and the new token to the server. Then you search for the old token and replace it (or insert a new row if the old token is not present).
If you want to find out if a given token is expired, check this answer. Another approach that I've seen in the Firebase documentation was to remove the token that was used to send a push message if sending the message failed.
The best way to do that is the described method in documentation of server-integration from google:
When a message is sent via an admin SDK, invalid/expired tokens will
throw an error allowing you to then remove them from the database.
So when you send message, response will return from API contain result status with possible values if error can be found in table 9 here:
If response status 200 + and error -> NotRegistered >> that is mean token expires, so delete this token from your database.

How to debug routes that require accept headers?

I'm following the FOSRest documentation on API versioning.
However it's not clear to me how the headers connect it to a specific controller using media_type.
Right now I'm sending the headers: Accept: application/json;version=1.0 with Chrome extension Postman to /api/user/status
However I'm getting a No route found for "POST /api/user/status" error
Here's my configuration:
routing.yml:
type: rest
prefix: /api
resource: Acme\Bundle\SomeBundle\Controller\DefaultController
DefaultController.php:
use FOS\RestBundle\Controller\Annotations\Version;
/**
* #Version("1.0")
* #RouteResource("User", pluralize=false)
*/
class User
...
public function postStatusAction()
config.yml
fos_rest:
versioning:
enabled: true
resolvers:
query: false
custom_header: false
media_type:
enabled: true
regex: '/(v|version)=(?P<version>[0-9\.]+)/'
routing_loader:
default_format: json
view:
mime_types:
json: ['application/json;version=1.0']
format_listener:
enabled: true
console debug:router post_user_status
| Route Name | post_user_status |
| Path | /api/user/status.{_format} |
| Path Regex | #^/api/user/status(?:\.(?P<_format>json|xml|html))?$#s |
| Host | ANY |
| Host Regex | |
| Scheme | ANY |
| Method | POST |
| Requirements | _format: json|xml|html |
| Class | Symfony\Component\Routing\Route |
| Defaults | _controller: AcmeSomeBundle:Default:postStatus |
| | _format: json |
| Options | compiler_class: Symfony\Component\Routing\RouteCompiler |
+--------------+---------------------------------------------------------+
I've also tried to no avail in routing.yml condition: "request.attributes.get('version') == '1.0'"
What am I missing?
Thanks in part to #Mohammad in the comments for pointing me in the right direction I eventually found the answer.
While looking over the FOSRest versioning documentation again the instructions are to be taken quite literally.
One of the requirements states
You must configure the possible mime types for all supported versions:
Which means that since I only had:
view:
mime_types:
json: ['application/json;version=1.0']
Even if the in the header sent requested an API version that didn't exist it kept defaulting to this no matter what.
The correct config is
view:
mime_types:
json: ['application/json','application/json;version=1.0']
along with Mohhamad's mention that media_type headers require format_listener
format_listener:
enabled: true
rules:
- { path: '^/api', priorities: ['json'], fallback_format: json, prefer_extension: false }
With this it routes correctly to the right API version number.
It also finally routes to a 404 response if the version number is incorrect or if there is no API version header.

Laravel 5.2 & Postman GET Requests are not passing $request->send()

I'm having some difficulty with sending a simple GET request via Postman (An application extension in google chrome) to my Laravel 5.2 server. Here are some details to what I'm doing:
Route here:
Next is the code containing the route
Code here (within the laravel routes.php file):
Finally the error that gets thrown
Error Here
I've gone through multiple tutorials (if resources are needed I will post them on request) and videos and yet I think I may have overlooked something. I've even dived into the source code of Laravel's Route handler but it doesn't even get to the method:
$request->send();
located within the public\index.php file on line 56.
When I perform the:
php artisan route:list
I get the following response:
+--------+----------+-----------------------+------+--------------------------------------------------------+-----------------------------------+
| Domain | Method | URI | Name | Action | Middleware |
+--------+----------+-----------------------+------+------------------------------------------------------------------------------+-------------+
| | POST | here | | Closure | web |
| | GET|HEAD | user/:id/validate| | \Controllers\UserController#getOAuthValidation | web,api |
+--------+----------+-----------------------+------+--------------------------------------------------------+-----------------------------------+
If ANYONE can shed some light on this I would greatly appreciate it.
strange. Your routes file is /user/validate but your route is expecting an id.
I'm assuming that the validate method requires an id field in its signature?
Remove that, or change your postman get to /user/1/validate

Driver [google] not supported

I have an app that use google Auth to auth users, i'm trying to do some functional testing using codeception framework, but when i try to run the functional testing i got the following error
[InvalidArgumentException]
Driver [google] not supported.
Is there is any problem to define Google Auth in codeception or may be pass by it ? , it's working just fine with my application but it's not working in the testing
Here is my Auth config file
return array(
/*
|--------------------------------------------------------------------------
| Default Authentication Driver
|--------------------------------------------------------------------------
|
| This option controls the authentication driver that will be utilized.
| This driver manages the retrieval and authentication of the users
| attempting to get access to protected areas of your application.
|
| Supported: "database", "eloquent"
|
*/
'driver' => 'google',
/*
|--------------------------------------------------------------------------
| Authentication Model
|--------------------------------------------------------------------------
|
| When using the "Eloquent" authentication driver, we need to know which
| Eloquent model should be used to retrieve your users. Of course, it
| is often just the "User" model but you may use whatever you like.
|
*/
'model' => 'User',
/*
|--------------------------------------------------------------------------
| Authentication Table
|--------------------------------------------------------------------------
|
| When using the "Database" authentication driver, we need to know which
| table should be used to retrieve your users. We have chosen a basic
| default value but you may easily change it to any table you like.
|
*/
'table' => 'users',
/*
|--------------------------------------------------------------------------
| Password Reminder Settings
|--------------------------------------------------------------------------
|
| Here you may set the settings for password reminders, including a view
| that should be used as your password reminder e-mail. You will also
| be able to set the name of the table that holds the reset tokens.
|
| The "expire" time is the number of minutes that the reminder should be
| considered valid. This security feature keeps tokens short-lived so
| they have less time to be guessed. You may change this as needed.
|
*/
'reminder' => array(
'email' => 'emails.auth.reminder',
'table' => 'password_reminders',
'expire' => 60,
),
);
Also i tried to add the following in the _boostrap.php regarding the functional testing but still it can't pass the google driver, i think there is something wrong here .
Auth::LoginUsingId(1);

Setting up web services with x509 and multiple clients and how to distinguish clients?

Following these two links, I was able to implement a simple web service with x509 certification, and an authenticated test client to consume the service.
Right now, it looks something like this:
--------------
| ServiceA.svc | ------------> Test Client 1
| -GetData() |
--------------
How can I extend what I have to accomplish something like this:
--------------
| ServiceA.svc | ------------> Test Client 1
| -GetData() | ------------> Test Client 2
| -SaveData() |
--------------
| ServiceB.svc |-------------> Test Client 1
| -GetData() |
--------------
| ServiceC.svc |-------------> Test Client 2
| -SaveData() |
--------------
I already have services set up, and Test Client 2 ready to go.
So here are some of my questions:
Do I need to create a separate certificate for Test Client 2?
How will the config files/end points/behaviors look like? I think Service B and C would be easy to setup as it is basically the same as what I have right now, but now that ServiceA will be consumed by both clients, I am a bit lost.
If ServiceA is called how do I know which client is calling it? I potentially want to limit the methods they can call (ie. TC1 can only use GetData(), TC2 can only use SaveData()), and be able to log who is accessing the methods.
I can post what I have on the config files if needed, but it looks basically what the two aforementioned links have.
yes, each client needs a separate certificate. Then from within the operation you can get its distinguished identity:
ServiceSecurityContext.Current.PrimaryIdentity.Name
The best practice is to separate the authorization process like described here:
http://msdn.microsoft.com/en-us/magazine/cc948343.aspx