Permission profiling is a way to generate a unique policy, for a specific robot, with the least priviliges needed to complete a task, such as deploying an app. The robot, created in Wayfinder, is put into a learning mode for one hour while you model that task manually or in your CI system. The permissions needed for that task are recorded and learned, and then a policy is generated with the least privilege for this robot to do that task in an automated way.
Without permission profiling, you would normally create a robot, assign it an existing Wayfinder role, which then can be assigned by workspace members, according to an assignment policy that the workspace admin creates. If an existing role doesn't have the required permissions, you could create and apply a new role with the right permissions and follow this same procedure.
With permission profiling, instead, workspace members dynamically construct RBAC permissions for robot accounts based on a usage pattern the robot "learns." No role needs to be explicitly assigned to the robot, and no assignment policy is needed. The policies created by a profiling session are applied to a specific robot, and cannot be assigned to other robots.
This feature has a number of benefits, the most important being:
- Resulting policies have least privilege. Only the permissions required for the task are granted, to a specific robot.
- Workspace members don't have to worry about the internals of permissions. The workspace members can create a robot token and go.
- Kubernetes has a large ecosystem of extended API groups. So you will probably have applications that require access to these API groups, and therefore, require new roles and assignment policies. Permission profiling makes it simpler for workspace admins and workspace members to create a robot access policy with only the required permissions, bypassing creating a new role and assignment policy.
Constraints on permission profiling
Profiling has a number of boundaries:
- Profiling can only occur within a namespace. Cluster-scoped permissions are explicitly denied.
- Profiling does not invalidate any security policies enforced within the cluster. If a request hits an enforcement policy the permission is rejected.
- Learning permissions is subject to a time window - by default this is one hour. After a robot has been created or enabled to profile the permission to learn will automatically disappear after the time has expired. The robot will no longer learn any new permissions.
The Wayfinder administrator must enable permission profiling—see Enabling Permission Profiling.
Use permission profiling
If the Wayfinder administrator enables permission profiling, the profiling option appears in the UI and CLI. You can use profiling if the robot is used for app deployments.
UI: Switch on profiling when creating a robot
To create a robot and switch on profiling:
Follow the procedure to create a robot, and after entering the name and description, select Yes for these two options in the Use permission profiling dialog:
- Is this robot being used for application deployments?
- Would you like to switch on profiling, allowing the permissions to be learned?
A dialog confirms that when you switch on profiling, the robot is assigned the cluster.learn role. Click Next.
Provide the cluster and namespace that the robot applies to, and then click Save.
The robot is created with permission profiling.
Copy the robot token and environment variables to use in your CI system.
You have a time window (default: one hour) to use this token to learn the specific permissions needed for your app deployment.
Permissions are only scoped to the namespace you provided. No cluster-scope permissions are granted, and no violations of existing security policies are permitted. For more information, see Constraints on permission profiling.
CLI: Switch on profiling when creating a robot
Example use case: In this example, you want to deploy an app into the
test namespace, create a new robot called
test, and give it the permissions needed to deploy this app with your CI system.
To create the robot and switch on profiling:
Create the robot and choose to switch on profiling when prompted:
$ wf create robot test
✔ Please provide a description for this robot: Test deployment
✔ Is this robot being used for application deployments? yes
✔ Would you like to switch on profiling, allowing the permissions to be learned? yes
✔ For the next hour any permitted permissions will be learned
✔ Which cluster should the robot be scoped to my-cluster
✔ Which namespace should the robot be scoped to test
✔ You have chosen the role: cluster.learn
✔ Permissions have been successfully assigned to subject/s
◉ Waiting for the role to apply successfully
✔ This robot will continue to profile permissions usage until: 18:34PM
✔ The following secrets can be used within your chosen CI
(Optional) Check that you have a learning policy attached to the robot
$ wf get policy --robot test
NAME ROLE ENABLED STATUS AGE
cluster.learn-rlzqv cluster.learn true Success 29s
You now have a robot with profiling enabled and scheduled to stop learning after one hour.
Take the environment variables from Step 1 above, and use them within our CI system.
As the robot speaks to the cluster, required permissions are captured and sent back to Wayfinder to provision policies for that robot.
You can check back and see the policies being captured by running:
$ wf get policy --robot test
NAME ROLE ENABLED STATUS AGE
cluster.learn-rlzqv cluster.learn true Success 6m53s
test-api-znfsb - true Success 3s
test-profile-m56gm - true Success 3s
Switch on permission profiling for an existing robot
You can turn on profiling for an existing robot that has no role assigned. To do so, use the CLI command
wf enable robot learning. Then follow the robot learning process with your CI as shown above.
Manually stop learning mode
Learning mode switches off after a time period (default: 1 hour). However, you can stop learning early by running
wf disable robot learning ROBOT-NAME.
Restrict the scope of learned policies
Learning roles provide a boundary around what can and can't be learned during the profiling period. The default learning role is
cluster.learn, and you can view its permissions by running:
wf get role cluster.learn -o yaml
The range of permissions in this default role is fairly liberal. This lets a workspace member consume any permissions within the scope of the designated namespace, excluding daemonsets.
To restrict the scope of permissions that can be learned, you can create your own learning role. For example, you could use Wayfinder's
cluster.deployment role as a base. With this as your learning role, the learned permissions will be constrained by the permissions in that role. However, due to the principle of least privilege, the learned policy will only contain the permissions that were required and used during the task being learned, so the learned policy may have a narrower scope than the
To tell Wayfinder that your new role is a learning role, in the role definition, set the
boundary. Then when you switch on profiling, Wayfinder detects multiple learning roles, and prompts you to select one.
Disable permission profiling in your workspace
Workspace administrators can disable permission profiling for their workspace by disabling the robot learning role. For example, if you're using the default learning role
cluster.learn, run the command:
wf disable role cluster.learn -w WORKSPACE-NAME