This section of the book appears to be talking about how the details of the threading and scheduling are implemented for a user mode program.
When threading first became popular, most operating systems were Multi-processing OS's, but not "multithreaded" in the sense that the operating system provide support for multiple user code streams sharing the same user address space and allowing these threads to be scheduled separately by the OS. Threading was a concept not dealt with by the OS at all. The OS knew processes, what the processes did with the user mode time they were given was their business.
With User mode threading, support for threads was provided by a programming library and the thread scheduler was a subroutine in the user program itself. The operating system would schedule the process to run and the process would schedule the threads within it. There were problems with this model because an event on one thread that caused the OS to block the process effectively blocked all threads within that process. This model only allowed the threads to run on a single CPU at a time, limiting parallelism. This is the many to one mapping model listed in the book. The single Kernel thread is the user process that the kernel schedules.
With Kernel threads, the OS becomes aware of the threads as separate schedulable entities that share the same address space. The OS can then allow each thread to compete for CPU time separately with other threads in the system. This allows the OS to schedule multiple threads from the same process on multiple CPUs at the same time. It also allows it run threads from a process where one thread is blocked, but the others have computable work to do. In this case each user thread has a backing Kernel thread that is a schedulable entity.
The MUST relationship they are talking about is that even if you are using User threads there is an underlying Kernel thread that the OS can schedule. There MUST be a schedulable entity even if it's at the process level. So your first comment is correct.