I know SHA-1 hashing is regarded insecure. HMAC-SHA-1 is still regarded secure as this is an encryption process with symmetric key of the hash produced by SHA-1.
So signing using RSA with a key size of 2048 with a SHA-1 hash over the content should be regarded secure just like HMAC-SHA-1, correct?
No, unfortunately your well meant comparison with HMAC fails and RSA with SHA-1 - as defined for PKCS#1 v1.5 padding and PSS - is considered insecure.
The construction of HMAC makes it near invulnerable to attacks on the collision resistance of the underlying hash. That is because it uses the secret key as input to the hash function to create the additional resistance. Any adversary does not have access to that secret key.
However, if the hash is used in a signature, they hashing of the data is commonly performed before the keyed operation is applied. No shared secret is available to allow for the same construction as HMAC and no randomization of the hash is performed. That means that the (lack of) original collision resistance is preserved, and that the signature generation function is therefore vulnerable as well.
As noted in the comments and explained in this answer an additional random input to the data could strengthen the hash and thus signature function significantly, even if that randomization doesn't rely on a shared secret. It would however change the signature API as provided by many RSA functions libraries significantly to add randomization to the hash function as they often directly accept hash values as input.
So signing using RSA with a key size of 2048 with a SHA-1 hash over the content should be regarded secure just like HMAC-SHA-1, correct?
The practical answer is: No, this is still insecure with all deployed RSA-based signature schemes. If you're just asking about using existing tools to make RSA-based signatures, stop here: SHA-1 is bad news, and don't touch it. (Also, don't use RSA in new applications; if you want signatures, use Ed25519.)
To get an answer in more detail, you really need to specify which signature scheme you're talking about—‘RSA’ alone just refers to the trapdoor permutation family $x \mapsto x^e \bmod n$, which is not a signature scheme (or encryption scheme) in itself. The most popular signature schemes based on RSA are RSASSA-PKCS1-v1_5 and RSASSA-PSS from PKCS#1, also published as RFC 3447.
In these signature schemes, a signature on a message $m$ under public key $(n,e)$ is an integer $s$ such that $$s^e \equiv f_r(H(m)) \pmod n,$$ where $f_r$ is some randomized function. RSASSA-PKCS1-v1_5 is not actually randomized, so $f_r(h)$ just adds some fixed padding to $h$ and ignores $r$; RSASSA-PSS is randomized, and $f_r(h)$ roughly encodes the pair $(r, h)$ in a roundabout way that makes proving theorems easy.
The details of $f_r$ aren't important—what is important is: The signature equation is defined in terms of $H(m)$ so the ability to find collisions in $H$ implies the ability to forge signatures. So if a forger can find two messages $m \ne m'$ such that $H(m) = H(m')$, they can ask the legitimate user to sign $m$, and then $s$ will work as a forged signature on $m'$ too that the legitimate user never meant to sign.
But it is a historical accident that the randomization $r$ of the signature scheme didn't figure into hashing the message! Had RSASSA-PSS used $\operatorname{HMAC-}\!H_r(m)$ instead of $H(m)$, or even just $H(r \mathbin\| m)$, it likely would have been resilient to collisions in $H$—and in fact, the original PSS proposal to IEEE pointed out that using $H(r \mathbin\| m)$ instead of $H(m)$ does not seem to rely on collision resistance of $H$.
This is not just a trivial change: using $H(r \mathbin\| m)$ likely would have thwarted certificate forgery attacks on MD5, which were exploited (paywall-free preprint) by the governments of the United States and Israel in an international incident of industrial sabotage against Iran. Today, the standard countermeasure against this adopted by the CA/Browser Forum for certificates is randomization of the CA serial number, which has an effect similar to (though slightly weaker than) using $H(r \mathbin\| m)$—but it requires application-specific changes where the signature scheme could have thwarted the entire class of attacks for all applications.
So reliance on plain collision resistance is a historical design mistake of essentially all RSA-based signature schemes that are deployed today. But there are randomized signature schemes like the original PSS proposal—and even deployed signature schemes (though not RSA-based) like Ed25519, which is the signature scheme you should reach for in new applications today—that are resilient to collisions by virtue of using $H(r \mathbin\| m)$ instead of $H(m)$. More background and history.
signing using rsa2048 of SHA-1 of the content should be regarded still secure
No, at least because SHA-1 collisions are possible and can makes things trivially insecure.
For example, using the prefix at shattered.io, it is trivial to make two PDF documents each with an arbitrarily chosen appearance when displayed and the same SHA-1 hash. Thus if Malory prepares a PDF that Alice signs as a detached signature of the SHA-1 of the PDF file, and you accept that signature, then you are vulnerable to Alice later presenting a document with very different appearance that also checks against the same signature, and Alice pretending that she signed this other document and was unaware of the one you accepted. It will be at least confusing, and an expert would testify that nothing indicates that Alice was malignant (only the party that prepared the PDF likely was).
On the other hand, if one signs using SHA-1 something which first 512 bytes contains enough bits (160 is aplenty) that are random and unpredictable, then one can still be reasonably confident that this signature can't be used for an other purpose. That's because finding an exact second SHA-1 preimage remains hard. For example, a certificate authority could safely produce a digital certificate from a Certificate Signing Request it receives, by using a serial number that it randomly assigns. That allows compatibility of the certificate with ancient software that only uses SHA-1. However, that's frowned at for policy reasons.
Note: that security assurance for unpredictable content of the first 512 bytes is still weaker than the one we get for HMAC and key unknown to the attacker (the standard security assumption for a MAC); but is comparable to the one we get for HMAC with the adversary learning the key after the MAC (or message) is committed and trying to prepare another message that does not change the MAC.
Also, 2048-bit RSA will become obsolete in the foreseeable future (2030 if you trust French security authorities, sooner for some others).
