What you're asking for is impossible, unless you can use the secret only before opening yourself to attack and never need it again. If that works, you're OK; just make sure the secret is only present in the container during the non-vulnerable period (e.g. after the container starts but before it opens a listening port or makes an outbound request) and that the secret is then gone (removed both from however it was passed into the container, and from the process memory, and note that the latter is tricky since the compiler will optimize out a "useless" write) and unrecoverable before exposing any attack surface.
If that doesn't work, you need to re-think your requirements and maybe your whole design. You can't give something to a container without giving it to the attacker who owns the container and can see everything it contains. You can obfuscate the secret, but in the end, if the program running in the container could see / use it, the attacker who takes over that program can too. At best you make them do a little reverse engineering.
That doesn't mean there are no options, though.
First of all, try not to have vulnerabilities in the container. The security offered by containers should be defense-in-depth, not the full protection of your system. When evaluating a security boundary it is good to assume all earlier boundaries have failed, but that doesn't change the fact that, in most systems, the outer boundaries (the program running in the container, here) should be doing basically all the security work, and should be up to the task.
Part of that is operating under least privilege within the container itself. For example, if the process starts with moderately high (in the container's context) privileges and reads a secret that requires those privileges, the process can then irreversibly drop its privileges, such that an attacker taking over the process later won't be able to read the secret the same way (though if it's still in the process' memory, the attacker could potentially read that, so you might want to purge it from there if you can). That's not foolproof - it just means that the attacker needs to find a local EoP vulnerability to read it again - but it makes a single vulnerability probably insufficient.
You can deputize the holding of the secret. If your main concern is merely the attacker seeing the secret, rather than being able to use it, you can design a system that holds the secret outside of the container (or, slightly less securely, in a separate process of a separate user inside the container) and exposes some secured communication channel (e.g. a local (Unix) socket) that can be used by the container process to say "do <thing> with secret" and through which the secret will never actually be exposed, directly or indirectly. Of course, you probably want to limit the scope of <thing>, or else the attacker doesn't really have any need to know the secret at all, after all (it doesn't matter whether the attacker actually knows the password if she can just say "tell 'em the password" to your deputized secret-holder).
You might be able to make the secret short-lived. If it's for something that is only relevant for a short period of time - ideally shorter than the container lifetime, though this might help even if that's not true - you should rotate the secret as often as possible, and ensure each time a container starts that its secret will be invalidated as soon as possible. That way, an attacker who steals it will have limited use of it (or possibly none at all, if it has already expired).