mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-06 15:46:57 +01:00
59 lines
2.2 KiB
Plaintext
59 lines
2.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * security/container_security/security-platform.adoc
|
|
|
|
[id="security-platform-admission_{context}"]
|
|
= Protecting control plane with admission plug-ins
|
|
|
|
While RBAC controls access rules between users and groups and available projects,
|
|
_admission plug-ins_ define access to the {product-title} master API.
|
|
Admission plug-ins form a chain of rules that consist of:
|
|
|
|
* Default admissions plug-ins: These implement a default set of
|
|
policies and resources limits that are applied to components of the {product-title}
|
|
control plane.
|
|
|
|
* Mutating admission plug-ins: These plug-ins dynamically extend the admission chain.
|
|
They call out to a webhook server and can both authenticate a request and modify the selected resource.
|
|
|
|
* Validating admission plug-ins: These validate requests for a selected resource
|
|
and can both validate the request and ensure that the resource does not change again.
|
|
|
|
API requests go through admissions plug-ins in a chain, with any failure along
|
|
the way causing the request to be rejected. Each admission plug-in is associated with particular resources and only
|
|
responds to requests for those resources.
|
|
|
|
[id="security-deployment-sccs_{context}"]
|
|
== Security context constraints (SCCs)
|
|
|
|
You can use _security context constraints_ (SCCs) to define a set of conditions
|
|
that a pod must run with in order to be accepted
|
|
into the system.
|
|
|
|
Some aspects that can be managed by SCCs include:
|
|
|
|
- Running of privileged containers
|
|
- Capabilities a container can request to be added
|
|
- Use of host directories as volumes
|
|
- SELinux context of the container
|
|
- Container user ID
|
|
|
|
If you have the required permissions, you can adjust the default SCC policies to
|
|
be more permissive, if required.
|
|
|
|
[id="security-service-account_{context}"]
|
|
== Granting roles to service accounts
|
|
|
|
You can assign roles to service accounts, in the same way that
|
|
users are assigned role-based access.
|
|
There are three default service accounts created for each project.
|
|
A service account:
|
|
|
|
* is limited in scope to a particular project
|
|
* derives its name from its project
|
|
* is automatically assigned an API token and credentials to access the
|
|
OpenShift Container Registry
|
|
|
|
Service accounts associated with platform components automatically
|
|
have their keys rotated.
|