No. The principle means "The security of a cipher must not depend on the secrecy of the algorithm". Inputs are allowed to be secret. That includes keys, plaintext, and passwords.
Different people use the name "pepper" to refer to different things. I know of at least three. None violate that principle. The first two don't harm security.
- The key used to encrypt password hashes and salts.
- A second salt that is stored outside the password database.
- A second salt that is randomly generated and not stored anywhere. The server and password crackers are supposed to brute force it as part of its password stretching procedure.
Definition one doesn't hurt security. A benefit to this is that it prevents offline cracking if the key can be kept secret.
The key might reside on a HSM, which would mean an extra layer of defense resistant to a lot of attacks.
At worst using encryption like this is equivalent to storing hashes unencrypted. It doesn't reduce security. (Just like using full disk encryption doesn't reduce secrecy.)
Two is no more insecure than normal salted password hashing. If this pepper is unpredictable (remains secret and can't be brute forced) then it prevents offline cracking. It is better than using one salt in certain contexts where hackers gain read only access to only some of your data.
The old justification for this method was that it would provide an extra layer of defense if the only type of access a hacker has is a database dump or SQL injection. Outside of that context it's pointless, but it never hurts security.
Three doesn't violate the principle, but it's inferior to just allowing the original password stretching algorithm more time to run. (Instead of forcing the server to run it more than one time.)
It's less secure if scrypt is used, for example.